search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

Format, RFC141 is going to define #1562

Closed bjhargrave closed 13 years ago

bjhargrave commented 14 years ago

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

bjhargrave commented 14 years ago

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

REG is now going to define MIME type in RFC149. I have two issues to be determined.

  1. Should the name of MIME type contain "tr069" ?

    In BundleFest, we had proposed "application/vnd.osgi.tr069" However, IMO, the types we are going to define do NOT depend on "tr069". But I understand Peter's opinion "It is not mandatory for DMT Admin." Therefore, how about "application/vnd.osgi.dmtree.residential" ?

  2. What should we do for the other generic data types, which TR069 does not use ? For instance, unsignedShort.

Please check the email from William on June 10th to REG ML, whose title was "Re: [reg] ToDo regarding RFC140/141/149".

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Here is the relevant section from the email that Ikuo mentioned:

I was thinking that for the primitive data types we could support:

So now we have MIME types for all the primitive data types that are supported by the data model plugin, and we know that this covers all the data types that are used by all the remote management protocols that we currently care about.

In addition, for each remote management protocol, we define the mapping between the protocol-independent MIME types and the protocol's supported primitive data types. For example, for TR-069, osgi/unsignedShort might map to unsignedInt (TR-069 has no unsignedShort).

The result is that data plugins always treat the data as being of the type that was specified in the data model definition, protocol dependence is kept out of the data plugin, and knowledge about mapping to protocol-specific types is kept in the protocol adapters.

I think this works. Consider the above example. The data plugin has an unsignedShort parameter. When the ACS writes a value it uses an unsignedInt, but restricts the value to [0:65535] because that's the range implied by the data model definition. The protocol adapter receives the value and converts from unsignedInt[0:65535] to unsignedShort. When the ACS reads a value, the unsignedShort from the data plugin is converted to unsignedInt[0:65535].

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Adding text of email message just sent to the REG list by Peter Kriens:

I think it is better to have tr069 in the name, this MIME type is specific for the private communication between the TR069 protocol adapter and data plugins having some relation with tr069. That is the plugins work perfectly well in Dmt Admin without TR069 and are therefore not TR069 specific but they can provide hints to the protocol adapter when it is tr069. So imho this is VERY TR069 specific, so I'd like to stick to the original name.

Data types that TR069 does not use are irrelevant in this scenario.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Peter,

Please could you address the points in comment BZ#1, in which I would like to draw attention to:

"The result is that data plugins always treat the data as being of the type that was specified in the data model definition, protocol dependence is kept out of the data plugin, and knowledge about mapping to protocol-specific types is kept in the protocol adapters"

?

Surely we all agree that it is a good thing to keep protocol dependence out of the data plugin.

Thanks, William

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Oops. The message in comment BZ#2 was not sent to the REG list but to some REG members.

bjhargrave commented 14 years ago

Comment author: @pkriens

I think that the data plugin is already dependent on Broadband Forum when it implements one of its data models, it tree it encodes is defined there and its data types. Using the MIME types we can use generic Dmt Admin tools not having to worry about these details while we have a precise mapping for the cases a Data Plugin needs to map to an exact TR 069 type that does not have a unique mapping to a Dmt Admin type.

Adding the MIME types does not introduces a new coupling, that coupling is already present in the tree structure that must map to a BBF defined layout. Adding a data type mapping is a small additional cost that I think is worth paying for the preciseness we achieve. However, from this perspective it just does not make sense to just add yet another set of datatypes, the MIME types must exactly match the TR069 types for this to be useful.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

I think the key point is whether the data plugin is already dependent on BBF. My hope and assumption was that it is NOT dependent on BBF.

The real work of defining a data model is in deciding how to model the underlying concepts, and in coming up with clear and simple object descriptions. The main areas where it is impossible completely to avoid management protocol dependence are:

  1. object naming and addressing: the data model definition will use the management protocol's node naming and addressing conventions

  2. data types: the data model definition will use the data types that are supported by the management protocol

  3. references: the values of reference parameters will be management protocol path names

  4. comma-separated lists: such lists may be represented using management protocol specific mechanisms

So I see it as our job to define a canonical representation that is used by the data plugins and can be mapped (by the protocol adapter) to and from the management protocol representation.

We have already done that in several areas, e.g. at the data plugin level, object paths follow OMA-DM conventions (./Device/XXX rather than Device.XXX), and we have decided how to handle comma-separated lists. Now we are talking about the data types.

I don't think that my suggestion makes things any less precise. I think it's just another means of achieving the same end. We can define all the same types, I just don't want to call them TR-069 types.

bjhargrave commented 14 years ago

Comment author: @pkriens

The canonical representation is Dmt Admin types ... Any drive that is oblivious of TR069 will not have to do anything but can still be transported because for each DMT Admin data type there is an appropriate mapping.

The problem we are trying to solve here, at least in my understanding, is how we can ensure that a BBF driver actual can implement a BBF specification through DMT Admin.

The data types will be 100% DMT Admin, however, the MIME type provides a mapping (it can actually provide several different MIME types for different protocols) so that he driver know exactly what type it should use in TR069. Maybe in some cases it would also provide a mapping simultaneously for SNMP or some other management protocol.

Dmt Admin tried to make an all encompassing data type set and as we have seen failed. Any new standard will invent new types, you cannot handle that generically.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

It seems to me the question is where the mapping should take place. I would prefer:

To me this suggests defining a set of protocol-independent MIME types. The MIME types that we are talking about are probably exactly the same in both cases; it's just a question of what we call them.

This may seem like a small point, but it means that, to support a new protocol, you only need to define a new MIME type if a suitable one doesn't already exist. This seems preferable to me.

bjhargrave commented 14 years ago

Comment author: @pkriens

