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

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: