[Css-csts] Embedded vs. Extended in diagnostic and notification-type extensions - my mistake!

[John Pietras]

CSTSWG colleagues ---

In an email prior to the Berlin meeting, and subsequently recorded as
part of RID NASA-JVP-80, I argued the diagnostic parameter extensions
(item 13 on the list) and notification-type parameter extensions (item
14 on the list) should be of type Embedded, not Extended. The basis of
this argument was the fact that the Extended type can take a NULL value
(actually, notUsed, but I'll return to that later), and an NULL value
should never be possible as a diagnostic value or notification-type
value. Tim Ray took (and completed) the action to find all such
instances and to make the change. 

 

HOWEVER, it is with great embarrassment that I must state that I made a
mistake. My argument was that diagnostic and notification-type should
never allow a null value. But what I failed to remember when I came to
this conclusion is that we need some sort of "end of list" marker for
these lists of values. If we do not have such an end-of-list marker, an
OID for an extension type must always be provided. This, of course,
leads to infinite recursion of extension of these lists. This point was
made obvious to  me as I looked through the ASN.1 sections of several of
the CSTS specifications that I am working on.

 

What needs to be made clear is that in the context of the diagnostic and
notification-type values, notUsed/NULL is never an available value - it
simply delimits the end of the set of available values. I looked through
both the CSTSFW and the Guidelines to see if there was any explanation
of this sort, and I was unable to find any. I think that it would be
most useful to include a comment with the ASN.1 definition of the
Embedded type in annex D2.3, something along the lines of 

"When specified as the value of the diagnosticExtension CHOICE of a
diagnostic parameter or the notificationTypeExtension CHOICE of a
notificationType parameter, the 'notUsed' value indicates that the
operation does not add any extension values to the diagnostic or
notificationType parameter. 'notUsed' is never itself an actual value of
a diagnostic or notificationType parameter."

 

I suppose that it would also be possible to define a slightly different
type in which the NULL choice would be defined more explicitly for this
usage, e.g., something like

 

ExtendedValues  :==  CHOICE

{     external            [0]  Embedded

;     endOfValues  [1]  NULL

}

 

but I understand that at this late date we don't want to create new
types. I think that the continued use of the Extended type will be okay
with a comment along the lines that I proposed above.

 

I apologize to everyone for raising this issue and diverting your
already-over-subscribed time to deal with this (Tim, in particular - I
know that you don't have any cycles to waste).

 

Finally, my revisiting this issue has made me realize that we are not
quite as formally correct in the ASN.1 as we should be. We have many
comments similar to "...diagnosticExtension is set to NULL."
Technically, I think that these statements should be of the form
"...diagnosticExtension is set to notUsed", since "notUsed" is the
semantic value and NULL is merely the encoding of that value. If we
agree that "notUsed" is the proper term to use in these cases, I will
volunteer to make the changes to Annex A after Yves has completed all of
the other changes.

 

 

Best regards,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110613/9fe1e7ab/attachment.htm