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 $B%N(J ( ( MajorB = MajorA ) $B%M(J 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 ) $B%M(J ( 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