[RFC149] Utility Class

[bjhargrave]

Original bug ID: BZ#1739 From: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp> Reported version: R4 V4.2

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Created attachment 148 Javadoc which will be specified in RFC149

I'm now designing new API to be specified in RFC149. TR069Mapper will be the one which TR-069 Protocol Adapter(PA) can use:

1. When PA receives SetParameterValues RPC form ACS, PA will open a DmtSession and call TR069Mapper#setTR069ParameterValue(DmtSession session,String tr069Path, String tr069DataType, String value) for every ParameterValueStruct.

2. When PA receives GetParameterValues RPC form ACS, PA will open a DmtSession and call TR069Mapper#getTR069ParameterValue(DmtSession session,String tr069Path) and get TR069ParameterValue for every ParameterValueStruct. PA can get the data type and value to to be included in GetParameterValuesResponse RPC by the returned TR069ParameterValue object.

Now, I have a question to ask REG members. Currently, I design TR069Mapper as an OSGi Service. However, TR069Mapper can be not an OSGi Service but an Utility Class with static methods.

Q. Which is more proper an OSGi Service or an Utility Class ?

IMO, OSGi Service is not needed, because there is no need to have multiple implementation by adopting OSGi Service. In addition, we can expect more consistent behaivior of TR-069 PA by Utility Class than by OSGi Service.

Attached file: doc.zip (application/x-zip-compressed, 76379 bytes) Description: Javadoc which will be specified in RFC149

[bjhargrave]

Comment author: @bjhargrave

If the implementation is fairly simple, it does not maintain any state and we don't see the need for any implementation to optimize that implementation in any way, then a class with static methods can be used.

The design of this class would be cleaner of the class just did any transformations and the caller of the class manipulated the DmtSession rather than the utility class. (I have not looked at this class and am just giving general advice.)

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I have some comments about the TR-069 utility API. They are separated to different groups according to the interfaces.

1. TR069Mapper That service operates on DmtSession with TR-069 string value. We would like to remain the DMT session operations to the implementation of the PA. Our suggestion is to remove that class. Is it OK?

2. TR069URI

   • can be renamed to TR069Uri, because of info.dmtree.Uri. It is camel case.
   • isValidDmtTreeUri is available as info.dmtree.Uri.isValidUri(String) - can be removed
   • isValidTR069Path can be renamed to isValidUri - it's OK in the context of TR069Uri
   • convert methods can throw exceptions in case of invalid arguments
   • convertTR069PathToDmtUri can be abbreviated to getDmtUri
   • convertDmtUriToTR069Path can be abbreviated to getTR069Uri

3. TR069ParameterValue The class will realize the TR-069 data type mapping table.

   • getTR069DataType() can be renamed to getType() - the method is defined in TR069ParameterValue and "TR069Data" looks redundant
   • getValue can return Object
   • new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException
   • new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

4. TR069MapperException

   • If we agree that the mapper can be removed, then we can rename the exception to TR069MappingException
   • can add different error codes - actually, TR-069 error codes, which can be returned directly by PA

The attached javadoc realizes the description.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Created attachment 152 TR-069 Util API (17.09.2010 - ProSyst update)

Attached file: TR069_Util_17092010_ProSyst_javadoc.zip (application/zip, 59248 bytes) Description: TR-069 Util API (17.09.2010 - ProSyst update)

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Thank you for your proposal.

I have some comments about the TR-069 utility API. They are separated to different groups according to the interfaces.

1. TR069Mapper That service operates on DmtSession with TR-069 string value. We would like to remain the DMT session operations to the implementation of the PA. Our suggestion is to remove that class. Is it OK?

Why would you like to remain the DMT session operations to the implementation of the PA ? What is the benefit for an implementer of TR-069 PA, compared to the API I propose ?.

I don't say" I am against with you". Just I want to clarify as usual．Actually, your proposal reduces my task to implement RI of RFC149, which I personally am happy with :-).

Originally before REF F2F and BundleFest in June 2010, RFC149 does not have any Reference Implementation or Utility Class, because it is just a guideline. However, I was asked to have Utility Class or Service in RFC149 in the F2F:

• To understand both DMT and TR-069 well is not easy, even if RFC149 provides the guideline. It will result in the unexpected behavior of TR-069 PA. In other words, the expected behavior of TR-069 PA is needed.

2. TR069URI
   • can be renamed to TR069Uri, because of info.dmtree.Uri. It is camel case.
   • isValidDmtTreeUri is available as info.dmtree.Uri.isValidUri(String) - can be removed
   • isValidTR069Path can be renamed to isValidUri - it's OK in the context of TR069Uri
   • convert methods can throw exceptions in case of invalid arguments
   • convertTR069PathToDmtUri can be abbreviated to getDmtUri
   • convertDmtUriToTR069Path can be abbreviated to getTR069Uri

I prefer "path" for TR069 and "URI" for DMT. However, it is not main issue. Let's discuss the naming of the methods after we conclude whether we remove TR069Mapper or not.

3. TR069ParameterValue The class will realize the TR-069 data type mapping table.
   • getTR069DataType() can be renamed to getType() - the method is defined in TR069ParameterValue and "TR069Data" looks redundant
   • getValue can return Object

Why Object to be returned ? For TR069-PA, it handles value as just string.

• new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException

When will TR069-PA call this method ? Why array will be returned ?

• new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

Could you explain the usage of this ( as concrete use case) ? Why is data array ?

4. TR069MapperException
   • If we agree that the mapper can be removed, then we can rename the exception to TR069MappingException
   • can add different error codes - actually, TR-069 error codes, which can be returned directly by PA

The attached javadoc realizes the description.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Thank you for your proposal.

I have some comments about the TR-069 utility API. They are separated to different groups according to the interfaces.

1. TR069Mapper That service operates on DmtSession with TR-069 string value. We would like to remain the DMT session operations to the implementation of the PA. Our suggestion is to remove that class. Is it OK?

Why would you like to remain the DMT session operations to the implementation of the PA ? What is the benefit for an implementer of TR-069 PA, compared to the API I propose ?. RFC-149 needs a few utilities, which will transform TR-069 world to DMT. The interesting transformations are:

• TR-069 parameter name <-> DMT Uri
• TR-069 parameter value <-> DMT data DMT session can produce DMT Uris and DMT data, but the session is not needed to convert them. I don't say" I am against with you". Just I want to clarify as usual．Actually, your proposal reduces my task to implement RI of RFC149, which I personally am happy with :-). I am very happy to discuss these good questions! Originally before REF F2F and BundleFest in June 2010, RFC149 does not have any Reference Implementation or Utility Class, because it is just a guideline. However, I was asked to have Utility Class or Service in RFC149 in the F2F:
• To understand both DMT and TR-069 well is not easy, even if RFC149 provides the guideline. It will result in the unexpected behavior of TR-069 PA. In other words, the expected behavior of TR-069 PA is needed. All notes are about the RFC-149 utility (class or service). The package will be publicity exported. Right? TR-069 PA Reference Implementation can reuse it.

  2. TR069URI
     • can be renamed to TR069Uri, because of info.dmtree.Uri. It is camel case.
     • isValidDmtTreeUri is available as info.dmtree.Uri.isValidUri(String) - can be removed
     • isValidTR069Path can be renamed to isValidUri - it's OK in the context of TR069Uri
     • convert methods can throw exceptions in case of invalid arguments
     • convertTR069PathToDmtUri can be abbreviated to getDmtUri
     • convertDmtUriToTR069Path can be abbreviated to getTR069Uri

I prefer "path" for TR069 and "URI" for DMT. However, it is not main issue. Let's discuss the naming of the methods after we conclude whether we remove TR069Mapper or not. OK

3. TR069ParameterValue The class will realize the TR-069 data type mapping table.
   • getTR069DataType() can be renamed to getType() - the method is defined in TR069ParameterValue and "TR069Data" looks redundant
   • getValue can return Object

Why Object to be returned ? For TR069-PA, it handles value as just string. TR-069 PA parser processes the string values. That utility can work over instances like Integer, Long,...

• new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException

When will TR069-PA call this method ? When SetParameterValue is in progress, TR-069 PA Reference Implementation will call that method to retrieve DmtData. That data will be set to DMT. Why array will be returned ? An array is needed because the value can be comma-separated list. Each list item will have own DmtData instance.

• new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

Could you explain the usage of this ( as concrete use case) ? Yes, of course. We can presume that there are:

• ./A/B - list subtree node
• ./A/B/C and ./A/B/D - leaf nodes
• the value of ./A/B/C is C_value, ./A/B/D is D_value The use case:
  1. TR-069 PA receives request GetParameterValues(["A.B"])
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA checks the type of "./A/B"
  4. It's list subtree node, then collect the child values. They are DmtData("C_value") and DmtData("D_value")
  5. Those values are passed to getTR069ParameterValue utility method
  6. The returned TR069ParameterValue is passed to parser
  7. The parser response is forwarded to transport layer. Why is data array ? The reason is same as above. The node type can point to list subtree node. In this case, each list item will be collected by a different DmtData.

4. TR069MapperException
   • If we agree that the mapper can be removed, then we can rename the exception to TR069MappingException
   • can add different error codes - actually, TR-069 error codes, which can be returned directly by PA

The attached javadoc realizes the description.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

1. TR069Mapper That service operates on DmtSession with TR-069 string value. We would like to remain the DMT session operations to the implementation of the PA. Our suggestion is to remove that class. Is it OK?

Why would you like to remain the DMT session operations to the implementation of the PA ? What is the benefit for an implementer of TR-069 PA, compared to the API I propose ?. RFC-149 needs a few utilities, which will transform TR-069 world to DMT. The interesting transformations are:

• TR-069 parameter name <-> DMT Uri
• TR-069 parameter value <-> DMT data DMT session can produce DMT Uris and DMT data, but the session is not needed to convert them.

I understand what you mean. Let me have a time to think about it.

Originally before REF F2F and BundleFest in June 2010, RFC149 does not have any Reference Implementation or Utility Class, because it is just a guideline. However, I was asked to have Utility Class or Service in RFC149 in the F2F:

• To understand both DMT and TR-069 well is not easy, even if RFC149 provides the guideline. It will result in the unexpected behavior of TR-069 PA. In other words, the expected behavior of TR-069 PA is needed. All notes are about the RFC-149 utility (class or service). The package will be publicity exported. Right?

Right.

TR-069 PA Reference Implementation can reuse it.

I would like to remark that REG will NOT provide any TR-069 PA RI. We will provide just Utility class or OSGi service, which will be used by TR-069 PA.

3. TR069ParameterValue The class will realize the TR-069 data type mapping table.
   • getTR069DataType() can be renamed to getType() - the method is defined in TR069ParameterValue and "TR069Data" looks redundant
   • getValue can return Object

Why Object to be returned ? For TR069-PA, it handles value as just string. TR-069 PA parser processes the string values. That utility can work over instances like Integer, Long,...

I don't understand it...

• new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException

When will TR069-PA call this method ? When SetParameterValue is in progress, TR-069 PA Reference Implementation will call that method to retrieve DmtData. That data will be set to DMT.

Again, why is value in Object ? What PA receives by SetParameterValues RPC is XML. It means PA will parse value-type pair as String for each. It seems to me that DmtData[] getDmtData(String value, String tr069type) is more convenient.

Could you show some usage as you describe for getTR069ParameterValue() method?

