[Sle-imp] RE: invoke-ID
John Pietras
pietras@gst.com
Fri, 2 May 2003 10:13:01 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C31093.6C68A4A0
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 3:23 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
Subject: RE: invoke-ID
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_000F_01C31093.6C68A4A0
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.69340680">
<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:purple;
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=3Dpurple =
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"15" Minute=3D"23"><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>3:23 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<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'>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_000F_01C31093.6C68A4A0--