[ubl-ndrsc] Versioning Material

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Here's some background material for the versioning discussion Wednesday.

First off, have a look at the pertinent section of the NDR doc.

Secondly, I've attached the XFront paper on versioning -- it's referenced
from the NDR doc but I doubt we've all read it recently.

Lastly, for your reference, I've appended the pertinent section from the
SAML specification at the end of this message.

Looking at the SAML stuff leads me to the conclusion that we (probably in
conjunction with LCSC) should consider specifying versioning not only in
terms of release-to-release schema versions, but also in terms of
message-to-message relationships in our business process.

Also here's the guts of my previous message about major/minor numbers in the
namespace URI (URN):

We don't have a firm rule for expressing versioning information in our
vocabulary(s).
 
The 0p70 schemas put version information in the namespace URI.  The NDR doc
doesn't give a specific format for those -- just says [TBD version
information].  In the 0p70 release I don't really understand the system
we're using.  Here's the Order URN:
 
urn:oasis:names:tc:ubl:Order:1.0:0.70
 
It appears that there are two version components here: "1.0" and "0.70".  In
the NDR doc we _hint_ at a major/minor scheme.  Is the "1.0" meant to denote
a major designator, and "0.70" minor?  
 
If those are respectively major and minor numbers, then I propose:
 
* change the number scheme so that the major number is a non-negative
integer and the minor number is a non-negative integer
 
That'd make, e.g. the Order urn look like:
 
urn:oasis:names:tc:ubl:Order:0:7
 
That'd be major version 0 and minor version 7.  We'd go change the other
URN's accordingly.
 

cs-sstc-core-01 34 31 May 2002
4 SAML Versioning 1303
SAML version information appears in the following elements: 1304 .
<Assertion> 1305 . <Request> 1306 . <Response> 1307 The version numbering of
the SAML assertion is independent of the version numbers of the SAML 1308
request-response protocol. The version information for each consists of a
major version number and a 1309 minor version number, both of which are
integers. In accordance with industry practice a version number 1310 SHOULD
be presented to the user in the form Major.Minor. This document defines SAML
Assertions 1.0 1311 and SAML Protocol 1.0. 1312 The version number
MajorB.MinorB is higher than the version number MajorA.MinorA if and only
if: 1313 MajorB > MajorA ノ ( ( MajorB = MajorA ) ネ MinorB > MinorA ) 1314
Each revision of SAML SHALL assign version numbers to assertions, requests,
and responses that are 1315 the same as or higher than the corresponding
version number in the SAML version that immediately 1316 preceded it. The
specifications may be revised without a change to the SAML major or minor
version 1317 number, as long as the specification changes raise no
compatibility issues with SAML implementations. 1318 New versions of SAML
SHALL assign new version numbers as follows: 1319 . Minor upgrade: ( MajorB
= MajorA ) ネ ( MinorB > MinorA ) 1320 If the major version number of
versions A and B are the same and the minor version number of B 1321 is
higher than that of A, the new SAML version MAY introduce changes to the
SAML schema and 1322 semantics but any changes that are introduced in B
SHALL be compatible with version A. 1323 . Major upgrade: MajorB > MajorA
1324 If the major version of B number is higher than the major version of A,
Version B MAY introduce 1325 changes to the SAML schema and semantics that
are incompatible with A. 1326 4.1 Assertion Version 1327 A SAML authority
MUST NOT issue any assertion whose version number is not supported. 1328 A
SAML relying party MUST reject any assertion whose major version number is
not supported. 1329 A SAML relying party MAY reject any assertion whose
version number is higher than the highest 1330 supported version. 1331 4.2
Request Version 1332 A SAML authority SHOULD issue requests that specify the
highest SAML version supported by both the 1333 sender and recipient. 1334
If the SAML authority does not know the capabilities of the recipient it
should assume that it supports the 1335 highest SAML version supported by
the sender. 1336 4.3 Response Version 1337 A SAML authority MUST NOT issue
responses that specify a higher SAML version number than the 1338
corresponding request. 1339 A SAML authority MUST NOT issue a response that
has a major version number that is lower than the 1340 major version number
of the corresponding request except to report the error 1341
RequestVersionTooHigh. 1342 cs-sstc-core-01 35 31 May 2002 An error response
resulting from incompatible protocol versions MUST result in reporting a
top-level 1343 StatusCode value of VersionMismatch, and MAY result in
reporting one of the following second-level 1344
values: 1345
RequestVersionTooHigh 1346
The protocol version specified in the request is a major upgrade from the
highest protocol version 1347 supported by the responder. 1348
RequestVersionTooLow 1349 The responder cannot respond to the particular
request using the SAML version specified in the 1350 request because it is
too low. 1351 RequestVersionDeprecated 1352 The responder does not respond
to any requests with the protocol version specified in the request. 1353

Attachment: Versioning.pdf
Description: Binary data