It seems to me the question is where the mapping should take place. I would prefer:

  • the TR-069 mapping to take place within the TR-069 protocol adapter, But that is where it takes place ... Unfortunately, TR069 requires "knowledge" of the type that is transiting. Putting the knowledge of a specific driver X in the a generic TR069 protocol adapter would be very very very bad. Dmt Admin has the your desired catch-all useful for anybody complete full set of data types ... at least that is what they thought at the time. Unfortunately TR069 has a few quirks that make them map almost, but that is not good enough. The MIME types are a very elegant solution where the driver (who has intricate knowledge of the details) can provide a hint. I'd much rather have them 100% specific so that the mapping is exact than that we try to create yet another set of data types ...

To me this suggests defining a set of protocol-independent MIME types. The MIME types that we are talking about are probably exactly the same in both cases; it's just a question of what we call them. I disagree, I think it is important that the driver can distinguish between hints for TR069, SNMP, etc.

This may seem like a small point, but it means that, to support a new protocol, you only need to define a new MIME type if a suitable one doesn't already exist. This seems preferable to me. It think it ends up being fuzzy and in the end will create a large set of uncohesive types.

So we seem to disagree :-)

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Yes, we seem to disagree ... but constructively! I am going to split this comment into two parts, a short one and a long one.

-------- short --------

Our devices support many TR-069 parameters, of which many are served by native code, and only some by Java (OSGi) code. Our TR-069 agent is currently and will continue to be a native application. It contains all the TR-069 knowledge and uses a private internal protocol (I will call it protocol XXX) for communicating with other system components. There are other non-TR-069 management agents that use protocol XXX, and protocol XXX knows nothing of TR-069, although of course there are some similarities, e.g. it has the same basic "set", "get", "create", "delete" operations, and the supported data types are roughly equivalent.

The TR-069 agent will use protocol XXX to communicate with a DMTAdmin protocol adapter, but this isn't a TR-069 PA, it's a protocol XXX PA. I hope this explains why we would prefer to avoid having any mention of TR-069 at the data plugin level.

-------- long --------

It seems to me the question is where the mapping should take place. I would prefer:

  • the TR-069 mapping to take place within the TR-069 protocol adapter, PK: But that is where it takes place ... Unfortunately, TR069 requires "knowledge" of the type that is transiting.

WL: Yes, when TR-069 encodes an XML message to send to the WAN it needs to know the primitive TR-069 data type. But all this requires is that the set of data types defined for use at the DP level is at least as rich as the set of TR-069 data types. Consider the following four cases:

  1. TR-069 PA, BBF data model
  2. TR-069 PA, non-BBF data model
  3. Other PA, BBF data model
  4. Other PA, non-BBF data model

At the DP level the data types are all DMT data types, so conceptually DMT_int, DMT_unsignedInt etc, so let's assume that there is one of these for each TR-069 data type, plus another, DMT_other, that is not supported by TR-069.

Case 1: DP types are DMT_int (for TR-069 int) etc. 1-1 mapping. No problem. Case 2: DP types could include DMT_other. TR-069 PA knows that TR-069 doesn't support this and so applies TR-069-specific generic policy to represent as an appropriate TR-069 type. Case 3: Really the same as case 2, because if PA doesn't support a type it will have to apply its own policy to map the value. Case 4: Presents no new issues.

So the bottom line (not surprisingly) is that either the PA can handle the type directly or else it has to map it to/from a type that it understands. I just don't see the problem.

PK: Putting the knowledge of a specific driver X in the a generic TR069 protocol adapter would be very very very bad. Dmt Admin has the your desired catch-all useful for anybody complete full set of data types

WL: Yes, but where am I proposing to put knowledge of a specific driver (by which I assume you mean DP) in a particular PA? I agree that this would be bad!

PK: ... at least that is what they thought at the time. Unfortunately TR069 has a few quirks that make them map almost, but that is not good enough. The MIME types are a very elegant solution where the driver (who has intricate knowledge of the details) can provide a hint. I'd much rather have them 100% specific so that the mapping is exact than that we try to create yet another set of data types ...

WL: But what are the quirks? The TR-069 primitive data types are a subset of the SOAP data types, and the SOAP data types are the XML Schema data types. For example a TR-069 unsignedInt is EXACTLY the same as an XML Schema unsignedInt. Why insist on calling it "TR-069 unsigned int" when it's just an unsigned int? The same goes for all the other TR-069 primitive types.

To me this suggests defining a set of protocol-independent MIME types. The MIME types that we are talking about are probably exactly the same in both cases; it's just a question of what we call them. PK: I disagree, I think it is important that the driver can distinguish between hints for TR069, SNMP, etc.

WL: Perhaps we are getting to the heart of the problem here. I think that you are assuming that a DP for a data model that was originally defined by BBF will be implemented differently from a DP for a data model that was originally defined by (say) OMA-DM. I don't see it that way. I see ANY data model definition as being CONCEPTUALLY converted to a DMTAdmin (protocol-independent) data model definition before being implemented. Nearly all of this is just mapping path names and data types, and the rules are all generic ones (we have already defined some of them, for comma-separated lists and references). This is the point I was trying to make in comment BZ#6.

bjhargrave commented 14 years ago

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

I agree with William. I think the mime types defined in Bug#1672 does not depend on TR-069 at all. They are generic ones.

Yes, we seem to disagree ... but constructively! I am going to split this comment into two parts, a short one and a long one.

-------- short --------

Our devices support many TR-069 parameters, of which many are served by native code, and only some by Java (OSGi) code. Our TR-069 agent is currently and will continue to be a native application. It contains all the TR-069 knowledge and uses a private internal protocol (I will call it protocol XXX) for communicating with other system components. There are other non-TR-069 management agents that use protocol XXX, and protocol XXX knows nothing of TR-069, although of course there are some similarities, e.g. it has the same basic "set", "get", "create", "delete" operations, and the supported data types are roughly equivalent.

The TR-069 agent will use protocol XXX to communicate with a DMTAdmin protocol adapter, but this isn't a TR-069 PA, it's a protocol XXX PA. I hope this explains why we would prefer to avoid having any mention of TR-069 at the data plugin level.

-------- long --------

It seems to me the question is where the mapping should take place. I would prefer:

  • the TR-069 mapping to take place within the TR-069 protocol adapter, PK: But that is where it takes place ... Unfortunately, TR069 requires "knowledge" of the type that is transiting.

