[Css-csts] topics for discussion in telecon
Ray, Timothy J. (GSFC-5830)
timothy.j.ray at nasa.gov
Wed Aug 12 15:17:25 EDT 2009
Dear Yves,
Thanks for the quick response. Your answers are very helpful. I finally understand how the EmbeddedPDV will be used (and how extension-data is connected to the standard PDU structures). This understanding is allowing me to make some good progress on a Framework implementation.
Thanks,
Tim
-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Tuesday, August 11, 2009 3:54 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] topics for discussion in telecon
Dear Tim,
Please find below some answers to your questions:
Where does our spec say that a Start is not allowed while Unbound? (I don’t
see it in section 3.7 on the Start operation)
In the section "Binding", the requirement 4.3.3.1.2.1 states "Except as
provided in 4.3.3.1.2.3, the Service User shall not invoke any further
operations for this service instance until the return from the Service
Provider is received".
This requirement is supposed to cover that case as we did not want to repeat
for each Operation/Procedure a common behaviour.
Where does our spec say that the Transport Mapping Layer is used underneath
the Framework? i.e. that a connection has to be established as part of a
Bind? (I don’t see it in section 4.3 on “Association Control”).
The section 2.6.3 states "... The mapping of CSTS PDUs to an underlying
communications service is intentionally outside the scope of this Recommended
Standard. In order to achieve interoperability, the Service User and Service
Provider must conform not only to the service specification based on this
Recommended Standard but also to an agreed upon specification of the mapping
of the service to the underlying communications service ...".
The document includes a reference to ISP.
Where does our spec say how to insert data into an Extended structure?
Annex D specifies:
D1.9 The extension capability may or may not be used using the Extended
parameter. If not used the Extended parameter shall carry a NULL value.
D1.10 Extension is defined by means of “EMBEDDED PDV”. The ASN.1 EMBEDDED PDV
type is a useful type used to include non-ASN.1 or other data within an ASN.1
encoded message. This type is described using the following ASN.1 SEQUENCE:
EMBEDDED PDV ::= [UNIVERSAL 11] SEQUENCE
{ identification CHOICE
{ syntaxes SEQUENCE
{ abstract OBJECT IDENTIFIER,
transfer OBJECT IDENTIFIER
},
syntax OBJECT IDENTIFIER,
presentation-context-id INTEGER,
context-negotiation SEQUENCE
{ presentation-context-id INTEGER,
transfer-syntax OBJECT IDENTIFIER
},
transfer-syntax OBJECT IDENTIFIER,
fixed NULL
},
data-value OCTET STRING
}
D1.12 The nextension shall make use of the “transfer-syntax” definition in
the “identification” CHOICE. The “transfer-syntax” is assigned an
object-identifier (see C4.7) unique for all extensions that clearly indicates
that all external syntaxes carried by this definition belong to the Cross
Support Services
D1.13The transfer syntax used for the extension (see D1.11) shall be the
transfer-syntaxes defined in C4.7.
Is anything in chapter 2 normative?
The chapter 2 ias descriptive only. Is there any requirement that should be
moved to section 3 or 4?
In section 4.2.1, do any of the subsections apply to the User side? If so,
which ones? (I realize that most of them do apply to both User and Provider,
but a new person might be confused ). Can we be more clear? For example,
4.2.1.3 gives the impression that this section applies to the Provider, but I
think our intention is that the whole section applies to both User and
Provider unless otherwise specified.
As for SLE the Recommendation is written toward the behaviour of the provider
and explain what the provider shall do depending on the user received
interactions. Every time a requirement refers to the reception of an
operation, it implies the operation is sent by the user. This approach worked
fine for the SLE Recommendations.
Would a statement such as "On reception of an UNBIND invocation from the
User, the Association Control procedure shall issue a ‘terminate’ event to
all procedure instances of the service instance" add clarity?
Best regards
Yves
"Ray, Timothy J.
(GSFC-5830)"
<timothy.j.ray at nas To
a.gov> "css-csts at mailman.ccsds.org"
Sent by: <css-csts at mailman.ccsds.org>
css-csts-bounces at m cc
ailman.ccsds.org
Subject
[Css-csts] topics for discussion in
11/08/2009 00:20 telecon
Dear Working Group,
General comment: I could develop a User implementation based on the
knowledge gained from attending our meetings. But that would not be a good
test of our specification. Instead, I am trying to stick to the
specification as my only guide.
Here are some questions for discussion in tomorrow’s telecom:
· Where does our spec say that a Start is not allowed while
Unbound? (I don’t see it in section 3.7 on the Start operation)
· Where does our spec say that the Transport Mapping Layer is
used underneath the Framework? i.e. that a connection has to be
established as part of a Bind? (I don’t see it in section 4.3 on
“Association Control”).
· Where does our spec say how to insert data into an Extended
structure?
· Is anything in chapter 2 normative?
· In section 4.2.1, do any of the subsections apply to the User
side? If so, which ones? (I realize that most of them do apply to
both User and Provider, but a new person might be confused ). Can we
be more clear? For example, 4.2.1.3 gives the impression that this
section applies to the Provider, but I think our intention is that the
whole section applies to both User and Provider unless otherwise
specified.
Best regards,
Tim
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list