[Css-csts] Extensions in abstract service specifications

[Martin Götzelmann]

Dear John,
 
The example that triggered the proposal to foresee specification of an "abstract service" is the hypothetical "Return Space Link Data" CSTS I tried to describe in the in the Concepts Book. This service is abstract mainly (there are other aspects) because it does not specify the  the data that are to be transmitted - derived services will narrow the specification to identify frames (with various selection criteria), possibly just blocks of bytes (if this approach is used used for RUFT), or OCFs. 
 
Not defining the data to be transmitted seems to imply a number of things:
a) First of all, the exact meaning of the "data" parameter is unspecified and that alone means the service cannot be implemented as specified;
b) using earlier versions of the Framework, the syntax of the data parameter was unspecified; in the current version there is an optional syntax specification (the OCTET STRING), but derived services could opt for a different syntax depending on the data they are dealing with;
c) depending on the data a derived service deals with, there might be more parameters to add to START and TRANSFER-DATA (e.g. selected VC IDs) and there might be additional notifications and diagnostics - but all of this is just standard extension of operations.
 
In this specific case the incompletely defined parameter "data" has been inherited from the buffered data delivery procedure, but I do not think we can exclude that an abstract service needs to add parameters that are incompletely defined both with respect to semantics and syntax. 
 
On the other hand I feel that we do not need to spell out in any detail what elements of the description can be omitted by an abstract service. I think it would be OK just to say that if any of these definitions can only be omitted for an abstract service and then it must be specifically said that the service is abstract and that the omitted definition must be provided by derived services.
 
Does this make any sense to you?
 
Kind Regards, Martin


________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 17 November 2009 23:49
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Extensions in abstract service specifications



CSTSWG colleagues -

I am in the process of updating the Guidelines to reflect the Noordwijk comments. I have come across an issue that I hope we can resolve via email.

 

The problem involves what, if anything, can be omitted from the specification of an extension when the service is abstract. Under the Extending Operations section in the in-progress version of the Guidelines states the following, which are intended for concrete services:

3.9.1        The invocation, positive result return, negative result return, positive result acknowledgement, or negative result acknowledgement for an operation of a CSTS may add one or more new parameters in the following way:

a)   The new parameters shall be identified (named), along with their respective types, value ranges, and units;

b)   The syntax and the transfer syntax (see reference [1]) of the new parameters shall be defined;

NOTE   -    The syntax identifier for a parameter (see [1]) identifiers both the syntax and the transfer syntax of that parameter. 

c)   If additional extension parameters are to be supported for services that may be derived from the CSTS, the transfer syntax shall specify how such extension parameters are to be accommodated; and

d)   The new parameters shall be defined with respect to applicability to the operation invocation, acknowledgement, or return.

3.9.2        The values of the diagnostic component of the result parameter of the negative return or negative acknowledgement for an operation for a CSTS may be extended in the following way:

a)   The new values shall be identified (named);

b)   The syntax and transfer syntax of the new values shall be defined;

c)   A 'diagnostic extension' value may be included in the set of extended diagnostic values; if so, the transfer syntax shall specify how such extended diagnostic values are to be accommodated; 

d)   The new diagnostic value(s) must be specified as to which negative result it(they) pertain(s): acknowledgement or return; and 

e)   New diagnostic values must be defined as being the content of the 'diagnostic extension' value of the diagnostic parameter of the operation return. 

3.9.3        The values of the notification-type parameter of a NOTIFY operation invocation for a CSTS may be extended in the following way:

a)   The new values must be identified (named);

b)   The syntax and transfer syntax of the new values must be defined; and

c)   A 'notification type extension' value may be included in the set of extended notification type values; if so, the transfer syntax shall specify how such extended notification type values are to be accommodated.

 

 

The next paragraph currently also goes on to say that for an abstract service specification, all of these things are not necessary. In effect, it says that:

a)       An abstract service can add a new parameter by identifying (naming) it and specifying whether it applies to the invocation, acknowledgement, or return, but the specification of the syntax and transfer syntax and extension mechanism can be deferred to a concrete derived service specification;

b)      An abstract service can added a new diagnostic value by identifying (naming) it and specifying (where applicable) whether it applies to the acknowledgement or return, but the specification of the syntax and transfer syntax and extension mechanism can be deferred to a concrete derived service specification; and

c)       An abstract service can added a new notification-type value by identifying (naming) it and specifying (where applicable) whether it applies to the acknowledgement or return, but the specification of the syntax and transfer syntax and extension mechanism can be deferred to a concrete derived service specification;

 

This notion of partially-specifying extension parameters, diagnostic values and notification-type values has be in the Guidelines for a number of revisions, but I'm now questioning whether it is workable. Specifically, I'm having difficulty conceiving of how such partially-defined entities would be documented in an abstract specification.

 

I imagine that we could come up with some way to do this, but I'm wondering if it's really necessary. That is, is it really useful to be able to partially define one of these extensions for an abstract service?  Or can we just assume that any new parameters/diagnostics/notification-types added to an abstract specification will be fully specified, and if additional parameters (etc.) are required to derive a concrete service from an abstract one, it's up to that concrete service specification to add them "completely". If we agree on the latter approach, then we don't have to state any exceptions for extending operations for abstract services. For that reason, I'd like to propose the latter, simplified approach.

 

Does anyone see a problem with simplifying the Guidelines in this way? I look forward to your comments.

 

Best regards,

John

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

________________________________


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20091119/542b0e0d/attachment-0001.htm