WL: Yes, when TR-069 encodes an XML message to send to the WAN it needs to know the primitive TR-069 data type. But all this requires is that the set of data types defined for use at the DP level is at least as rich as the set of TR-069 data types. Consider the following four cases:

  1. TR-069 PA, BBF data model
  2. TR-069 PA, non-BBF data model
  3. Other PA, BBF data model
  4. Other PA, non-BBF data model

At the DP level the data types are all DMT data types, so conceptually DMT_int, DMT_unsignedInt etc, so let's assume that there is one of these for each TR-069 data type, plus another, DMT_other, that is not supported by TR-069.

Case 1: DP types are DMT_int (for TR-069 int) etc. 1-1 mapping. No problem. Case 2: DP types could include DMT_other. TR-069 PA knows that TR-069 doesn't support this and so applies TR-069-specific generic policy to represent as an appropriate TR-069 type. Case 3: Really the same as case 2, because if PA doesn't support a type it will have to apply its own policy to map the value. Case 4: Presents no new issues.

So the bottom line (not surprisingly) is that either the PA can handle the type directly or else it has to map it to/from a type that it understands. I just don't see the problem.

PK: Putting the knowledge of a specific driver X in the a generic TR069 protocol adapter would be very very very bad. Dmt Admin has the your desired catch-all useful for anybody complete full set of data types

WL: Yes, but where am I proposing to put knowledge of a specific driver (by which I assume you mean DP) in a particular PA? I agree that this would be bad!

PK: ... at least that is what they thought at the time. Unfortunately TR069 has a few quirks that make them map almost, but that is not good enough. The MIME types are a very elegant solution where the driver (who has intricate knowledge of the details) can provide a hint. I'd much rather have them 100% specific so that the mapping is exact than that we try to create yet another set of data types ...

WL: But what are the quirks? The TR-069 primitive data types are a subset of the SOAP data types, and the SOAP data types are the XML Schema data types. For example a TR-069 unsignedInt is EXACTLY the same as an XML Schema unsignedInt. Why insist on calling it "TR-069 unsigned int" when it's just an unsigned int? The same goes for all the other TR-069 primitive types.

To me this suggests defining a set of protocol-independent MIME types. The MIME types that we are talking about are probably exactly the same in both cases; it's just a question of what we call them. PK: I disagree, I think it is important that the driver can distinguish between hints for TR069, SNMP, etc.

WL: Perhaps we are getting to the heart of the problem here. I think that you are assuming that a DP for a data model that was originally defined by BBF will be implemented differently from a DP for a data model that was originally defined by (say) OMA-DM. I don't see it that way. I see ANY data model definition as being CONCEPTUALLY converted to a DMTAdmin (protocol-independent) data model definition before being implemented. Nearly all of this is just mapping path names and data types, and the rules are all generic ones (we have already defined some of them, for comma-separated lists and references). This is the point I was trying to make in comment BZ#6.

bjhargrave commented 14 years ago

Comment author: Andreas Kraft <a.kraft@telekom.de>

I agree with Ikuo and William. We had a lot of discussions whether to keep protocol knowledge in the data plugin or not. We decided to keep the knowledge in the management agent part. This now also means to have some knowledge about type conversions. Example: If you want to set/access values from a GUI you need to convert strings to integer and vice versa. We should use common data types as much as possible and only define our own when absolutely necessary (e.g. CSV).

I agree with William. I think the mime types defined in Bug#1672 does not depend on TR-069 at all. They are generic ones.

bjhargrave commented 14 years ago

Comment author: @pkriens

Question. We support driver D and protocol OMA DM, SNMP, and TR069. Assume we have data field f. f is defined as SEQUENCE OF BOOLEAN in SNMP, FORMAT_INTEGER in OMA DM/DMT Admin, and comma separated field of "true" or "false" in TR069.

OMA DM -> FORMAT_INTEGER -> FORMAT_INTEGER SNMP -> FORMAT_INTEGER -> SEQUENCE OF BOOLEAN TR069 -> FORMAT_INTEGER -> comma separated list of booleans

Now we have field g that must map:

OMA DM -> FORMAT_INTEGER -> FORMAT_INTEGER SNMP -> FORMAT_INTEGER -> INTEGER TR069 -> FORMAT_INTEGER -> UNSIGNED LONG

Can anyone explain to me how each driver knows how to map to its native type if we leave out the native protocol type identifier from the MIME name?

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

My short answer is that a given parameter is defined only once and that the parameter definition determines how the value is represented in the protocol for which it was originally defined.

I think that it is unacceptable for the data model definition to specify the parameter value representation in each protocol. How can we know which protocols will need to be supported when we create the data model definition?

In other words I don't think it's meaningful to say <<defined as SEQUENCE OF BOOLEAN in SNMP, FORMAT_INTEGER in OMA DM/DMT Admin, and comma separated field of "true" or "false" in TR069>>.

For the long answer, please see inline discussion of comment BZ#13 below:

Question. We support driver D and protocol OMA DM, SNMP, and TR069. Assume we have data field f. f is defined as SEQUENCE OF BOOLEAN in SNMP, FORMAT_INTEGER in OMA DM/DMT Admin, and comma separated field of "true" or "false" in TR069.

OMA DM -> FORMAT_INTEGER -> FORMAT_INTEGER SNMP -> FORMAT_INTEGER -> SEQUENCE OF BOOLEAN TR069 -> FORMAT_INTEGER -> comma separated list of booleans

WL: Please bear in mind that the data model will have been defined in the first place either with a single protocol in mind (e.g. TR-069) or else with no protocol in mind (i.e. defined specifically for use with DMTAdmin). If defined with a single protocol in mind, the data model definition will have been mapped to DMTAdmin concepts, AND THIS MAPPING MUST BE DONE IN SUCH A WAY THAT THIS PROTOCOL'S PROTOCOL ADAPTER WILL MAP BACK TO THE APPROPRIATE REPRESENTATION IN THIS PROTOCOL.

