OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Potential Erratum -- NameIDMappingResponse schema


> What are the constraints for producing one?
Note the last paragraph from the TC Process, no more than once every  
6 months. Note also (b) regarding no substantive change.

<http://www.oasis-open.org/committees/process.php#3.5>
> 3.5 Approved Errata
>
> A TC may approve a set of Errata to an OASIS Standard as "Approved  
> Errata" to the corrected specification by:
>
> (a) Adopting the set of proposed corrections as a Committee Draft,  
> in the form of a list of changes, and optionally accompanied by a  
> copy of the original specification text marked to incorporate the  
> proposed changes.
>
> (b) Confirming by Full Majority Vote that the proposed corrections  
> do not constitute a Substantive Change.
>
> (c) Submitting the proposed corrections for a 15-day public review,  
> and completing that review, pursuant to Section 3.4.
>
> (d) After the public review, confirming the proposed corrections as  
> Approved Errata by a Full Majority Vote.
>
> Once approved, the Approved Errata shall be with the specification  
> it corrects, in any publication of that specification. Disposition  
> of Approved Errata must be identified in the subsequent Public  
> Review Draft of the corrected specification.
>
> A TC may not adopt Approved Errata to an OASIS Standard more than  
> once in any consecutive six-month period.

regards, Frederick

Frederick Hirsch
Nokia


On Apr 30, 2007, at 3:03 PM, ext Scott Cantor wrote:

>> I was going to suggest the same thing but was worried that folks  
>> would
>> frown on the idea :)  Really though, it may be the best option we  
>> have
>> at this stage.
>
> I could also be wrong, BTW, about the errata rules. There used to  
> be no
> process; now that there is one, what are the constraints for  
> producing one?
>
> I think it makes very little sense to say you can have official  
> errata but
> they can't *really* change the spec. Typos happen, you can't expect  
> all of
> them to be X number of words away from a MUST.
>
> From a conformance standpoint, it seems reasonable to me that any  
> statement
> wrt conformance be applicable to the state of a spec and its errata  
> as of a
> certain date.
>
> -- Scott
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]