[Css-csts] RE: Action Item #03-0511S

[Martin Karch]

Dear John,

sorry for my late response, here are the answers to your questions:

I have checked the book as it was changed during the Berlin meeting, and the ASN.1 change with respect to published identifier is as follows:

PublishedName ::= VisibleString (FROM (ALL EXCEPT "."))
was changed to
PublishedIdentifier ::= OBJECT IDENTIFIER


What concerns the list names, I can give you the following examples from the ASN.1:


ListOfParameters              ::=   CHOICE

{     defaultList             [0]   NULL

,     parameterNames          [1]   SEQUENCE OF PublishedIdentifier

,     listName                [2]   PublishedIdentifier

}

here the listName was originally of the type PublishedName.

Also in the socnd example the listName was originally of the type PublishedName:

NotificationStartInvocExt           ::= SEQUENCE

{     listOfEvents                  CHOICE

{     defaultList             [0]   NULL  -- See 4.10.4.1.2.2.2

,     eventNames              [1]   SEQUENCE OF PublishedIdentifier

,     listName                [2]   PublishedIdentifier

}

,     extensionParameter            Extended

}


Best regards,
Martin



________________________________
From: John Pietras [mailto:john.pietras at gst.com]
Sent: 21 July 2011 19:30
To: Martin Karch
Cc: css-csts at mailman.ccsds.org
Subject: RE: Action Item #03-0511S

Martin,
According to the minutes of the Berlin meeting, the decision was made to recast the type of PublishedName from Visible String to Object Identifier, not necessarily to rename the type. Has the ASN.1 also now been changed from PublishedName to something else (e.g., PublishedIdentifer)?

Also, a related question - presumably, the list names will now also be OIDs. Will they now be called "list identifiers"?

Thanks.

Best regards,
John

From: Martin Karch [mailto:martin.karch at vega.de]
Sent: Tuesday, July 12, 2011 12:08 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: Action Item #03-0511S

Dear John,

thank you very much for your proposal of the concept decriptions in 'PublishedNamesConceptSections-2011-0531.doc'.


We have the following comment:
the proposed description should refer to 'Published Identifiers' rather than to 'published names', as in Berlin we have agreed to use 'Published Identifiers', which are of the type Object Identifier. In the meantime the following definition was added in the Book:
"Published Identifier: a unique identifier that allows identification of a parameter or an event. This unique identifier is allocated by the Space Assigned Number Authority (SANA)."

May we ask you to modify the proposed concept description accordingly.

If nobody complains, we will then integrate the proposed concept descriptions into the Book.


Many thanks in advance!

Best regards,
Martin


________________________________
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 31 May 2011 17:20
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Action Item #03-0511S
CSTSWG colleagues ---
Action item #03-0511S states "JP will provide the text for the Cyclic Report, Information Query, and the Notification Concept about 'published names'." The action resulted from (a) the concern that the early statements to the effect that the Complex publishes the parameter names underplays the possibility that the service specification itself could define the names, and (b) the recognition that in addition to the Cyclic Report and Notification procedures, the Information Query procedure also relies on the use of published names of queriable parameters.

I have uploaded the file PublishedNamesConceptsSections-2011-0531.docx to the Red-1 Framework Review May 2011 folder of the CWE at URL

http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/Red-1%20Framework%20Review%20May.2011/PublishedNamesConceptsSections-2011-0531.docx

Please note that I have also deleted the following Note from the Notification procedure Concept section:
"NOTE   -             It is possible for a notification-enabled CSTS to have a published event list name that represents an event list that contains events that do not have their own published names. For example, a particular notification-enabled CSTS may allow subscription to certain event groups but not to some or all of the individual events that constitute that group. In such cases, event names must be defined for these events (even though they are not published) so that they are commonly understood by both Service User and Service Provider. If a given notification-enabled CSTS allows event lists to represent notifiable events that are not individually publishable, the definition of those non-publishable names is controlled by the specification of that CSTS."

I seem to recall that we discussed this possibility at some point, and that we (the CSTSWG) agreed that this was too complicated. That is, any parameter/event that can be subscribed to via a list name should also be able to be subscribed to individually. If I am remembering that conclusion incorrectly, the Note should remain in the Notification section and similar notes added to the Information Query and Cyclic Report sections.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110805/5e94ba43/attachment-0001.html