WL: To make this more explicit, assume that the data model was defined in the first place for OMA DM. In OMA DM it's represented as an integer, and the parameter definition will indicate this, e.g. will explain that each bit conceptually represents a Boolean but that the representation is an integer. All protocols will represent it as an integer. This is correct. It IS an integer.

WL: But now assume that the data model was defined in the first place for TR-069 and that that the data model author decided (as you suggest) to represent it as a comma-separated list of booleans. Now we need to indicate this at the data plugin level, presumably as discussed in Girona, so there will be an interior node with a leaf node per value. The protocol adapters will see that it's a list and so will represent it in the appropriate way for the protocol, which for TR-069 will be the comma-separated list of Booleans that was originally specified in the TR-069 data model definition.

WL: The above two cases result in different representations but THIS DOESN'T MATTER, because we are talking about two different data model definitions and therefore about TWO DIFFERENT PARAMETERS.

Now we have field g that must map:

OMA DM -> FORMAT_INTEGER -> FORMAT_INTEGER SNMP -> FORMAT_INTEGER -> INTEGER TR069 -> FORMAT_INTEGER -> UNSIGNED LONG

Can anyone explain to me how each driver knows how to map to its native type if we leave out the native protocol type identifier from the MIME name?

WL: Let's assume that g was originally defined for TR-069 as an unsignedLong (64 bit). So the fact that it's natively an UNSIGNED LONG needs to be known at the driver level (and available via metadata). The TR-069 protocol adapter will map that to TR-069 unsignedLong. It's up to the other protocol adapters how to represent it in their protocols.

WL: Now assume that g was originally defined for SNMP as an integer (signed 32 bit). Similarly the driver will know that it's INT and the TR-069 protocol adapter will map it to int, not to unsignedLong because IT ISN'T AN UNSIGNED LONG.

WL: Again, we are talking about two different data model definitions and therefore about two different parameters.

bjhargrave commented 14 years ago

Comment author: @pkriens

So in your reasoning the MIME type is ONLY needed for the exact mapping to the driver's native protocol, which argues for a protocol specific MIME type?

If a parameter has one, and only one, data model definition than it only needs be transported exactly over its native protocol. The protocol adapter derives its information from Dmt Admin and that information is sometimes insufficient because the mapping Format -> native type is not complete.

A "generic protocol", for example a GUI should base itself on Dmt Admin. With such a protocol it is not necessary to exactly follow the native data models because any conversion will happen through Dmt Admin and the data plugin. For example, an unsigned int would be read and written as a long in this GUI, which would be fine because when it is transported over TR069 it will be typed as an unsigned int. Sticking to the Dmt Admin types (and constraints) would therefore not require any additional MIME types.

From the discussions I start to understand that the MIME type is not wanted to do exact native mapping but it is felt that Dmt Admin is not rich enough for other use cases. Now I am not arguing the Dmt Admin is perfect. If there is a shortcoming in the types of Dmt Admin then we should address this in Dmt Admin and NOT create an alternative MIME based type system. Having two type parallel systems will be really confusing.

So I'd rather add unsigneds to Dmt Data formats than create MIME types for them. Marking a node as a "LIST" is on the edge for me because I think all nodes have lists with their children, only TR069 needs to know that some of these lists have to be encoded in strings with comma separated fields and others just as children. That seems more an oddity in TR069 than a shortcoming in Dmt Admin? However, forced to choose between a generic MIME type for this concept or some Dmt Admin extension I'd prefer Dmt Admin extension.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

I think we are homing in on agreement here, and that the outstanding disagreement is well represented by the LIST discussion

here is how I see things progressing in support for lists:

  1. current DMTAdmin; lists are represented as node trees; no special behaviour

  2. need to support TR-069, for which some lists will be comma-separated; define LIST MIME type; for data models originally defined for BBF, associate LIST MIME type with BBF comma-separated lists

  3. need to support protocol XXX, for which some lists are comma-separated and others are colon-separated; define LIST2 MIME type; for data models originally defined for protocol XXX, associate LIST MIME type with comma-separated lists and LIST2 MIME type with colon-separated lists

now we have the granularity in the data model definition to describe the different behaviour needed by the various protocol adapters:

  1. OMA-DM protocol adapter ignores the LIST and LIST2 MIME types

  2. TR-069 protocol adapter honours the LIST MIME type (and either ignores or honours the LIST2 MIME type, which can occur only in data models originally defined for protocol XXX; if it honours it, it probably treats it the same as LIST; this TR-069 protocol adapter behaviour needs standardising?)

  3. protocol XXX protocol adapter honours the LIST and LIST2 MIME types

I believes that this meets the requirement stated below that "the MIME type is ONLY needed for the exact mapping to the driver's native protocol"

also see more detailed inline comments below for background

So in your reasoning the MIME type is ONLY needed for the exact mapping to the driver's native protocol, which argues for a protocol specific MIME type? WL: yes to the first bit (if by "driver's native protocol" you mean "protocol for which the data model was originally defined"); no to the second, because don't want any protocol dependence in the data plugin

If a parameter has one, and only one, data model definition than it only needs be transported exactly over its native protocol. The protocol adapter derives its information from Dmt Admin and that information is sometimes insufficient because the mapping Format -> native type is not complete. WL: agreed

A "generic protocol", for example a GUI should base itself on Dmt Admin. [...] WL: that assumes that the "generic protocol" doesn't already exist; in the general case I think it does already exist (just as TR-069 already exists) and so needs to be accommodated

From the discussions I start to understand that the MIME type is not wanted to do exact native mapping but it is felt that Dmt Admin is not rich enough for other use cases. [...] WL: basically agree here

So I'd rather add unsigneds to Dmt Data formats than create MIME types for them. WL: great!

Marking a node as a "LIST" is on the edge for me because I think all nodes have lists with their children, only TR069 needs to know that some of these lists have to be encoded in strings with comma separated fields and others just as children. That seems more an oddity in TR069 than a shortcoming in Dmt Admin? WL: yes and no; not just TR-069; for example you suggested yesterday that a protocol might support TWO types of lists, a comma-separated one and a colon-separated one; so I see it just as a recognition that conversions may be necessary

