[Css-csts] Extensions in abstract service specifications

[John Pietras]

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

 

________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20091117/00aaa828/attachment.htm