[Css-csts] Extension parameters

[Ray, Timothy J. (GSFC-5830)]

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

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