However, forced to choose between a generic MIME type for this concept or some Dmt Admin extension I'd prefer Dmt Admin extension. WL: not sure whether you mean here that the Dmt Admin extension should be protocol-specific or protocol-neutral

bjhargrave commented 14 years ago

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

[Summary for the hot discussion so far]

=================================================================== (Agreed)Add the followings to the DmtData Formats:

FORMAT_UNSIGNED_LONG
FORMAT_UNSIGNED_INTEGER
FORMAT_DATE_TIME
FORMAT_HEXBINARY(?)

That must be described in RFC141, and DMT Admin Service Spec in future.

=================================================================== (To be confirmed)

Q1. Should "REFERENCE" be handled by new DmtData FORMAT or MIMETYPE ?

Q2. Should "LIST" be handled by new DmtData FORMAT or MIMETYPE ?

Q3. If any of them will needs MIMETYPE, which RFC will describe the definition of the MIMETYPE ?

===================================================================

bjhargrave commented 14 years ago

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

=================================================================== (My opinion For Q1)

As for REFERENCE, I prefer FORMAT(e.g. FORMAT_REFERENCE_STRING).

(My opinion For Q2)

As for LIST, I don't understand the discussion among Peter and William completely. Why does the the following idea meet all our requirements ?

1) When TR-069 Protocol Adapter(PA) receives GetParameterValues RPC, it will check the FORMAT of the path. If it is an interior node and the FORMAT of it is LIST, it will get the values from all child nodes of the interior node and construct the Comma-Separated List String, and return it to the ACS.

2) When TR-069 PA receives SetParameterValues RPC, it will check the FORMAT of the path. If it is an interior node and the FORMAT of it is LIST, it will deconstruct the Comma-Separeted List String to the each elements. Then it will check the FORMAT of the child nodes of the interior node and cast the String to the FORMAT before calling DmtSesssion#setNodeValue().

3) When TR-069 PA receives any of DmtEvent/ADDED/DELETED/REPLACED, it will check the FORMAT of the parent node, which fires the Event. If it is LIST, then it will construct the Comma-Separated List String and the Notification will be fired to ACS appropriately, where the Notification was fired by the parent node.

4) If there exists other Remote Management Protocol, which needs other LIST (e.g. semi-colum separated list), the PA for it translate the node values to the semi-colum separated list, as TR-069 PA does.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

