[Css-csts] NotificationTypes

[John Pietras]

Yves,
In preparation for writing the new annex that will explain how parameter/event/directive names are formed, I've been reviewing the various sections of the December draft of the CSTS SFW that makes use of those names. In the specification of the NOTIFY operation (3.10), paragraph 3.10.2.2.3.5 states "All procedures shall have the possibility to extend the notification-type parameter with additional event-names".

The specification of the NotificationTypes ASN.1 type in Annex D3.3 is

-- The definition of the Notification types follows the definition in

-- 3.10.2.2.3 and the types are defined by the Object Identifers

-- productionConfigured, productionInterrupted, productionHalted and

-- productionOperational (see C7).

NotificationTypes            ::=   SEQUENCE

{     eventName                     ParamOrEventName

,     eventValue                    CHOICE

{     text              [0]   VisibleString

,     empty             [1]   NULL

}

,     notificationTypeExtension     Extended

}


I may be wrong (very possible since I have been away from this for a while), but there seems to be an inconsistency between paragraph 3.10.2.2.3.5 and the ASN.1 type definition.

My understanding of the approach is that *all* notifiable events are to be defined as (eventName:eventValue) pairs (where eventValue is optional; that is, it may have a null value), and this is consistent with what paragraph 3.10.2.2.3.5 says.

However, the ASN.1 type specification contains the notificationTypeExtension parameter, which seems to add another, different type of extension mechanism that is not otherwise addressed in section 3.10. Furthermore, because NotificationTypes is defined as the SEQUENCE {eventName, eventValue, notificationTypeExtension}, notificationTypeExtension appears to extend the notification named by eventName, and not add a new syntax for defining a notification-type . Is this the intended interpretation of notificationTypeExtension ? If so, then there should probably be some explanation in section 3.10.

Or is the inclusion of the notificationTypeExtension parameter merely an erroneous carry-over from the normal way that parameter extension is provided in the CSTS SFW?

Best regards,
John

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