[Css-dts] Version Number in SLE Transfer Services Specifications

[Michael Stoloff]

Dear Wolfgang,

JPL supports your proposal that the current RCF draft Recommendation (and 
eventual Blue Book Issue 1) should specify version 2 to avoid a conflict 
with existing RCF implementations (based on an earlier RCF draft 
Recommendation) that identify themselves as version 1.  Like ESA, JPL needs 
to support the existing, version 1, de facto international standard, as 
well as the anticipated version 2 standard (Pink sheets TBS), and we too 
would like to be able to depend on a functioning version negotiation mechanism.

Thanks for you initiative in addressing this issue.

--Best regards,
   Michael

At 04:29 PM 7/25/2003 +0200, Wolfgang.Hell@esa.int wrote:
>We were smart enough to include in the XXX-BIND operation a parameter called
>version-number. There is even a procedure defined on how the applicable 
>version
>of the specification can be negotiated between user and provider when the
>association between them get established.
>
>As you will be aware, there are implementations out in the field that are used
>daily in support of mission such as Integral and Mars Express. These
>implementations were built in accordance with specific issues of the 
>related Red
>Books and are not fully compliant with the Blue Books. As the MUSES-C example
>has shown, it is somewhat dangerous to come up with modifications without
>incrementing also the version number. This is in particular true for those 
>cases
>where an implementation of an earlier version exists and where the 
>modifications
>affect the ASN.1 data type specification.
>
>For the CLTU Book, we'll have the chance to fix the problem via the Pink Sheet
>mechanism, which will have to be launched because of other defects in that 
>book
>in any case. It also will look quite logical, since version 1 is 
>associated with
>Blue Book 1 and version 2 will be associated with Blue Book 2 after completion
>of the Pink Sheet process.
>
>For RAF, the situation is the same, although as far as I recall none of the
>candidate updates to the book will result in a change of the ASN.1.
>
>For RCF, the situation is different. We have implementations out in the field
>that comply with a specific Red Book, and they set the version-number 
>parameter
>to 1. In view of some defects detected in the draft Blue 1 Book, it was agreed
>to withdraw this book and rather publish a corrected version as Red-2.
>Eventually, that will become a Blue Book 1. However, in order to avoid the 
>same
>problem as was observed with the CLTU service, the version number in that book
>should then be specified to be 2. It may look a bit strange to have a Blue 
>Book
>1 that specifies a version number of 2, but I believe that this is a 
>lesser evil
>than creating interoperability problems due to assignment of the same version
>number to different actually implemented versions.
>
>I should also like to point out that this is not an academic, but a real world
>issue. ESA is commencing the implementation of its second SLE implementation
>release. This second release is intended to be fully compliant with the latest
>Blue Book issues. On the other hand, we will have to continue support of the
>current mission set with the currently used implementation. This shall be
>achieved by supporting both variants concurrently and therefore we depend on a
>functioning version negotiation mechanism.
>
>  For the above indicated reasons, we are seeking your agreement to 
> publish the
>RCF Red-2/Blue-1 Book with the version number specified to be 2. Your early
>reply will be greatly appreciated.
>
>Best regards,
>
>Wolfgang
>
>
>
>_______________________________________________
>CSS-dts mailing list
>CSS-dts@mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/css-dts