(In reply to comment BZ#17 and comment BZ#18)

Thanks Ikuo. Here are some 2Wire comments.

(Agreed)Add the followings to the DmtData Formats: FORMAT_UNSIGNED_LONG FORMAT_UNSIGNED_INTEGER FORMAT_DATE_TIME FORMAT_HEXBINARY(?)

Currently FORMAT_BINARY maps to OMA-DM "bin" and FORMAT_BASE64 maps to OMA-DM "b64", which means "binary but transferred as BASE64". We think that this means that we DO need FORMAT_HEXBINARY. We also think that a new constructor will be required, since the existing DmtData(byte[] bytes, boolean base64) can only handle BINARY and BASE64. We suggest DmtData(byte[] bytes, int format).

(My opinion For Q1)

As for REFERENCE, I prefer FORMAT(e.g. FORMAT_REFERENCE_STRING).

We are fine with this.

(My opinion For Q2)

As for LIST, I don't understand the discussion among Peter and William completely. Why does the the following idea meet all our requirements ?

  • First, let us assume that An interior node has child nodes, each of which contains each element of the list.
  • The interior node must not have value but its MetaNode#getFormat() must returns "FORMAT_LIST".

We think that all interior nodes need to use FORMAT_NODE, so your FORMAT_LIST proposal is (unfortunately) not permitted. It is also not possible to use the MIME type, because for an interior node this needs to reference an OMA-DM DDF.

We propose instead requiring the DP to support a complex value in this case, i.e. having getNodeValue() return a Java.util.List object.

A TR-069 PA that wants to access a list-valued parameter will realise that the parameter maps to an internal node and so will know that it's special. It can then attempt to read it as a complex value, at which point if a Java.util.List object is returned it will know that it's a list.

We believe that it will not be possible to use a complex value when writing a list-valued parameter because this would break the rule that setting a complex value is not allowed to create new nodes. So a TR-069 PA that wants to write a list-valued parameter will need to (a) read it in order to discover that it's list-valued, and (b) manipulate the individual leaf nodes to write it.

bjhargrave commented 14 years ago

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

[Discussion Conclusion of REG F2F in Athens]

[Summary for the hot discussion so far]

(Agreed)Add the followings to the DmtData Formats: FORMAT_UNSIGNED_LONG FORMAT_UNSIGNED_INTEGER FORMAT_DATE_TIME FORMAT_HEXBINARY(?)

FORMAT_HEXBINARY is newly defined. DmtData( byte[] bytes, int format) is newly defined, where format must be any of FORMAT_BINARY, FORMAT_BASE64, or FORMAT_HEXBINARY.

That must be described in RFC141, and DMT Admin Service Spec in future.

=================================================================== (To be confirmed) Q1. Should "REFERENCE" be handled by new DmtData FORMAT or MIMETYPE ?

FORMAT_REREFENCE is newly defined and DmtData(String value, int format) will be used to construct the format(JavaDoc must be updated).

Q2. Should "LIST" be handled by new DmtData FORMAT or MIMETYPE ?

Neither new FORMAT or MIMETYPE will be added. Just new "URI identifying an OMA DM Device Description Framework (DDF) file" for the list interior node.

Q3. If any of them will needs MIMETYPE, which RFC will describe the definition of the MIMETYPE ?

=====================================================================

RFC141 and new Dmt Admin Spec will define the followings:

A: new FORMATs: FORMAT_UNSIGNED_LONG FORMAT_UNSIGNED_INTEGER FORMAT_DATETIME FORMAT_HEXBINARY FORMAT_REREFENCE_STRING

B: new "URI identifying an OMA DM Device Description Framework (DDF) file" for the list interior node. C: How to implement DataPlugins which want to support list:

D: How to implement Protocol Adapters or Local Managers who want to modify the list subtree.

===================================================================

If I miss anything, please point it out.

bjhargrave commented 14 years ago

Comment author: jblackford@2wire.com

Just to clarify 2 sub-points in comment BZ#20:

C: How to implement DataPlugins which want to support list:

  • The interior node should have MIMETYPE which B defines.

  • MetaNode for the child leaf node should be supported, even if no child leaf nodes exist. (PA can get the Format of the child leaf node by using "<>".)

  • For internal change of the leaf nodes, the DmtEvent with DELETED for the all existing nodes should be fired first and then the DmtEvent with ADDED for all new nodes should be fired, even if some leaf nodes do not change actually. (in order to keep same behaivior for D)

The "- The interior node should have MIMETYPE which B defines." should not mention MIMETYPE, but instead should state that "- The interior node should return the URI specified in B as a result of having getNodeType called"

The "(PA can get the Format of the child lead node by using "<>".)" should not place "<>" in quotes as this is not the literal string that is in there. The <> needs to be replaced by any child name, which would be an integer.

bjhargrave commented 14 years ago

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

The "- The interior node should have MIMETYPE which B defines." should not mention MIMETYPE, but instead should state that "- The interior node should return the URI specified in B as a result of having getNodeType called"

Agreed.

The "(PA can get the Format of the child lead node by using "<>".)" should not place "<>" in quotes as this is not the literal string that is in there. The <> needs to be replaced by any child name, which would be an integer.

No. Since there might no child node exist at the moment, Therefore PA might be unable to call the DmtSession method with the arguemnt including concrete integer as the URI of the child nodes.

The following the sample code where it is assumed that the URI specified in B is "URI_FOR_LIST" and TR-069 PA receives SetParameterValue RPC (the path "A.B" and the value as the String receivedStringValue).

String receivedStringValue = .....;

booelean leafFlag = dmtSession.isLeaf("./A/B"); if(leafFlag){ // create the leaf node with the receivedStringValue to the node "./A/B"; return; } String type = dmtSession.getNodeType("./A/B"); if(type!=URI_FOR_LIST){ // may do something. return; }

String[] elements = parseCommaSeparatedList(receivedStringValue );

// all existing child nodes must be deleted first. String[] childNodeNames = dmtSession.getChildNodeNames("./A/B"); for( each childNodeNames ) dmtSession.deleteNode("./A/B"+childNodeNames[i]); }

// then create leaf nodes with parsed values. MetaNode metaNode = dmtSession.getMetaNode("./A/B/<>"); int format = metaNode.getFormat(); switch(format){ DmtData.FORMAT_INT: for( each elements ){ int value = Integer.parseInt(elements[i]); DmtData data = new DmtData(value); dmtSession.createInteriorNode("./A/B/"+i,data); } break;

DmtData.FORMAT_LONG: ..... }

I had updated the description based on the first comment:

=====================================================================

RFC141 and new Dmt Admin Spec will define the followings:

A: new FORMATs: FORMAT_UNSIGNED_LONG FORMAT_UNSIGNED_INTEGER FORMAT_DATETIME FORMAT_HEXBINARY FORMAT_REREFENCE_STRING

B: new "URI identifying an OMA DM Device Description Framework (DDF) file" for the list interior node. C: How to implement DataPlugins which want to support list:

D: How to implement Protocol Adapters or Local Managers who want to modify the list subtree.

===================================================================

bjhargrave commented 14 years ago

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

The "- The interior node should have MIMETYPE which B defines." should not mention MIMETYPE, but instead should state that "- The interior node should return the URI specified in B as a result of having getNodeType called"

Agreed.

The "(PA can get the Format of the child lead node by using "<>".)" should not place "<>" in quotes as this is not the literal string that is in there. The <> needs to be replaced by any child name, which would be an integer.

No. Since there might no child node exist at the moment, Therefore PA might be unable to call the DmtSession method with the arguemnt including concrete integer as the URI of the child nodes.

Node meta data can be accessed for missing nodes. I think that we can economize the special string "<>". As a part of the javadoc of DmtSession.getMetaNode(String): "

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

Node meta data can be accessed for missing nodes. I think that we can economize the special string "<>".

This string "<>" is mentioned in figure 117.8 (section 117.5) and section 117.5.3.2. However I think that we established last week that it is intended only as a typographic convention and that an implementation would permit (and require) a valid node name (i.e. a name that is syntactically valid, even though it need not reference an existing node), and not the literal string "<>".

For example, any string matching the pattern /\d+/ (unsigned integer) (*) would be a valid list entry leaf node name.

Do others share this opinion? If so, do we agree that the spec needs to be clearer here?

(*) the actual pattern in this case might be more complex because we might want to forbid unnecessary leading zeroes in order to avoid having to worry whether "7" and "007" reference the same node

bjhargrave commented 14 years ago

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

Hmm, this seams a matter of interpretation of the Dmt Admin Service Spec Version 1.0.

First, let me clarify each ones' opinions.

There are two interpretations

[A] DmtSession#getMetaNode(String) can take "./A/B/<>" as its argument.

That means, the method returns the MetaNode of the child node of "./A/B", even if no child node exists at the moment.

The section "117.4.1 The DMT Addressing URI" says that "Names that are restricted to the URI set [-a-zAZ0- 9_.!~*'()] are most efficient." Therefore, the node name of "<>" is assumed as the reserved name for that usage (DmtSession#getMetaNode()). IMO, there is no contradiction in the current spec.

[B] DmtSession#getMetaNode(String) can NOT take "./A/B/<>" as its argument. The actual argument should have the concrete node name, i.e "./A/B/1", even if the node of the specified URI does not exist at the moment.

John and William is for B, while Ikuo(I) is for A.

I'm not sure whether Evgeni is for A. Evgeni, Which do you support ?

========================================================================= [My opinion]

In either case, we can realize the list subtree:

The MetaNode of the leaf in the list subtree must isZeroOccurrenceAllowed( ) returns 0 and getMaxOccurrence( ) returns more than 1. Since the "117.13.10.16 public int getMaxOccurrence( )" says "Note that if the occurrence is greater than 1 then this node can not have siblings with different metadata."

However, if we take B, some restriction against the argument URI for the list leaf node should be clarified in the spec as William proposed in Comment#24. For example, it is so strange if DmtSession#getMetaNode("./A/B/hogehoge"), the node name is not the numeric one, returns valid MetaNode. In addition, what will be returned if the MaxOccurence is 10 and DmtSession#getMetaNode("./A/B/20") ? Those detail behavior should be clarified for "the list subtree specific restriction" in the new spec.

On the other hand, if we take A, no restriction against the argument URI. Just add the clarification on the usage of "<>" string in the argument of DmtSession#getMetaNode() and ReadableSession#getMetaNode() not for "the list subtree specific restriction" but for "the Meta Data generic usage".

Therefore, I prefer A.

bjhargrave commented 14 years ago

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

Hmm, this seams a matter of interpretation of the Dmt Admin Service Spec Version 1.0.

First, let me clarify each ones' opinions. The best approach in this situation.

There are two interpretations

[A] DmtSession#getMetaNode(String) can take "./A/B/<>" as its argument.

That means, the method returns the MetaNode of the child node of "./A/B", even if no child node exists at the moment.

The section "117.4.1 The DMT Addressing URI" says that "Names that are restricted to the URI set [-a-zAZ0- 9_.!~*'()] are most efficient." Therefore, the node name of "<>" is assumed as the reserved name for that usage (DmtSession#getMetaNode()). IMO, there is no contradiction in the current spec.

[B] DmtSession#getMetaNode(String) can NOT take "./A/B/<>" as its argument. The actual argument should have the concrete node name, i.e "./A/B/1", even if the node of the specified URI does not exist at the moment.

John and William is for B, while Ikuo(I) is for A.

I'm not sure whether Evgeni is for A. Evgeni, Which do you support ? My vote goes to A. My arguments are below.

========================================================================= [My opinion]

In either case, we can realize the list subtree:

The MetaNode of the leaf in the list subtree must isZeroOccurrenceAllowed( ) returns 0 and getMaxOccurrence( ) returns more than

  1. Since the "117.13.10.16 public int getMaxOccurrence( )" says "Note that if the occurrence is greater than 1 then this node can not have siblings with different metadata."

However, if we take B, some restriction against the argument URI for the list leaf node should be clarified in the spec as William proposed in Comment#24. For example, it is so strange if DmtSession#getMetaNode("./A/B/hogehoge"), the node name is not the numeric one, returns valid MetaNode. In addition, what will be returned if the MaxOccurence is 10 and DmtSession#getMetaNode("./A/B/20") ? Those detail behavior should be clarified for "the list subtree specific restriction" in the new spec. In both cases, DmtException with an error code NODE_NOT_FOUND should be thrown.

On the other hand, if we take A, no restriction against the argument URI. Just add the clarification on the usage of "<>" string in the argument of DmtSession#getMetaNode() and ReadableSession#getMetaNode() not for "the list subtree specific restriction" but for "the Meta Data generic usage".

Therefore, I prefer A. Actually, the question is: How can we specify scaffold node as an internal list node? If we cannot, the scaffold meta node will give us a lot of troubles. Currently, this can be realized on the first registration of data plug-in with URI ./A/B/#. What to do, if the data plug-ins with the given URIs are registered in the sequence: ./A/B/1, ./A/B/5 and ./A/B/#? ./A/B can be internal list after the last registration or the last registration can be skipped and an error can be logged.

bjhargrave commented 14 years ago

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

Thanks for your post, Evgeni.

John and William is for B, while Ikuo(I) is for A.

I'm not sure whether Evgeni is for A. Evgeni, Which do you support ? My vote goes to A. My arguments are below.

So we are on the same side :-)

However, if we take B, some restriction against the argument URI for the list leaf node should be clarified in the spec as William proposed in Comment#24. For example, it is so strange if DmtSession#getMetaNode("./A/B/hogehoge"), the node name is not the numeric one, returns valid MetaNode. In addition, what will be returned if the MaxOccurence is 10 and DmtSession#getMetaNode("./A/B/20") ? Those detail behavior should be clarified for "the list subtree specific restriction" in the new spec.

In both cases, DmtException with an error code NODE_NOT_FOUND should be thrown.

That is so reasonable.

If we take A, how about the following rules, to be clarified in the new Dmt Admin Spec.

  1. If the URI specified by getMetaNode() contains only one "<>" and ends with "/<>", 1-1. If the node is multi node and MetaNode is supported, it returns MetaNode for those multi nodes, whether the specified node exist or not.

    1-2. Else if the node is not multi node and MetaNode is supported, it returns MetaNode for the node, whether the specified node exist or not.

    1-3. Otherwise, it throws DmtException with an error code NODE_NOT_FOUND.

  2. Else if the URI specified by getMetaNode() contains "<>", it throws DmtException with an error code INVALID_URI.

  3. Otherwise, 3-1. If the MetaNode of the node is supported by the DataPlugin, it returns MetaNode for the node, whether the specified node exist or not.

    3-2. Otherwise, it throws DmtException with an error code NODE_NOT_FOUND.

I would like to remark 3-1. Assume that the node "./A/B" is the list subtree and the no leaf node exist. What DmtSession#getMetaNode("./A/B/1") returns depends on the DataPlugin implementation. However, at least, DmtSession#getMetaNode("./A/B/<>") should returns MetaNode.

====================================================================

In Bug#1670, I would like to confirm ONLY the way how to get the MetaNode of the node which does not exist. I'll wait for John and William's confirmation.

Let's discuss the issue of scaffold node in Bug#1717.

bjhargrave commented 14 years ago

Comment author: wlupton@2wire.com

John and William is for B, while Ikuo(I) is for A. We haven't expressed an opinion. We just want to clarify whether it was ever intended that "<>" be supported by the API, or whether it was always intended to refer to a possible node name (whether or not it exists). Peter? [I thought I had posted a similar remark earlier, but I don't see it, so perhaps it never got submitted]

bjhargrave commented 14 years ago

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

Thanks for your post, Evgeni.

John and William is for B, while Ikuo(I) is for A.

I'm not sure whether Evgeni is for A. Evgeni, Which do you support ? My vote goes to A. My arguments are below.

So we are on the same side :-)

