[Css-csts] ASN.1 modules for non-ASN.1 extensions

[John Pietras]

Yves and Martin,

I'm trying to follow the logical extension and intersection of several threads of yesterday's discussion on the Guidelines, and in particular on the topic of how the formal specification of the extended elements should be documented when the syntax is not ASN.1.  I have some follow-up questions to pose to you and the other members of the working group. 

 

Before posing my questions, let me recap some background and context:

a)  We all agreed that an ISO Service Object Identifiers module is needed to specify the service type and the requires subtrees. The questions and ambiguities have to do with the specification of the extensions. 

 

b)  In an earlier correspondence between myself and Yves regarding the nature of the extensions module, I proposed and Yves agreed that rather than having a single extension module for all extensions of all extended procedures, there should be a separate module for each extended procedure. The following discussion is therefore stated in terms of specifications organized around extended procedures (and not all extension lumped together). 

 

c) We agreed that for the case that the CSTS specification uses a non-ASN.1 syntax to specify the extensions, the Guidelines need only specify what has to be defined in the specification of such a syntax, but not it's representation, which, of course, cannot be anticipated by the Guidelines.

 

 

1. My first question is: when a CSTS specifies the extensions of an extended procedure in something other than ASN.1, do we need an ISO OID for the specification of the collcection of information assocaited with that extended procedure (i.e., the equivalent of the procedure PDU module)? Presumably, the procedure PDU module is given an OID so that it can be registered (in the CSTS case, with SANA), so the need to give it a formal reference. Is it our assumption that that reference is always in the form of an ISO OID, or do we allow the possibility of using an alternate "registration tree" that is still maintained by SANA, e.g., an XML namespace?

 

2. A closely-related question is: given that each procedure that extends a Framework procedure must define an ISO OID for each extension type, should each such extension type be expressed via ASN.1? The important characteristic of the extension type identifer is that when it gets transferred it has the (transfer) syntax of an OID, so theoretically an extension type specified in a non-ASN.1 syntax could simply define the type ID in terms of the octet string that results from the BER encoding of the OID. However, it might be easiest to express these extension type OIDs using ASN.1, even if the syntax (and transfer syntax) of the extended types themselves are not expressed via ASN.1 (and encoded via BER).

 

3. My third question is: what about the cases when the procedure is either (a) extended by addition of operation(s) to a Framework or parent procedure, or (b) 

the procedure is service-original? In those cases, the component PDUs of the extended/original procedure need to be specified.

 

4. My final question applies to the specification of the PDU type of a procedure that is derived from another procedure by adding one or more operations to those of the parent procedure. I *think* that such a type has to be defined on the basis of the CstsFrameworkPdu type, with all component operations specified. For clarity, the comments could identify which operations are inherited from the parent procedure and which are new to the procedure.

 

 

Given these various considerations, I propose the following approach:

1. For every extended or service-original procedure an ASN.1 module be included in the service specification. That module will have an ISO OID for registration purposes.

2. The "PDU" type for the procedure is declared as an ASN.1 type (Since it is defined as a refinement of the already-defined CstsFrameworkPdu type, there are no transfer syntax considerations). 

3. If the syntax and transfer syntax of the extension types are ASN.1 and BER (respectively), the module will contain a comment to that effect.

4. If the syntax and transfer syntax of the extension types are *not* ASN.1 and BER, the module will contain commetns that unambiguously identify the document that specifies the syntax and transfer syntax) (e.g., another normative annex of the CSTS specification). The form of that non-ASN.1 extension type syntax documentation is unspecified by the Guidelines.

5. For each message type (invocation, return, acknowledgement) of each operation, the extensions are identified (or stated that ther are no extensions). For each extension type, the extension type OID is specified using ASN.1 syntax. 

a) If the extension type itself is to be BER-encoded, the extension type is defined using ASN.1 and the comment is added that the reansfer syntax is BER.

b) If the extension type istelf is to be defined using another syntax and transfer syntax, the module shall reference (in the form of a comment) the document that contains the specification of the syntax and transfer syntax of the extension type, and the name of that extension type as it is stated in that document . 

 

Does this sound like a reasonable approach? Can you think of any problems with it?

 

Best regards,

John

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100714/afa84968/attachment.html