[Css-csts] opaqueString value possible for Cyclic Report? - further questions

[John Pietras]

CSTSWG colleagues ---

Last Friday I sent the message below, which raised my concern about the possibility of the intended syntax of the data parameter not being enforced. I have come up with a few more questions regarding this parameter, especially with regard to how the type of the parameter might evolve through successive generations of services being derived. 

 

The following set of assertions comprise what I *think* the rules regarding the data parameter are, but I am not sure if anyone else agrees. I am eager to hear your comments.

 

1.	For a service that is composed of procedures that are adopted, derived, or constructed from Framework procedures and/or operations, the service must either specify that the data parameter is octet-string-valued and refine its definition (e.g., formatted as a CCSDS Transfer Frame) or specify it as an extended type and specify the syntax, transfer syntax, and syntax identifier. The NULL choice for the Extended type is not permitted.
2.	For a service that is derived from a (parent) CSTS for the data parameter is defined as an octet-string, the child service may only further refine the definition of that octet string. The parent definition of the refinement must still be applicable. For example, a data parameter refined as “The name of a city” can be further refined as “The name of a city in North America”, but it cannot be refined as “The name of an automobile”.
3.	For a service that is derived from a (parent) CSTS for the data parameter is defined as an Extended type, the child service may only further extend the definition of that parameter, and only if the specification of the parent service’s syntax for that data parameter has extension capabilities. The parent definition of the extension must still be applicable. For example, consider a parent service in which the data parameter of an operation is extended to make it vector-valued, where each element of the vector is defined as a sequence of an integer value and an extended parameter that may take a null value. A child service of that parent may extend the elements, but it cannot go back to an earlier extension point (that is, one that was exposed to the parent or another ancestor).

 

Is this consistent with everyone’s understanding? I think that this needs to be addressed in the Guidelines, so the sooner we can confirm this (or correct it) the sooner I can finish the next draft of the Guidelines.

 

Best regards,

John

 

 

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Friday, November 20, 2009 4:03 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] opaqueString value possible for Cyclic Report?

 

CSTSWG colleagues ---

I hope that I am merely misunderstanding something, but it just now seems possible to me for the data parameter of the TRANSFER-DATA operation of the Cyclic Report procedure to have an octet-string value (via the opaqueString choice), even though our intention is that it have the QualifiedParameters syntax. That is to say, the ASN.1 CyclicReportTransferDataExt extension type extends the possible values to include the qualifiedParameter choice but it does not inhibit the opaqueString choice. 

 

Is my interpretation correct? If so, is the following statement in section 4.7.3.2 in the main text:

“The TRANSFER-DATA shall be refined as required in ‎3.9 to carry the selected parameters (names, type, value and qualifier) using the qualified-parameters parameter (see annex ‎B).”

sufficient to ensure that an implementation of the Cyclic Report procedure will not encode the data parameter as an octet string?

 

I realize that the book has already gone to the Secretariat for preparation as a Red Book. If there is a problem here, we would have to deal with it in the RID process.

 

Best regards,

John

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

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