I am afraid, that here is my typing mistake. If we can, it will be nice to economize the new special string "<>". I prefer B, the concrete node path like ./A/B/1, where the ./A/B is list subtree. Sorry again :(

bjhargrave commented 14 years ago

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

I'm not sure whether Evgeni is for A. Evgeni, Which do you support ? My vote goes to A. My arguments are below.

So we are on the same side :-)

I am afraid, that here is my typing mistake. If we can, it will be nice to economize the new special string "<>". I prefer B, the concrete node path like ./A/B/1, where the ./A/B is list subtree. Sorry again :(

Too big mistake !

I try to think about the case that we take B.

  1. If the URI specified by getMetaNode() contains any "<>", it throws DmtException with an error code INVALID_URI.

  2. Else If the node specified exist, the MetaNode of the node will be returned.

  3. Else (if the node does not exist), DmtAdmin will check the Node Type of the parent node of it. 3-1. If the type was the LIST_URI, the node must be the leaf node of the list, which means the MetaNode of the leaf node must allow ZeroOccurence and have some MaxOccurence: the leaf node name must be numeric between 0 and MaxOccurence.

    ==> 3-1-1. If the node name was between them (except leading zeros as William mentioned in comment#24), the DataPlugin should return the MetaNode. 3-1.2. Otherwise, the DmtException with an error code NODE_NOT_FOUND will be thrown.

    3-2. Otherwise, the DmtException with an error code NODE_NOT_FOUND will be thrown.

    Is that what you mean ?

bjhargrave commented 14 years ago

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

I try to think about the case that we take B.

  1. If the URI specified by getMetaNode() contains any "<>", it throws DmtException with an error code INVALID_URI.

  2. Else If the node specified exist, the MetaNode of the node will be returned.

  3. Else (if the node does not exist), DmtAdmin will check the Node Type of the parent node of it. 3-1. If the type was the LIST_URI, the node must be the leaf node of the list, which means the MetaNode of the leaf node must allow ZeroOccurence and have some MaxOccurence: the leaf node name must be numeric between 0 and MaxOccurence.

    ==> 3-1-1. If the node name was between them (except leading zeros as William mentioned in comment#24), the DataPlugin should return the MetaNode. 3-1.2. Otherwise, the DmtException with an error code NODE_NOT_FOUND will be thrown.

    3-2. Otherwise, the DmtException with an error code NODE_NOT_FOUND will be thrown.

    Is that what you mean ?

It is OK for me.

bjhargrave commented 14 years ago

Comment author: @pkriens

<> was a place holder, a meta-node can be retrieved with a URI that does not point to any real node. I think this is especially mentioned in the spec. Using <> is just as good as using 666 or this_node_does_exist.

bjhargrave commented 14 years ago

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

<> was a place holder, a meta-node can be retrieved with a URI that does not point to any real node. I think this is especially mentioned in the spec. Using <> is just as good as using 666 or this_node_does_exist.

Do you mean that ?

bjhargrave commented 14 years ago

Comment author: @pkriens

  • if the node "./A/B" has multi child nodes, the getMetaNode("./A/B/<>") should return the MetaNode for them, if the impl of DP supports MetaNode. (using "<>" is especially mentioned in the spec) Yes, but <> was a placeholder, i.e. you can use anything in this place. So "<>" should be ok if the name is allowed on that position. If it had been a literal, it would have been more explicitly mentioned.

  • Even if the node "./A/B/this_node_does_exist" does not exist, what does getMetaNode("./A/B/this_node_does_exist") return depends on the implementation of DataPlugin(DP). The MetaNode just describes what happens at the position, the name is irrelevant. A Data Plugin should not use the last name in any special name, all siblings regardless of their name are assumed to be equal. At least that is how I recall it.

bjhargrave commented 14 years ago

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

  • if the node "./A/B" has multi child nodes, the getMetaNode("./A/B/<>") should return the MetaNode for them, if the impl of DP supports MetaNode. (using "<>" is especially mentioned in the spec) Yes, but <> was a placeholder, i.e. you can use anything in this place. So "<>" should be ok if the name is allowed on that position. If it had been a literal, it would have been more explicitly mentioned.

  • Even if the node "./A/B/this_node_does_exist" does not exist, what does getMetaNode("./A/B/this_node_does_exist") return depends on the implementation of DataPlugin(DP). The MetaNode just describes what happens at the position, the name is irrelevant. A Data Plugin should not use the last name in any special name, all siblings regardless of their name are assumed to be equal. At least that is how I recall it.

Peter, thank you very much for the clarification. Spec already specify that the siblings must have the same MetaNode, if cardinality is more than one (which means multi node). Peter's explanation completely matches it.

Based on the understanding, I revised the description regarding C in comment BZ#22:

=====================================================================

RFC141 and new Dmt Admin Spec will define the followings:

C: How to implement DataPlugins which want to support list:

It gets so simple.

bjhargrave commented 14 years ago

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

In the conf call on Sep 7th, REG agreed:

bjhargrave commented 14 years ago

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

In the discussion on REG ML, we agreed to change the name of FORMAT_REFERENCE to FORMAT_NODE_URI. Due to this change, DmtData.getReference() should be DmtData.getNodeUri().

Assigned to Steffen for updating RFC141 javadoc.

bjhargrave commented 14 years ago

Comment author: Steffen Druesedow <steffen.druesedow@telekom.de>

In the discussion on REG ML, we agreed to change the name of FORMAT_REFERENCE to FORMAT_NODE_URI. Due to this change, DmtData.getReference() should be DmtData.getNodeUri().

Assigned to Steffen for updating RFC141 javadoc.

Done

bjhargrave commented 13 years ago

Comment author: Steffen Druesedow <steffen.druesedow@telekom.de>

done in RFC and RI