[Css-csts] Follow-up on "Optional" discussion, and errors regarding procedure-instance-identifier

Mon Mar 31 14:48:28 EST 2008

John,

Good points.  All your suggestions seem sensible to me.  

Best regards,
Tim

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Monday, March 31, 2008 3:15 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Follow-up on "Optional" discussion,and errors
regarding procedure-instance-identifier

Members of the CSTSWG ---
In Crystal City we discussed a range of possible mechanisms for
supporting optional capabilities in CSTSes. I have in my notes that we
agreed to support options at the level of whole procedures (and not, for
example, optional operations within a procedure). Also, only secondary
procedures can be optional; the prime procedure must always be
supported.

What I failed to note was the outcome of the discussion of what the
appropriate response should be to an invocation of an operation of an
optional procedure that is not supported by a particular provider. In
fact, I can't even recall if we did come to a consensus. The issue is
whether such an invocation should cause a protocol abort or a
more-benign negative-result. I have come up with a proposal for using
the negative-result approach.

Also, in working through this issues, I came across some errors related
to the procedure-instance-identifier parameter in the v0.12 Procedures
Definition. These errors are described at the end of this note.

Here is my proposal for treating invocations of unimplemented optional
secondary proposals. 

- For each secondary procedure, the service specification must specify
the minimum number of instances of that secondary procedure that a
conforming implementation must support. For mandatory secondary
procedures, the service specification sets this minimum number to at
least one. For optional secondary procedures, the service specification
sets the minimum number to zero.

- For each instance of a CSTS, the maximum number of instances of a
secondary procedure must be static (per the CSTSWG decision in Colorado
Springs). The service specification may fix that maximum number, or it
may defer setting the value of the number to the Service Agreement. 

- The Service Agreement must specify the maximum number of supported
instances of a secondary procedure within the range specified in the
service specification. 

- If the secondary procedure type is optional and is not supported by a
particular provider (i.e., the Service Agreement with that provider sets
that maximum number of instances of that secondary procedure to zero),
the set of secondary procedure instance numbers that are valid is the
empty set. If a user attempts to invoke an operation (e.g., START) of
that procedure type, the instance number component of the
procedure-instance-identifier parameter (of the Standard Operation
Header) will be invalid for that procedure type, and the operation will
return a negative result with diagnostic 'invalid range'. 

This approach even works in the case of a service in which the prime
procedure and an optional secondary procedure are of the same type
(whether this is a realistic case or not is another matter). In such a
case, if the optional secondary instances are not supported by a
provider, only the zero value of the instance number component will be
valid (signifying the prime procedure), but any instance number
corresponding to a secondary procedure instance (1 and above) will be
invalid and result in the negative-result return. 

Note that this approach does put a minor requirement on every
implementation of a service to recognize all procedure types associated
with that service, even the optional ones that aren't supported by an
implementation. 

This is context in which I am writing the Guidelines for dealing with
optional procedures. If I have missed a decision form Crystal City to do
otherwise (e.g., peer-abort on an attempt to invoke an unsupported
optional secondary procedure), please let me know. And even if we didn't
come to a conclusion in Crystal City and you disagree with this
approach, please let's discuss it.

Finally, I mentioned above that there appear to be several definition
errors regarding procedure-instance-identifier in the v0.12 Procedures
Definition. 

Clause 4.4.2.5.1 states "When invoking for the first time a procedure in
a service, the invoker shall specify the procedure type and instance
number. The procedure-instance-identifier shall be used for all
operations used in the context of that procedure instance." The first
error involves the "first time" phrase. The procedure instance
identifier appears in every invocation, not just in the first invocation
of a procedure. This sentence should (I think) be changed to read "The
identification of the procedure type and procedure instance number with
which the invocation is associated. The procedure-instance-identifier
shall be used for all operations used in the context of that procedure
instance."

The second error is found in clauses 4.4.2.5.2 - 4.4.2.5.4, which treat
the whole procedure-instance-identifier as the instance number component
of that identifier. E.g., " 4.4.2.5.2	The
procedure-instance-identifier of the prime procedure shall be set to 0."
I think that this should be phrased "The procedure instance number
component [part, element] of the procedure-instance-identifier of the
prime procedure shall be set to 0."

This confusion is also present in the ASN.1, in which the type
ProcedureInstanceId is defined as:

ProcedureInstanceId		::=	SEQUENCE
{	procedureType		ProcedureType
,	procedureInstanceId	CHOICE
{	primeProcedure	 [0]	INTEGER (0)
,	secondaryProcedure [1] 	IntPosShort
}

That is, a component of the of the SEQUENCE (procedureInstanceId) has
the same name as the larger type to which it belongs. The type
ProcedureInstanceId is then used as the type for procedureInstanceId
components of larger types:

StandardConfirmedInvocationHeader	::= SEQUENCE
{	invokerCredentials	Credentials
,	invokeId			InvokeId
,	procedureInstanceId	ProcedureInstanceId
}

StandardReturnHeader		::= SEQUENCE
{	performercredentials	Credentials
,	invokeId			InvokeId
,	procedureInstanceId	ProcedureInstanceId
,	result				CHOICE
	{	positive	[0]	Extended	-- To carry the
positive results
	,	negative	[1]	SEQUENCE
{ 	diagnostics	Diagnostics
,	extended	Extended
}
	}
}

In other words, the procedureInstanceId component of the
StandardConfirmedInvocationHeader has a component with the same name as
itself!

The simplest way to fix this is to (a) rename the procedureInstanceId
component of the ProcedureInstanceId type to be
"procedureInstanceNumber", and (b) rephrase clauses 4.4.2.5.2 -
4.4.2.5.4 to be in terms of the instance number component of the
procedure-instance-identifier, not the procedure-instance-identifier
itself.

The final error (inconsistency) is between Table 4-2 and the ASN.1.
Table 4-2 shows the procedure-instance-identifier as occurring only in
the invocation, whereas the ASN.1 also has it in the return (see the
ASN.1 StandardReturnHeader, above). Which one is correct?

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts