[Css-csts] Extension parameters

Sun Aug 30 06:51:08 EDT 2009

Dear Tim,

What I am thinking of is a "chain of decoders" where the decoder to select next is selected by the object identifier in the EMBEDDED PDV. Of course each of the decoders would have to check the correctness of the syntax and return an error in case of a syntax error. If any of the decoders in the chain detects a problem, the decoding process of course needs to be aborted and the PDU rejected.

As concerns the length/value encoding I believe one needs to consider that every ASN.1 types is encoded as

       <tag> <length> <value>

with an empty OCTET STRING having the length 0. Therefore just specifying an OCTET STRING would do the same job.

Regards, Martin

________________________________

From: css-csts-bounces at mailman.ccsds.org on behalf of Ray, Timothy J. (GSFC-5830)
Sent: Tue 25/08/2009 12:30 AM
To: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Extension parameters

Dear Martin,

Personally, I am willing to accept the approach that you have outlined.  It sounds like you have an elegant design architecture in mind.  Would your intended design architecture handle an incoming pdu that is not properly constructed -- such as a Start-Invocation with an extension parameter whose syntax indicates "Stop-Return-Neg-Ext"?  (I don't have the name quite right, but the point is that some very incompetent implementer accidentally put an extension that is intended for the Stop-Return into a Start-Invocation).  I'm thinking that one can't blindly accept the sender's "syntax" value.

Again, I am willing to back off of my suggestion.  But I would like to answer your question about how the length-value would be incorporated into ASN.1.  There would be a new type (please forgive my syntax if it is sloppy):

    LengthValue ::= SEQUENCE
    {   length         IntUnsigned
    ,   value          OctetString
    }

This type would be used in place of Extended.  A length of zero would indicate "empty". 

Best regards,
Tim

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
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

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