Why array will be returned ? An array is needed because the value can be comma-separated list. Each list item will have own DmtData instance.

I understand your intention of DmtData array. However, as described in Bug#1672, DmtData cannot be determined only by value and tr069type. See SetParameterValue RPC sheet of Bug#1672. Format of the node is mandatory needed and RawFormatName is optionally needed if the format supports FORMAT_RAW_BINARY or FORMAT_RAW_BINARY.

Therefore, DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper.

• new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

Could you explain the usage of this ( as concrete use case) ? Yes, of course. We can presume that there are:

• ./A/B - list subtree node
• ./A/B/C and ./A/B/D - leaf nodes
• the value of ./A/B/C is C_value, ./A/B/D is D_value The use case:
  1. TR-069 PA receives request GetParameterValues(["A.B"])
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA checks the type of "./A/B"
  4. It's list subtree node, then collect the child values. They are DmtData("C_value") and DmtData("D_value")
  5. Those values are passed to getTR069ParameterValue utility method
  6. The returned TR069ParameterValue is passed to parser
  7. The parser response is forwarded to transport layer.

Thank you for the usage. Even if the node is list subtree, TR-069 PA needs to get the node type and the MetaNode of the target node. Right ?

Why is data array ? The reason is same as above. The node type can point to list subtree node. In this case, each list item will be collected by a different DmtData.

I got it.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

1. TR069Mapper That service operates on DmtSession with TR-069 string value. We would like to remain the DMT session operations to the implementation of the PA. Our suggestion is to remove that class. Is it OK?

Why would you like to remain the DMT session operations to the implementation of the PA ? What is the benefit for an implementer of TR-069 PA, compared to the API I propose ?. RFC-149 needs a few utilities, which will transform TR-069 world to DMT. The interesting transformations are:

• TR-069 parameter name <-> DMT Uri
• TR-069 parameter value <-> DMT data DMT session can produce DMT Uris and DMT data, but the session is not needed to convert them.

I understand what you mean. Let me have a time to think about it. OK, any comments and questions are welcome.

Originally before REF F2F and BundleFest in June 2010, RFC149 does not have any Reference Implementation or Utility Class, because it is just a guideline. However, I was asked to have Utility Class or Service in RFC149 in the F2F:

• To understand both DMT and TR-069 well is not easy, even if RFC149 provides the guideline. It will result in the unexpected behavior of TR-069 PA. In other words, the expected behavior of TR-069 PA is needed. All notes are about the RFC-149 utility (class or service). The package will be publicity exported. Right?

Right.

TR-069 PA Reference Implementation can reuse it.

I would like to remark that REG will NOT provide any TR-069 PA RI. We will provide just Utility class or OSGi service, which will be used by TR-069 PA. Seems OK, it's guideline.

3. TR069ParameterValue The class will realize the TR-069 data type mapping table.
   • getTR069DataType() can be renamed to getType() - the method is defined in TR069ParameterValue and "TR069Data" looks redundant
   • getValue can return Object

Why Object to be returned ? For TR069-PA, it handles value as just string. TR-069 PA parser processes the string values. That utility can work over instances like Integer, Long,...

I don't understand it... The idea was that TR-069 PA XML parser can parse the string to a java instance. I talked with my colleague and we decided that it is OK to to use strings.

• new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException

When will TR069-PA call this method ? When SetParameterValue is in progress, TR-069 PA Reference Implementation will call that method to retrieve DmtData. That data will be set to DMT.

Again, why is value in Object ? What PA receives by SetParameterValues RPC is XML. It means PA will parse value-type pair as String for each. It seems to me that DmtData[] getDmtData(String value, String tr069type) is more convenient. String is OK as I mentioned above.

Could you show some usage as you describe for getTR069ParameterValue() method? Yes, of course. We can presume that there is:

• ./A/B - list subtree node The use case:
  1. TR-069 PA receives request SetParameterValues([ParameterValueStruct("A.B", "1_value,2_Value")], "ACS_generated_key")
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA gets ./A/B meta node
  4. TR-069 PA gets ./A/B DmtData with getDmtData(String value, String tr069Type, MetaNode metaNode). The result will be DmtData("1_value") and DmtData("2_value")
  5. The node type is list subtree, then delete all children of ./A/B
  6. Create children:
• ./A/B/1 with value DmtData("1_value")
• ./A/B/2 with value DmtData("2_value")
  7. returns SetParameterValuesResponse to the ACS

Why array will be returned ? An array is needed because the value can be comma-separated list. Each list item will have own DmtData instance.

I understand your intention of DmtData array. However, as described in Bug#1672, DmtData cannot be determined only by value and tr069type. See SetParameterValue RPC sheet of Bug#1672. Format of the node is mandatory needed and RawFormatName is optionally needed if the format supports FORMAT_RAW_BINARY or FORMAT_RAW_BINARY.

Therefore, DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper. Sorry, I forgot it. Yes, the meta node is needed too.

• new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

Could you explain the usage of this ( as concrete use case) ? Yes, of course. We can presume that there are:

• ./A/B - list subtree node
• ./A/B/C and ./A/B/D - leaf nodes
• the value of ./A/B/C is C_value, ./A/B/D is D_value The use case:
  1. TR-069 PA receives request GetParameterValues(["A.B"])
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA checks the type of "./A/B"
  4. It's list subtree node, then collect the child values. They are DmtData("C_value") and DmtData("D_value")
  5. Those values are passed to getTR069ParameterValue utility method
  6. The returned TR069ParameterValue is passed to parser
  7. The parser response is forwarded to transport layer.

Thank you for the usage. Even if the node is list subtree, TR-069 PA needs to get the node type and the MetaNode of the target node. Right ? Actually, the node type is enough in getTR069ParameterValue. The meta node can removed.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Created attachment 153 bnd project including javadoc

• new mapping TR0-69->DMT method can be added DmtData[] getDmtData(Object value, String tr069Type) throws TR069MappingException

When will TR069-PA call this method ? When SetParameterValue is in progress, TR-069 PA Reference Implementation will call that method to retrieve DmtData. That data will be set to DMT.

Again, why is value in Object ? What PA receives by SetParameterValues RPC is XML. It means PA will parse value-type pair as String for each. It seems to me that DmtData[] getDmtData(String value, String tr069type) is more convenient. String is OK as I mentioned above.

I got it.

Could you show some usage as you describe for getTR069ParameterValue() method? Yes, of course. We can presume that there is:

• ./A/B - list subtree node The use case:
  1. TR-069 PA receives request SetParameterValues([ParameterValueStruct("A.B", "1_value,2_Value")], "ACS_generated_key")
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA gets ./A/B meta node
  4. TR-069 PA gets ./A/B DmtData with getDmtData(String value, String tr069Type, MetaNode metaNode). The result will be DmtData("1_value") and DmtData("2_value")
  5. The node type is list subtree, then delete all children of ./A/B
  6. Create children:
• ./A/B/1 with value DmtData("1_value")
• ./A/B/2 with value DmtData("2_value")
  7. returns SetParameterValuesResponse to the ACS

I got the image.

Why array will be returned ? An array is needed because the value can be comma-separated list. Each list item will have own DmtData instance.

I understand your intention of DmtData array. However, as described in Bug#1672, DmtData cannot be determined only by value and tr069type. See SetParameterValue RPC sheet of Bug#1672. Format of the node is mandatory needed and RawFormatName is optionally needed if the format supports FORMAT_RAW_BINARY or FORMAT_RAW_BINARY.

Therefore, DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper. Sorry, I forgot it. Yes, the meta node is needed too.

During implementing RI, I found that the node uri is required for FORMAT_NODE_URI (relative path). See the attached javadoc.

• new mapping DMT->TR-069 method can be added TR069ParameterValue getTR069ParameterValue(DmtData[] data, String nodeType, MetaNode metaNode)

Could you explain the usage of this ( as concrete use case) ? Yes, of course. We can presume that there are:

• ./A/B - list subtree node
• ./A/B/C and ./A/B/D - leaf nodes
• the value of ./A/B/C is C_value, ./A/B/D is D_value The use case:
  1. TR-069 PA receives request GetParameterValues(["A.B"])
  2. TR-069 PA converts the parameter name "A.B" to DMT Uri "./A/B" with the help of the RFC-149 utility.
  3. TR-069 PA checks the type of "./A/B"
  4. It's list subtree node, then collect the child values. They are DmtData("C_value") and DmtData("D_value")
  5. Those values are passed to getTR069ParameterValue utility method
  6. The returned TR069ParameterValue is passed to parser
  7. The parser response is forwarded to transport layer.

Thank you for the usage. Even if the node is list subtree, TR-069 PA needs to get the node type and the MetaNode of the target node. Right ? Actually, the node type is enough in getTR069ParameterValue. The meta node can removed.

I would say a method for handling list subtree interior node and a method for handling leaf node is more simple a little bit, because

• no need to construct DmtData array for every time.
• TR069-PA needs to distinguish them even if ProSyst's proposal.

I had updated the RI based on the discussion. Could you check the source code (src directory) and javadoc (doc directory) in the attached file (the reason why I attached the whole bnd project is I failed to commit SVN) ?

I would like REG member , especially Williams and Evgeni, to review the code regarding binary encoding (base64, bin, hexBinary). Please find "XXX" comments in the source.

Attached file: org.osgi.util.tr069_20100924.zip (application/x-sdlc, 60696 bytes) Description: bnd project including javadoc

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper. Sorry, I forgot it. Yes, the meta node is needed too.

During implementing RI, I found that the node uri is required for FORMAT_NODE_URI (relative path). See the attached javadoc. TR-069 parameter value should be converted to the node URI. Right? Why do we need the node uri? I'll check the implementation. I would say a method for handling list subtree interior node and a method for handling leaf node is more simple a little bit, because

• no need to construct DmtData array for every time.
• TR069-PA needs to distinguish them even if ProSyst's proposal.

I had updated the RI based on the discussion. Could you check the source code (src directory) and javadoc (doc directory) in the attached file (the reason why I attached the whole bnd project is I failed to commit SVN) ? Actually, SVN repository is read only. We must use the GIT repository. For more details see: https://mail.osgi.org/pipermail/reg/2010-May/000727.html https://mail.osgi.org/pipermail/reg/2010-May/000720.html

I would like REG member , especially Williams and Evgeni, to review the code regarding binary encoding (base64, bin, hexBinary). Please find "XXX" comments in the source.
OK, I'll review the attached sources. Do you plan to add some TCs?

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper. Sorry, I forgot it. Yes, the meta node is needed too.

During implementing RI, I found that the node uri is required for FORMAT_NODE_URI (relative path). See the attached javadoc. TR-069 parameter value should be converted to the node URI. Right? Why do we need the node uri? I'll check the implementation.

See Comment#34 in Bug#1672. https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1672#c34

the value ("reference" in TR069 context) specified in SetParameterValues RPC might be relative path. In that case, the value to be set to the corresponding node in DMT must be absolute URI. For converting the relative path to the absolute path, the node uri is needed.

I would say a method for handling list subtree interior node and a method for handling leaf node is more simple a little bit, because

• no need to construct DmtData array for every time.
• TR069-PA needs to distinguish them even if ProSyst's proposal.

I had updated the RI based on the discussion. Could you check the source code (src directory) and javadoc (doc directory) in the attached file (the reason why I attached the whole bnd project is I failed to commit SVN) ? Actually, SVN repository is read only. We must use the GIT repository. For more details see: https://mail.osgi.org/pipermail/reg/2010-May/000727.html https://mail.osgi.org/pipermail/reg/2010-May/000720.html

Thanks for the information. I'll check it later.

I would like REG member , especially Williams and Evgeni, to review the code regarding binary encoding (base64, bin, hexBinary). Please find "XXX" comments in the source.
OK, I'll review the attached sources. Do you plan to add some TCs?

We need CT. If anyone volunteer to implement CT for the Utility class, it would be very appreciated.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

DmtData[] getDmtData(String value, String tr069Type, MetaNode metaNode) seems proper. Sorry, I forgot it. Yes, the meta node is needed too.

During implementing RI, I found that the node uri is required for FORMAT_NODE_URI (relative path). See the attached javadoc. TR-069 parameter value should be converted to the node URI. Right? Why do we need the node uri? I'll check the implementation.

See Comment#34 in Bug#1672. https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1672#c34

the value ("reference" in TR069 context) specified in SetParameterValues RPC might be relative path. In that case, the value to be set to the corresponding node in DMT must be absolute URI. For converting the relative path to the absolute path, the node uri is needed. Thanks for information. I prefer to use TR-069 parameter name in that case i.e. "Device.A" not "./Device/A".

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Created attachment 154 TR-069 Util API (24.09.2010 - ProSyst update)

Please, check my comments, which are marked with //XXX:Evgeni. I hope that they will be helpful.

Attached file: org.osgi.util.tr069_20100924_ProSyst.zip (application/zip, 63689 bytes) Description: TR-069 Util API (24.09.2010 - ProSyst update)

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Created an attachment (id=154) [details] TR-069 Util API (24.09.2010 - ProSyst update) Please, check my comments, which are marked with //XXX:Evgeni. I hope that they will be helpful.

Thank you for your comments. That helps a lot. Based on the comment, I had updated the implementation. I have several questions to confirm and requests.

[getTR069ParameterValue(DmtData data)]

In both case of DmtData.FORMAT_BINARY and DmtData.FORMAT_HEXBINARY, Evgeni wrote "return new TR069ParameterValue(data.toString(), TR069DATATYPE_HEXBINARY);"

DmtData#toString() in Dmt Admin Service Spec Version 1.0 javadoc says "Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces."

Point 1: I'm not sure that "two-digit hexadecimal numbers for each byte separated by spaces" should be set in GetParameteraValuesResponse RPC. Is that what you mean ? >> Evgeni

Anyway, we need to add hexBinary to the description in RFC141. >> Steffen.

Point 2: In the both cases of FORMAT_BASE64 and FORMAT_RAW_BINARY, You did not use "return new TR069ParameterValue(data.toString(), TR069DATATYPE_BASE64);". Instead of it, we use the following codes: value = Base64.byteArrayToBase64(data.getRawBinary()); return new TR069ParameterValue(value, TR069DATATYPE_BASE64); It is consistent behavior ?

[TR069URI.isValidTR069Path(final String tr069Path)]

Evgeni commented "the path element can be a number, in case of Device.LAN.DHCPOption.{i}"

I understand it. However, "3.1 General Notation" in TR106 Amendment3 says "the name of each node in the hierarchy MUST start with a letter or underscore.". Is it a bug of TR-106 ?

Please check my comments "//XXX:Ikuo:20100928:" in the source.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Created attachment 155 TR-069 Util API (29.09.2010 - NTT update)

Sorry. I had forgotten to upload the attachement.

Attached file: org.osgi.util.tr069_20100929.zip (application/x-zip-compressed, 64037 bytes) Description: TR-069 Util API (29.09.2010 - NTT update)

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

[getTR069ParameterValue(DmtData data)]

In both case of DmtData.FORMAT_BINARY and DmtData.FORMAT_HEXBINARY, Evgeni wrote "return new TR069ParameterValue(data.toString(), TR069DATATYPE_HEXBINARY);"

DmtData#toString() in Dmt Admin Service Spec Version 1.0 javadoc says "Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces."

Point 1: I'm not sure that "two-digit hexadecimal numbers for each byte separated by spaces" should be set in GetParameteraValuesResponse RPC. Is that what you mean ? >> Evgeni TR-106 Amendment 3 doesn't specify the hexBinary format. Can somebody give a clarification here? Is it Ok to use hex dump as it is described in the DmtData javadoc?

Anyway, we need to add hexBinary to the description in RFC141. >> Steffen.

Point 2: In the both cases of FORMAT_BASE64 and FORMAT_RAW_BINARY, You did not use "return new TR069ParameterValue(data.toString(), TR069DATATYPE_BASE64);". Instead of it, we use the following codes: value = Base64.byteArrayToBase64(data.getRawBinary()); return new TR069ParameterValue(value, TR069DATATYPE_BASE64); It is consistent behavior ? I think that it is correct only for FORMAT_RAW_BINARY. FORMAT_BASE64 bytes should be placed directly.

[TR069URI.isValidTR069Path(final String tr069Path)]

Evgeni commented "the path element can be a number, in case of Device.LAN.DHCPOption.{i}"

I understand it. However, "3.1 General Notation" in TR106 Amendment3 says "the name of each node in the hierarchy MUST start with a letter or underscore.". Is it a bug of TR-106 ? That description can be extended to point to the rule exception, which is described in the same section: " In some cases, where multiple instances of an object can occur, the placeholder node name “{i}” is shown. In actual use, this placeholder is to be replaced by an instance number "

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Created attachment 157 154: TR-069 Util API (30.09.2010 - ProSyst update)

Please check my comments "//XXX:Ikuo:20100928:" in the source. Please, clone the OSGi Git repository to your PC. I want to fix that API with a review of different patches and commits. I reviewed //XXX:Ikuo:20100928 and add my // XXX:Evgeni:20100929

Attached file: org.osgi.util.tr069_20100930_ProSyst.zip (application/zip, 76697 bytes) Description: 154: TR-069 Util API (30.09.2010 - ProSyst update)

[bjhargrave]

Comment author: wlupton@2wire.com

TR-106 Amendment 3 doesn't specify the hexBinary format. Can somebody give a clarification here? Is it Ok to use hex dump as it is described in the DmtData javadoc?

It's in TR-106 Amendment 4 (the current version). The TR-069 data types are a subset of the SOAP 1.1 data types, which in turn are (mostly) the XML Schema types, so the definition is really that from XML Schema Part 2, http://www.w3.org/TR/xmlschema-2/#hexBinary. I don't think that white space is permitted between the bytes, i.e. I don't think that "41 42" is a valid representation of "AB".

In designing this utility library, have we taken account of the difference between lexical and canonical representations? If not, do we need to? This is illustrated by hexBinary, in which the lexical representation allows upper- or lower-case Hex digits, but the canonical representation requires upper-case Hex digits. In general I think we should probably accept any valid lexical representation (supplied via SetParameterValues) and generate only the canonical representation (returned via GetParameterValues). The canonical representation is always a subset of the lexical representation. Do we also need to consider whitespace?

---

[TR069URI.isValidTR069Path(final String tr069Path)]

Evgeni commented "the path element can be a number, in case of Device.LAN.DHCPOption.{i}"

I understand it. However, "3.1 General Notation" in TR106 Amendment3 says "the name of each node in the hierarchy MUST start with a letter or underscore.". Is it a bug of TR-106 ? That description can be extended to point to the rule exception, which is described in the same section: " In some cases, where multiple instances of an object can occur, the placeholder node name “{i}” is shown. In actual use, this placeholder is to be replaced by an instance number "

I don't think of this as an "exception". The "{i}" is used in data model definitions because of course the definition of a table row applies to all rows. Instance numbers are used at run time (so TR-069, which defines the protocol, does not mention the "{i}" placeholder).

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Created an attachment (id=157) [details] 154: TR-069 Util API (30.09.2010 - ProSyst update)

Please check my comments "//XXX:Ikuo:20100928:" in the source. Please, clone the OSGi Git repository to your PC. I want to fix that API with a review of different patches and commits. I reviewed //XXX:Ikuo:20100928 and add my // XXX:Evgeni:20100929

Although I had been struglling to set up Git, I finally succeeded to commit the project for the utility class, which we are discussing in Bug#1739.

• topic branch "ikuo/tr069util"
• project name "org.osgi.util.tr069"

I'm sorry that the revised RFC and the code does not take comment#17 into account yet. I'll think about it from now on.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

For the preparation of REG F2F in Heidelberg.

TR-106 Amendment 3 doesn't specify the hexBinary format. Can somebody give a clarification here? Is it Ok to use hex dump as it is described in the DmtData javadoc?

It's in TR-106 Amendment 4 (the current version). The TR-069 data types are a subset of the SOAP 1.1 data types, which in turn are (mostly) the XML Schema types, so the definition is really that from XML Schema Part 2, http://www.w3.org/TR/xmlschema-2/#hexBinary. I don't think that white space is permitted between the bytes, i.e. I don't think that "41 42" is a valid representation of "AB".

TO DO (for me):

• Fix the RI of RFC149 for hexBinary (currently RI uses DmtData#toString() , which returns value using space as a separator).

How to fix must be determined in REG F2F.

In designing this utility library, have we taken account of the difference between lexical and canonical representations? If not, do we need to? This is illustrated by hexBinary, in which the lexical representation allows upper- or lower-case Hex digits, but the canonical representation requires upper-case Hex digits. In general I think we should probably accept any valid lexical representation (supplied via SetParameterValues) and generate only the canonical representation (returned via GetParameterValues). The canonical representation is always a subset of the lexical representation. Do we also need to consider whitespace?

[bjhargrave]

Comment author: wlupton@2wire.com

I said that I would summarise the conclusions from the discussion that we had about XML value representation, whitespace etc

• the PA will receive SPV requests, from which it will extract parameter values

• these values can be anything that is valid for the corresponding SOAP data type

• note that the data type can be inferred from the XML itself via the xsi:type attribute, and from metadata supplied by the DP

  • the PA is assumed to collapse whitespace (as defined by XML Schema) before passing the value to the DMTData constructor

• the simple rule is that this whitespace processing needs to be done for all but xs:string

• the set of valid values is the same as that of the corresponding data type (as defined by XML Schema); for example, hexBinary and numeric values cannot contain embedded spaces

• for GPV, the PA is required to use canonical representation (as defined by XML Schema), e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values

• note that DMTData.toString() methods can be assumed to return canonical representation

[bjhargrave]

Comment author: wlupton@2wire.com

One other thing. Please note that XML Schema permits more than just "0" and "1" for Boolean: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean.

So "true" and "false" need to be supported at the XML level (and indeed are the canonical representation). Do these values need to be supported at the DMTData level?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

One other thing. Please note that XML Schema permits more than just "0" and "1" for Boolean: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean.

So "true" and "false" need to be supported at the XML level (and indeed are the canonical representation). Do these values need to be supported at the DMTData level? IMO, the DmtData boolean support is flexible enough. That scenario should be full y managed by PA.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

One other thing. Please note that XML Schema permits more than just "0" and "1" for Boolean: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean.

So "true" and "false" need to be supported at the XML level (and indeed are the canonical representation). Do these values need to be supported at the DMTData level? IMO, the DmtData boolean support is flexible enough. That scenario should be full y managed by PA.

I agree with Evgeni. I'll add the followings to RFC149:

• PA should translate it properly in either cases.
• TR069ParameterValue#getDmtData/getDmtDataForList must handle it properly in either cases.

I said that I would summarise the conclusions from the discussion that we had about XML value representation, whitespace etc

• the PA will receive SPV requests, from which it will extract parameter values

• these values can be anything that is valid for the corresponding SOAP data type

• note that the data type can be inferred from the XML itself via the xsi:type attribute, and from metadata supplied by the DP

  • the PA is assumed to collapse whitespace (as defined by XML Schema) before passing the value to the DMTData constructor

Is TR069ParameterValue#getDmtData/getDmtDataForList responsible for it or not?

• the simple rule is that this whitespace processing needs to be done for all but xs:string

It means no whitespace processing will be done for "xs:string", does it ?

• the set of valid values is the same as that of the corresponding data type (as defined by XML Schema); for example, hexBinary and numeric values cannot contain embedded spaces

• for GPV, the PA is required to use canonical representation (as defined by XML Schema), e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values

Again, Is TR069ParameterValue#getTR069ParameterValue/getTR069ParameterValueForList responsible for it or not?

• note that DMTData.toString() methods can be assumed to return canonical representation

In 117.13.4.42 public String toString( ) of Dmt Admin Service Spec Ver1.0, --begin quote--- Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. --end quote--- Unfortunately, RFC141 ver 1.10.0 lacks it.

Do you mean it needs to be updated as the following ?

Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. For FORMAT_HEXBINARY, it is represented by two-digit hexadecimal numbers for each byte without spaces in canonical representation(the lower case hexadecimal digits ([a-f]) are not allowed).

[bjhargrave]

Comment author: wlupton@2wire.com

• the PA is assumed to collapse whitespace (as defined by XML Schema) before passing the value to the DMTData constructor

Is TR069ParameterValue#getDmtData/getDmtDataForList responsible for it or not?

I think that, having agreed that TR069ParameterValue#getDmtData/getDmtDataForList is NOT responsible for supporting the XML Schema requirement for Boolean "true" / "false", it makes sense to agree that these methods are also not responsible for any XML Schema specific requirements.

Therefore I think that the PA needs to be responsible for all such processing, i.e. the whitespace processing described here, and the other canonical representation things listed below.

• the simple rule is that this whitespace processing needs to be done for all but xs:string

It means no whitespace processing will be done for "xs:string", does it ?

right

• for GPV, the PA is required to use canonical representation (as defined by XML Schema), e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values

Again, Is TR069ParameterValue#getTR069ParameterValue/getTR069ParameterValueForList responsible for it or not?

by the above discussion, no

• note that DMTData.toString() methods can be assumed to return canonical representation

by the above discussion, this can NOT be assumed

In 117.13.4.42 public String toString( ) of Dmt Admin Service Spec Ver1.0, --begin quote--- Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. --end quote--- Unfortunately, RFC141 ver 1.10.0 lacks it.

Do you mean it needs to be updated as the following ?

Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. For FORMAT_HEXBINARY, it is represented by two-digit hexadecimal numbers for each byte without spaces in canonical representation(the lower case hexadecimal digits ([a-f]) are not allowed).

Firstly, this is surely wrong for BASE64 data, which is not represented using Hex digits (each ASCII character represents 6 bits, so a group of 4 ASCII characters represents 24 bits or 3 bytes). So the existing Dmt Admin text re BASE64 needs to be reviewed.

Secondly, if we have agreed that the Java methods are not responsible for the XML Schema requirements, (a) we shouldn't refer to "canonical representation" (unless we define it), and (b) we don't need to forbid the space separators for HexBinary (although we might still want to).

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

• the PA is assumed to collapse whitespace (as defined by XML Schema) before passing the value to the DMTData constructor

Is TR069ParameterValue#getDmtData/getDmtDataForList responsible for it or not?

I think that, having agreed that TR069ParameterValue#getDmtData/getDmtDataForList is NOT responsible for supporting the XML Schema requirement for Boolean "true" / "false", it makes sense to agree that these methods are also not responsible for any XML Schema specific requirements. I completely agree that TR Utility classes should NOT be responsible for any XML Schema specific requirements. There will be a parser, which can manage it.

Therefore I think that the PA needs to be responsible for all such processing, i.e. the whitespace processing described here, and the other canonical representation things listed below.

• the simple rule is that this whitespace processing needs to be done for all but xs:string

It means no whitespace processing will be done for "xs:string", does it ?

right

• for GPV, the PA is required to use canonical representation (as defined by XML Schema), e.g. upper-case Hex letters in hexBinary, and no leading zeroes in numeric values

Again, Is TR069ParameterValue#getTR069ParameterValue/getTR069ParameterValueForList responsible for it or not?

by the above discussion, no

• note that DMTData.toString() methods can be assumed to return canonical representation

by the above discussion, this can NOT be assumed

In 117.13.4.42 public String toString( ) of Dmt Admin Service Spec Ver1.0, --begin quote--- Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. --end quote--- Unfortunately, RFC141 ver 1.10.0 lacks it.

Do you mean it needs to be updated as the following ?

Binary - including FORMAT_RAW_BINARY - and base64 data is represented by two-digit hexadecimal numbers for each byte separated by spaces. For FORMAT_HEXBINARY, it is represented by two-digit hexadecimal numbers for each byte without spaces in canonical representation(the lower case hexadecimal digits ([a-f]) are not allowed).

Firstly, this is surely wrong for BASE64 data, which is not represented using Hex digits (each ASCII character represents 6 bits, so a group of 4 ASCII characters represents 24 bits or 3 bytes). So the existing Dmt Admin text re BASE64 needs to be reviewed. In my opinion, DmtData.toString() unifies the string representation of all types to hex dump. It includes base 64 bytes. I agree that it's a little bit strange, but the fix can break the backward compatibility.

Secondly, if we have agreed that the Java methods are not responsible for the XML Schema requirements, (a) we shouldn't refer to "canonical representation" (unless we define it), and (b) we don't need to forbid the space separators for HexBinary (although we might still want to).

[bjhargrave]

Comment author: wlupton@2wire.com

Firstly, this is surely wrong for BASE64 data, which is not represented using Hex digits (each ASCII character represents 6 bits, so a group of 4 ASCII characters represents 24 bits or 3 bytes). So the existing Dmt Admin text re BASE64 needs to be reviewed. In my opinion, DmtData.toString() unifies the string representation of all types to hex dump. It includes base 64 bytes. I agree that it's a little bit strange, but the fix can break the backward compatibility.

I think this makes sense if DmtData.toString() is intended just to represent the DmtData object as a string IGNORING THE FORMAT. If it is intended to honour the format then it is rather strange, because the only distinction between BASE64 and HEX_BINARY is the string representation!

I guess this just underlines the fact that treating BASE64 and HEX_BINARY as independent formats is rather strange, but this is something that we are perpetuating because it has already been done for BASE64.

I certainly agree that we shouldn't break backwards compatibility. So probably all that needs to be done is to make it clear (if not already clear) that DmtData.toString() for binary data returns the same string representation regardless of the format.

(I would think that the PA would probably choose not to use the toString() method in this case, but to convert the binary data directly. Is there or should there be a TR-069-specific utility method for this?)

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Firstly, this is surely wrong for BASE64 data, which is not represented using Hex digits (each ASCII character represents 6 bits, so a group of 4 ASCII characters represents 24 bits or 3 bytes). So the existing Dmt Admin text re BASE64 needs to be reviewed. In my opinion, DmtData.toString() unifies the string representation of all types to hex dump. It includes base 64 bytes. I agree that it's a little bit strange, but the fix can break the backward compatibility.

I think this makes sense if DmtData.toString() is intended just to represent the DmtData object as a string IGNORING THE FORMAT. If it is intended to honour the format then it is rather strange, because the only distinction between BASE64 and HEX_BINARY is the string representation!

I guess this just underlines the fact that treating BASE64 and HEX_BINARY as independent formats is rather strange, but this is something that we are perpetuating because it has already been done for BASE64.

I certainly agree that we shouldn't break backwards compatibility. So probably all that needs to be done is to make it clear (if not already clear) that DmtData.toString() for binary data returns the same string representation regardless of the format.

So do we agree that ?

In 117.13.4.42 public String toString( ) of Dmt Admin Service Spec Ver1.1 will be updated , --begin quote--- Binary - including FORMAT_RAW_BINARY - , base64 and hexBinary data is represented by two-digit hexadecimal numbers for each byte separated by spaces. --end quote---

(I would think that the PA would probably choose not to use the toString() method in this case, but to convert the binary data directly. Is there or should there be a TR-069-specific utility method for this?)

There is no utility method so far. However, TR069ParameterValue#getTR069ParameterValue() impl needs it internally (I did not implement it yet, though). Do we need it as utility method ?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Firstly, this is surely wrong for BASE64 data, which is not represented using Hex digits (each ASCII character represents 6 bits, so a group of 4 ASCII characters represents 24 bits or 3 bytes). So the existing Dmt Admin text re BASE64 needs to be reviewed. In my opinion, DmtData.toString() unifies the string representation of all types to hex dump. It includes base 64 bytes. I agree that it's a little bit strange, but the fix can break the backward compatibility.

I think this makes sense if DmtData.toString() is intended just to represent the DmtData object as a string IGNORING THE FORMAT. If it is intended to honour the format then it is rather strange, because the only distinction between BASE64 and HEX_BINARY is the string representation!

I guess this just underlines the fact that treating BASE64 and HEX_BINARY as independent formats is rather strange, but this is something that we are perpetuating because it has already been done for BASE64.

I certainly agree that we shouldn't break backwards compatibility. So probably all that needs to be done is to make it clear (if not already clear) that DmtData.toString() for binary data returns the same string representation regardless of the format.

So do we agree that ?

In 117.13.4.42 public String toString( ) of Dmt Admin Service Spec Ver1.1 will be updated , --begin quote--- Binary - including FORMAT_RAW_BINARY - , base64 and hexBinary data is represented by two-digit hexadecimal numbers for each byte separated by spaces. --end quote--- It's fine to me.

(I would think that the PA would probably choose not to use the toString() method in this case, but to convert the binary data directly. Is there or should there be a TR-069-specific utility method for this?)

There is no utility method so far. However, TR069ParameterValue#getTR069ParameterValue() impl needs it internally (I did not implement it yet, though). Do we need it as utility method ? I think no, TR069ParameterValue#getTR069ParameterValue() impl should do that.

[bjhargrave]

Comment author: Kai Hackbarth <k.hackbarth@prosyst.com>

2Wire, ProSyst and NTT agree on Ikuo's proposal!

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Just minor confirmation.

• IMO, TR069ParameterValue.getTR069ParameteValuesForList(DmtData[] data) is not responsible for checking whether the all items of the specified array have the same format. Is that fine for others ?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Just minor confirmation.

• IMO, TR069ParameterValue.getTR069ParameteValuesForList(DmtData[] data) is not responsible for checking whether the all items of the specified array have the same format. Is that fine for others ? Fine to me. If we add that verification, we need to check meta node too... It's OK to skip the check with an appropriate javadoc description.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Just minor confirmation.

• IMO, TR069ParameterValue.getTR069ParameteValuesForList(DmtData[] data) is not responsible for checking whether the all items of the specified array have the same format. Is that fine for others ? Fine to me. If we add that verification, we need to check meta node too... It's OK to skip the check with an appropriate javadoc description.

REG conf call Dec 1 2010, REG agreed it.