[Sle-imp] RE: invoke-ID
John Pietras
pietras@gst.com
Fri, 2 May 2003 10:13:23 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0014_01C31093.7B3343A0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
-----Original Message-----
From: Michael Stoloff [mailto:Michael.J.Stoloff@jpl.nasa.gov]
Sent: Thursday, May 01, 2003 10:19 PM
To: Brian Safigan
Cc: Boxell, Jeff; Michael Poole; Son Q Ho; Wolfgang Hell; Martin
Goetzelmann; Martin Pilgram; Takahiro Yamada; John Pietras; Jim Noles;
Deane Sibol; Michael J Stoloff
Subject: RE: invoke-ID
Please excuse this second message on the same subject, but I would like
to make two corrections to my previous message in any effort to head off
some potential confusion.
(1) The correct paragraph reference in the CLTU Blue Book Issue 1 for
the requirement under discussion is 3.4.2.5.2. Copies of the Blue Book
are available from the CCSDS web site <http://www.ccsds.org
<http://www.ccsds.org/> >.
(2) My previous message was sparked by the observation that the
requirement in paragraph 3.4.2.5.2 of the CLTU Blue Book conflicts with
the ASN.1 used in the current JPL and Avtec implementations of the SLE
API. Son Ho has correctly pointed out to me that there is no
discrepancy between the version of the CLTU specification that JPL and
ESA implemented to and the ASN.1 quoted by Brian Safigan. The
requirement in question does appear in the published CLTU Blue Book, but
it does not appear in the version of the CLTU specification that JPL and
ESA implemented to. The ASN.1 quoted by Brian does match the version of
the CLTU specification that JPL and ESA implemented to. (At the time
JPL and ESA needed to commit to a specification to meet implementation
schedules for the INTEGRAL mission, the Blue Book had not yet been
published. In fact, the version of the CLTU specification adopted for
INTEGRAL actually precedes even the CLTU Red Book Issue 2, although I
believe the Red-2 version is very close to what was actually
implemented.)
None of this changes the basic point I was trying to make in my previous
message, which I hope you will still consider.
My apologies for the error and for interrupting your day a second time.
--Regards,
Michael
At 12:22 PM 5/1/2003 -0700, <Michael.J.Stoloff@jpl.nasa.gov> wrote,
Brian,
Here's the definition of DiagnosticCltuStart from the published Blue
Book version of the CLTU service specification (available on the CCSDS
web site):
DiagnosticCltuStart ::= CHOICE
{ common [0] Diagnostics
, specific [1] INTEGER
{ outOfService (0)
, unableToComply (1)
, productionTimeExpired (2)
, invalidCltuId (3)
}
}
It appears that someone caught the omission and corrected it before the
final CCSDS version of the specification was approved. (Good job!)
Since the Blue Book version was not available when we were doing the
implementation, I went back and compared to the version of the
specification that we actually used. I also compared to what's in the
most recent version (v1.1) of the ESA SLE API specification. Both agree
with definition you quote in your email message.
Since the ASN.1 uses the "named integer" syntax, the problem is simple
to correct on the provider side: just revise the definition of
DiagnosticCltuStart (and anything derived it, such as the
CLTU_StartDiagnostic typedef in the SLE API) by adding the missing
diagnostic and then add the corresponding program logic.
The complication is that the revision may have a negative impact on
existing CLTU user implementations that are not programmed for the extra
diagnostic. Because of the "named integer" syntax, I think that there
should be no impact as long as the extra diagnostic is not actually used
in an SLE-PDU sent to the user. (If we had used the ASN.1 enumeration
syntax, I believe that revising the ASN.1 definition would change the
type and cause the user implementation to fail the first time it
receives a START return SLE-PDU, even if the diagnostic contained in the
SLE-PDU were one of the ones in the definition of DiagnosticCltuStart
that you quote in your email.) However, if the user application is not
programmed for the extra diagnostic, and the user actually receives an
SLE-PDU with the extra diagnostic encoded, I believe the results are
implementation-dependent (and possibly catastrophic).
For that reason, I've added the names of several people who are involved
with CLTU implementations to the distribution of this email in an effort
to assess exactly how difficult it would be to revise existing
implementations without affecting inter-operability.
BTW, I believe there may be a few other minor inconsistencies between
what is currently implemented and what is in the published Blue Book.
Also, I believe CCSDS is working on some minor corrections to the
published Blue Book (which would then be published as either a Technical
Corrigendum to the existing Blue Book or as a Blue Book Issue 2).
First, I want to emphasize that JPL is committed to supporting the
current implementation for its existing user base as long as necessary.
Second, ESA has suggested, and JPL concurs in principle, that we should
plan to upgrade existing implementations to a common Blue Book version
at some point in the foreseeable future. Exactly how that would be
accomplished is a topic for discussion. In part, I am sending this
message to try to begin that discussion.
Just my two cents worth. I encourage anyone on distribution of this
message to comment as appropriate. Also, please feel free to forward
this message to anyone you know who may be interested in this topic.
Thanks!
--Regards,
Michael
P.S. to John Pietras: It would probably be helpful if we had an "SLE
Implementers" mailing list for discussions such as the one I am trying
to start here. Do you think it would be possible/appropriate for the
CCSDS Cross Support Services Area to host such a mailing list? Can I
impose on you to talk to your local Area Director about that and let us
know? Thanks!
At 12:19 PM 5/1/2003 -0400, Brian Safigan wrote:
<snip>
The cltu spec 3.4.5.2 states that if the first-cltu-identification is
not greater than all cltu-ids currently in the buffer, to reply with a
negative result with the diagnostic set to 'invalid-cltu-ID'. This is
not a choice. The only choices (see ASN.1 code below) are outOfService,
unableToComply, productionTimeExpired, duplicateInvokeId, and
otherReason. The best we can do is set it to otherReason unless the
ASN.1 is updated. Do you know what others are doing?
DiagnosticCltuStart ::= CHOICE
{ common
[0] Diagnostics
, specific
[1] INTEGER
{ outOfService
(0)
, unableToComply
(1)
, productionTimeExpired (2)
}
}
Diagnostics
::= INTEGER
{ duplicateInvokeId (100)
, otherReason
(127)
}
------=_NextPart_000_0014_01C31093.7B3343A0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C31093.769F3C90">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"date"/>
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:DoNotRelyOnCSS/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:GrammarState>Clean</w:GrammarState>
<w:DocumentKind>DocumentEmail</w:DocumentKind>
<w:EnvelopeVis/>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:553679495 -2147483648 8 0 66047 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;
text-underline:single;}
tt
{font-family:"Courier New";
mso-ascii-font-family:"Courier New";
mso-fareast-font-family:"Times New Roman";
mso-hansi-font-family:"Courier New";
mso-bidi-font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal-reply;
mso-style-noshow:yes;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:Arial;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
/* Style Definitions */=20
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
</style>
<![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Michael Stoloff
[mailto:Michael.J.Stoloff@jpl.nasa.gov] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><st1:date
Month=3D"5" Day=3D"1" Year=3D"2003"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'>Thursday, May 01, =
2003</span></font></st1:date><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><st1:time
Hour=3D"22" Minute=3D"19"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>10:19 PM</span></font></st1:time><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brian Safigan<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Boxell, Jeff; Michael =
Poole;
Son Q Ho; Wolfgang Hell; Martin Goetzelmann; Martin Pilgram; Takahiro =
Yamada;
John Pietras; Jim Noles; Deane Sibol; Michael J Stoloff<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: =
invoke-ID</span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Please excuse this second message on the same subject, but I =
would like
to make two corrections to my previous message in any effort to head off =
some
potential confusion.<br>
<br>
(1) The correct paragraph reference in the CLTU Blue Book Issue 1 =
for the
requirement under discussion is 3.4.2.5.2. Copies of the Blue Book =
are
available from the CCSDS web site <<a href=3D"http://www.ccsds.org/"
eudora=3Dautourl>http://www.ccsds.org</a>>.<br>
<br>
(2) My previous message was sparked by the observation that the
requirement in paragraph 3.4.2.5.2 of the CLTU Blue Book conflicts with =
the
ASN.1 used in the current JPL and Avtec implementations of the SLE =
API.
Son Ho has correctly pointed out to me that there is no discrepancy =
between <b><i><span
style=3D'font-weight:bold;font-style:italic'>the version of the CLTU
specification that JPL and ESA implemented to</span></i></b> and the =
ASN.1
quoted by Brian Safigan. The requirement in question <b><i><span
style=3D'font-weight:bold;font-style:italic'>does</span></i></b> appear =
in the
published CLTU Blue Book, but it does <b><i><span =
style=3D'font-weight:bold;
font-style:italic'>not</span></i></b> appear in the version of the CLTU
specification that JPL and ESA implemented to. The ASN.1 quoted by =
Brian <b><i><span
style=3D'font-weight:bold;font-style:italic'>does</span></i></b> match =
the
version of the CLTU specification that JPL and ESA implemented to. =
(At
the time JPL and ESA needed to commit to a specification to meet =
implementation
schedules for the INTEGRAL mission, the Blue Book had not yet been
published. In fact, the version of the CLTU specification adopted =
for
INTEGRAL actually precedes even the CLTU Red Book Issue 2, although I =
believe
the Red-2 version is very close to what was actually implemented.)<br>
<br>
None of this changes the basic point I was trying to make in my previous
message, which I hope you will still consider.<br>
<br>
My apologies for the error and for interrupting your day a second =
time.<br>
<br>
--Regards,<br>
Michael<br>
<br>
At </span></font><st1:time Hour=3D"12" Minute=3D"22">12:22 PM</st1:time> =
<st1:date
Month=3D"5" Day=3D"1" Year=3D"2003">5/1/2003</st1:date> -0700,
<Michael.J.Stoloff@jpl.nasa.gov> wrote,<br =
style=3D'mso-special-character:
line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Brian,<br>
<br>
Here's the definition of DiagnosticCltuStart from the published Blue =
Book
version of the CLTU service specification (available on the CCSDS web =
site):<br>
<br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>DiagnosticCltuStart &nb=
sp;
::=3D CHOICE</span></font></tt><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">{
common &=
nbsp; &n=
bsp;
[0] Diagnostics</font></tt><br>
<tt><font face=3D"Courier New">,
specific  =
;
[1] INTEGER</font></tt><br>
<tt><font face=3D"Courier New"> {
outOfService &=
nbsp;
(0)</font></tt><br>
<tt><font face=3D"Courier New"> ,
unableToComply  =
;
(1)</font></tt><br>
<tt><font face=3D"Courier New"> ,
productionTimeExpired &nbs=
p; (2)</font></tt><br>
<tt><font color=3Dred face=3D"Courier New"><span =
style=3D'color:red'>
,
invalidCltuId =
(3)</span></font></tt><font color=3Dred><span style=3D'color:red'><br>
</span></font><tt><font face=3D"Courier New"> =
}</font></tt><br>
<tt><font face=3D"Courier New">}</font></tt><br>
<br>
</span></font>It appears that someone caught the omission and corrected =
it
before the final CCSDS version of the specification was approved. =
(Good
job!)<br>
<br>
Since the Blue Book version was not available when we were doing the
implementation, I went back and compared to the version of the =
specification
that we actually used. I also compared to what's in the most =
recent
version (v1.1) of the ESA SLE API specification. Both agree with
definition you quote in your email message.<br>
<br>
Since the ASN.1 uses the "named integer" syntax, the problem =
is
simple to correct on the provider side: just revise the definition =
of
DiagnosticCltuStart (and anything derived it, such as the =
CLTU_StartDiagnostic
typedef in the SLE API) by adding the missing diagnostic and then add =
the
corresponding program logic.<br>
<br>
The complication is that the revision may have a negative impact on =
existing
CLTU user implementations that are not programmed for the extra =
diagnostic.
Because of the "named integer" syntax, I think that there =
should be
no impact as long as the extra diagnostic is not actually used in an =
SLE-PDU
sent to the user. (If we had used the ASN.1 enumeration syntax, I =
believe
that revising the ASN.1 definition would change the type and cause the =
user
implementation to fail the first time it receives a START return =
SLE-PDU, even
if the diagnostic contained in the SLE-PDU were one of the ones in the
definition of DiagnosticCltuStart that you quote in your email.) =
However,
if the user application is not programmed for the extra diagnostic, and =
the
user actually receives an SLE-PDU with the extra diagnostic encoded, I =
believe
the results are implementation-dependent (and possibly =
catastrophic).<br>
<br>
For that reason, I've added the names of several people who are involved =
with
CLTU implementations to the distribution of this email in an effort to =
assess
exactly how difficult it would be to revise existing implementations =
without
affecting inter-operability.<br>
<br>
BTW, I believe there may be a few other minor inconsistencies between =
what is
currently implemented and what is in the published Blue Book. =
Also, I
believe CCSDS is working on some minor corrections to the published Blue =
Book
(which would then be published as either a Technical Corrigendum to the
existing Blue Book or as a Blue Book Issue 2).<br>
<br>
First, I want to emphasize that JPL is committed to supporting the =
current
implementation for its existing user base as long as necessary. =
Second,
ESA has suggested, and JPL concurs in principle, that we should plan to =
upgrade
existing implementations to a common Blue Book version at some point in =
the
foreseeable future. Exactly how that would be accomplished is a =
topic for
discussion. In part, I am sending this message to try to begin =
that
discussion.<br>
<br>
Just my two cents worth. I encourage anyone on distribution of =
this
message to comment as appropriate. Also, please feel free to =
forward this
message to anyone you know who may be interested in this topic. =
Thanks!<br>
<br>
--Regards,<br>
Michael<br>
<br>
P.S. to John Pietras: It would probably be helpful if we had an =
"SLE
Implementers" mailing list for discussions such as the one I am =
trying to
start here. Do you think it would be possible/appropriate for the =
CCSDS
Cross Support Services Area to host such a mailing list? Can I =
impose on
you to talk to your local Area Director about that and let us =
know?
Thanks!<br>
<br>
At <st1:time Hour=3D"12" Minute=3D"19">12:19 PM</st1:time> <st1:date =
Month=3D"5"
Day=3D"1" Year=3D"2003">5/1/2003</st1:date> -0400, Brian Safigan =
wrote:<br
style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><snip><br>
The cltu spec 3.4.5.2 states that if the first-cltu-identification is =
not
greater than all cltu-ids currently in the buffer, to reply with a =
negative
result with the diagnostic set to 'invalid-cltu-ID'. This is not a =
choice. The
only choices (see ASN.1 code below) are outOfService, unableToComply,
productionTimeExpired, duplicateInvokeId, and otherReason. The best we =
can do
is set it to otherReason unless the ASN.1 is updated. Do you know what =
others
are doing?<br>
<br>
DiagnosticCltuStart<x-tab> </x-tab><x-tab>&n=
bsp; </x-tab><x-tab> =
</x-tab><x-tab> &nbs=
p; </x-tab><x-tab> &n=
bsp; </x-tab>::=3D<x-tab> </x-tab=
>CHOICE<br>
{<x-tab> </x-tab>common<x-tab>&n=
bsp; </x-tab><x-tab> =
</x-tab><x-tab> </x-tab><x=
-tab> </x-tab><x-tab> =
; </x-tab><x-tab> &nb=
sp; </x-tab><x-tab> &=
nbsp; </x-tab><x-tab>  =
; </x-tab><x-tab> &nb=
sp;</x-tab><x-tab> </x-tab=
>[0]<x-tab> </x-tab>Diagnostics<br>
,<x-tab> </x-tab>specific<x-tab>=
</x-tab><x-tab> &nbs=
p; </x-tab><x-tab> &n=
bsp; </x-tab><x-tab> =
</x-tab><x-tab> &nbs=
p; </x-tab><x-tab> </=
x-tab><x-tab> </x-tab><x-t=
ab> </x-tab><x-tab> &=
nbsp; </x-tab>[1]<x-tab> &n=
bsp; </x-tab>INTEGER<br>
{<x-tab> </x-tab>outOfService<x-=
tab> </x-tab><x-tab> =
</x-tab><x-tab> &nbs=
p; </x-tab><x-tab> </=
x-tab><x-tab> </x-tab><x-t=
ab> </x-tab><x-tab> &=
nbsp; </x-tab>(0)<br>
<x-tab> </x-tab>,<x-tab>&n=
bsp; </x-tab>unableToComply<x-tab>&nbs=
p; </x-tab><x-tab> </=
x-tab><x-tab> </x-tab><x-t=
ab> </x-tab><x-tab> &=
nbsp; </x-tab><x-tab>  =
; </x-tab><x-tab> &nb=
sp; </x-tab>(1)<br>
<x-tab> </x-tab>,<x-tab>&n=
bsp; </x-tab>productionTimeExpired<x-t=
ab> </x-tab><x-tab> &=
nbsp; </x-tab><x-tab>  =
;</x-tab><x-tab> </x-tab>(=
2)<br>
<x-tab> </x-tab>}<br>
}<br>
<br>
Diagnostics<x-tab> </x-tab><x-tab> &nbs=
p; </x-tab><x-tab> &n=
bsp; </x-tab><x-tab> =
</x-tab><x-tab> &nbs=
p; </x-tab><x-tab> </=
x-tab><x-tab> </x-tab><x-t=
ab> </x-tab>::=3D<x-tab>&n=
bsp; </x-tab>INTEGER<br>
{<x-tab> </x-tab>duplicateInvoke=
Id<x-tab> </x-tab><x-tab> &=
nbsp; </x-tab><x-tab>  =
; </x-tab><x-tab> &nb=
sp; </x-tab><x-tab> &=
nbsp; </x-tab>(100)<br>
,<x-tab> </x-tab>otherReason<x-t=
ab> </x-tab><x-tab> &=
nbsp; </x-tab><x-tab>  =
; </x-tab><x-tab> &nb=
sp;</x-tab><x-tab> </x-tab=
><x-tab> </x-tab><x-tab>&n=
bsp; </x-tab><x-tab> =
</x-tab>(127)<br>
}<o:p></o:p></span></font></p>
</div>
</body>
</html>
------=_NextPart_000_0014_01C31093.7B3343A0--