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

Thanks.  And that same document defines

"(gg) "Substantive Change" is a change to a specification that would require
a compliant application or implementation to be modified or rewritten in
order to remain compliant."

I'm not sure that the modification of schema as suggested would "require"
compliant implementations to change.  Indeed, I'm pretty sure none of the
implementations that have passed through the testing program enforce schema
validation, and no one has complained about this particular issue.


On 4/30/07 3:14 PM, "Frederick Hirsch" <frederick.hirsch@nokia.com> wrote:

>> 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

Eric  Tiffany             |  eric@projectliberty.org
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile

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