Note that no editorial edits are permitted to the spec documents if we a

I'd like to correct something I stated on the last call. We were discussing normative vs. editorial edits. I said something to the effect that we should only raise issues regarding normative text in the documents and that we could make some final editorial edits prior to submission.

This last part was not correct. I was confusing the votes for approving a Committee Draft before the start of a public review with the vote to "re-approve" a spec after a public review, which is what our current first vote is about. After this vote to re-approve our spec as a committee draft, we can make NO changes, normative or editorial, before we submit it to OASIS for standardization (our second vote). The only change that can occur is to modify the spec names (from CD to Standard).

So bear this in mind as you make your votes. The spec that will potentially become an OASIS Standard consists of the documents that we are approving as CD's with the first vote.

For some reason, another posting I made this morning still hasn't appeared on the list, so I'll also repeat that here...

Srinivas asked about whether another review cycle required another interop. The answer is no. The TC process says nothing about interop's. A TC doesn't even have to do one. It's just a vehicle for a TC to ensure that what they've done works in a heterogeneous environment. It's a good idea, but not required or even defined by OASIS.

w.r.t. whether we have to do another Public Review... The process states that if "substantive" changes are made to the spec after the start of a public review (i.e. the WSS public review was 19-Sep thru 19-Oct of 2003), the TC "should" conduct another public review.

As Rich said, "substantive" is a subjective term. In the SSTC, we considered it to mean anything that affected normative text in the spec or anything in the schema files other than documentation. I personally prefer that definition, but it doesn't mean that WSS has to use the same definition.

w.r.t. the schemas, the changes from the ones posted for public review consist of

- Secext

o The change from QName's to anyURI on attributes

o The addition of the TransformationParametersType type and the TransformationParameters element

o The removal of the PasswordTypeEnum, ValueTypeEnum, and EncodingTypeEnum types.

- Utility

o Removal of the ValueType attribute from the AttributedDateTime complexType

w.r.t. the spec documents, we've clearly had numerous normative changes since the PR drafts (that was the 082703 version of core). But I guess it's up to individuals to consider whether these are "substantial" such that they require a new public review period. A change that means something implemented to the first spec doesn't work with the re-approved spec seems substantial.

Finally, I suppose the "should" in "should conduct another public review" could be considered an out as well, since it is not a "MUST". I suppose technically, the TC is within the process to declare that the changes haven't been substantive, or that even if they are, the process doesn't mandate a new public review. I would guess that the intent of OASIS is that they want new reviews for any substantive changes, but that's not what the process says.

Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com

wss message