[Css-dts] Version Number in SLE Transfer Services Specifications
Wolfgang.Hell@esa.int
Wolfgang.Hell@esa.int
Fri, 25 Jul 2003 16:29:31 +0200
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