[Css-csts] RE: NotificationTypes

[Yves.Doat at esa.int]

Dear John,

I wish you all the best in 2013 with a fantastic Framework Red Book.

I see that you have been working very hard and I really appreciate the
various inputs you submitted.

I cross-checked with Margherita your mails and we agreed on the following:
   The ASN.1 definition is correct;

   The requirement 3.10.2.2.3.5 is a left over from previous definition which
   intended to allow a new service to define events to their liking. With the
   new approach the event definition is contraints by the agreed structure
   starting from Functional Resources. The requirement will be removed.

   The notificationTypeExtension is inserted to allow an event to carry
   additional information. This additional information must be defined at the
   time of event definition.
   A new 3.10.2.2.3.5 has been created :
   "Events defined by the NOTIFY operation may be transferred with additional
   information to be carried by the type notificationTypeExtension."

   The eventValues of the Framework events are specified to contain a null
   value (See requirement 3.10.2.2.3.2). There is no change to the document.

I hope those four points answer your two emails. If you still have a problem
with that approach, please let me know.

Best regards
Yves


                                                                                                                                   
  From:       John Pietras <john.pietras at gst.com>                                                                                  
                                                                                                                                   
  To:         John Pietras <john.pietras at gst.com>, "Yves.Doat at esa.int" <Yves.Doat at esa.int>                                         
                                                                                                                                   
  Cc:         "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>                                             
                                                                                                                                   
  Date:       26/12/2012 16:44                                                                                                     
                                                                                                                                   
  Subject:    RE: NotificationTypes                                                                                                
                                                                                                                                   





Yves,
Another question just occurred to me. The four published events defined for
the NOTIFY operation (production configured, production interrupted,
production halted, and production operational) do not have eventValues
associated with them. Are procedures that use the NOTIFY operation allowed to
add eventValues for one or more of them, or are they restricted to only
having event names? Either way, I think that 3.10 should address it.

John

From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Wednesday, December 26, 2012 10:25 AM
To: Yves.Doat at esa.int
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: [Css-csts] NotificationTypes

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


This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.