[Css-csts] Extension parameters

Tue Aug 25 10:17:21 EDT 2009

Martin,
When I sent out the update of the TD-CSTS White Book late on Sunday night, I had not seen your reply to Tim's note. I therefore used the "transfer-syntax" formulation that is currently specified in the CSTSFW. 

You will see in the TD-CSTS update that I used XML for encoding the extension parameters, with the different extension parameters corresponding to different complex types defined within the context of a TD-CSTS namespace. While I was constructing that XML mapping, I wondered whether it would be possible to declare the whole TD-CSTS XML namespace as a single "transfer syntax". I'm not necessarily proposing that we do this (instead of declaring a different (transfer) syntax for each extension), but I am curious about you thoughts on the feasibility of such an approach. 

Thanks.

Best regards,
John

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Martin Götzelmann
Sent: Saturday, August 22, 2009 3:09 PM
To: Ray, Timothy J. (GSFC-5830); css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Extension parameters

Dear Tim,

It is not clear to me how you want to include the "length-value mechanism" into ASN.1 - somehow you must use an ASN.1 type that a decoder applying BER can recognise. Of course you could replace the type EMBEDDED PDV by OCTET STRING together with the rule that an empty OCTET STRING implies that no extension is used. With a slightly cleaner approach you could use a CHOICE with NULL for "no extension" and OCTET STRING for an externally defined extension. And granted you can design and write your SW in a way that the decoder always knows what is to be expected in the extension - it can decide this using the procedure ID.

These are the reasons why we decided to specify extensions differently.

ASN.1 has mechanisms to say "what follows is specified somewhere else" and the simplest of these is EMBEDDED PDV. If the selected language has such a mechanism, why invent something special for CSTS? (You might not like the selection of the language, but that is a different issue ;-)

Have a closer look at the EMBEDDED PDV specification on page D8/9. Leaving out the "formal decorations" it is defined as

EMBEDDED PDV ::= SEQUENCE {Identification, data-value}

The data-value is an OCTET STRING and I am assuming that you do not have a problem with this (I do not think that there is any other sensible option within ASN.1).

The Identification gives you 6 options to identify the type, among these is "fixed" which is defined as NULL. With this option we would have (nearly) what you are suggesting. 

Originally Yves had suggested to use the option "transfer-syntax" (the book still says so and I will explain later why I think this should be changed). With the identification option "transfer-syntax" you would say how the following data are encoded "on the wire" and this would allow invoking an appropriate decoder that understands and can translate that transfer syntax. Examples for transfer-syntax specifications are ASN.1 BER, ASCII, XML. With this approach all extensions defined within the framework would have the same identifier, because they are all transferred using ASN.1 BER.

On the Colorado Springs meeting I have suggested to change this and to identify the specification of the extension, which implies that you must define an Object identifier for every type that is defined as an extension. The rationale of  this proposal was that it enables you to build more sophisticated infrastructure components to support decoding of types not konown at the time of implementation. For instance, an application using such infrastructure components could register a decoder together with the identification of the type it can decode. The infrastructure component could then decode whatever it understands and if it encounters an object identifier it does not know about, it could check the list of registered decoders and invoke the one that can continue the decoding process. 

I do not think this approach puts an undue burden on simpler implementations. On the decoding side, you can simply ignore the object identifier if you already know what the additional data is. On the encoding side, it just means inserting a well specified additional constant.

Suggested modification of the Framework Book, D1.12

Following the change agreed in Colorado Springs, that the Identifier in the Extended type should identify the specification of the extension rather than the transfer syntax, I believe we should also change clause D1.12 of the Framework to say that the specification shall use the "syntax" option rather than the "transfer-syntax" option. This will not change anything in the encoding as both are of the type OBJECT IDENTIFIER and the choices are not tagged.

Kind Regards, Martin

________________________________

From: css-csts-bounces at mailman.ccsds.org on behalf of Ray, Timothy J. (GSFC-5830)
Sent: Fri 21/08/2009 9:35 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Extension parameters

Dear WG members,

I'm sorry for raising this issue at the eleventh hour.  My understanding of ASN.1 is growing week-by-week, and therefore, the ability to evaluate our specification is growing week-by-week.  I'm concerned that someone who is not an ASN.1 expert will be overwhelmed by our specification, and have a suggestion to simplify one of the trickier parts.  The ideas in this email have been discussed with John Pietras and Muhammad Rabi (he is implementing a rough prototype of the Framework for the Provider side), and we all agree that this issue is worth bringing up to our whole Working Group.

Our current extension-parameter mechanism uses an EmbeddedPDV that is placed inside an 'Extended' structure.  It requires the definition of a transfer-syntax object-identifier for every extension-parameter location.  

As far as I can tell, our services would work just as well if we replaced the 'Extended' structure with a length-value mechanism and removed all the transfer-syntax identifiers.  A 'length' of zero would indicate that an extension is 'not used' (and a 'length' greater than zero would indicate that an extension 'is used').  Decoding of the 'value' would be based on the context.  The next paragraph provides an example to illustrate.

Suppose the Provider receives a Start-Invocation whose Procedure-Instance-Id indicates the Buffered Ascii Data Delivery (BADD) procedure.   The BADD procedure knows that it extends the Buffered Data Delivery (BDD) procedure, which knows that it extends the generic Start-Invocation, so the sequence to be followed in decoding Start-Invocation extensions would be known:

        Generic Start-Invocation -> BDD -> BADD

Because the extension 'length' in the generic Start-Invocation structure is greater than zero, the extension 'value' would be decoded using the format defined at the BDD level.  The extension at the BDD level provides Start and Stop times, and includes another length-value extension.  Because the 'length' in that extension is also greater than zero, the extension 'value' would be decoded using the format defined at the BADD level.  The extension at the BADD level provides a Filename.

The length-value approach seems to work fine as long as the following assumptions are true:

1)      Each level knows "what it extends".  This ensures that the receiver will always know the extension sequence (no matter how many layers of extension there are).

2)      For a given PDU and a given procedure (or service) there is exactly one format for the extension parameter.  For example, the BDD procedure's extension of the Start-Invocation always has the same format, and that format is defined abstractly by 'BuffDataDelStartPosInvocExt'.  This ensures that the receiver will always know how to decode the extension at each level.

Best regards,

Tim

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts