On a couple of the points below:
Scott Cantor wrote:
...
>>4. Lines 682-689: The use of the phrase "while confirming
>>itself" is pretty confusing and could really use some
>>additional explanatory text. Does this mean the attributes
>>are only used when the entity presenting the assertion is the
>>"subject" of the assertion?
>
>
> No, it means they're used when evaluating subject confirmation. Core doesn't
> define when that is precisely. At least it never did before. I reworded a
> little bit to clarify that the attributes apply to the characteristics of an
> action performed by a "confirming entity", not the subject. We should make
> sure that term is in the glossary.
...
I sent mail to Jeff asking that he add "confirming entity" to the
glossary, which currently doesn't have it.
...
>>6. Lines 978-979 re: the note that AuthorityBinding was
>>removed. Should we clutter up the core spec with these
>>notes? I think they should just go in the 1.1/2.0
>>differences section of the tech overview. If we want to
>>include them, we should go through the spec to mention them
>>all. For example, we don't mention that the
>>AttributeNamespace attribute was removed in section 2.7.3.1.
>>Lines 1383-1384 do describe removal of <RespondWith>.
>
>
> Well, we mentioned all the things we removed that have no new equivalent.
> Eg. AttributeNamespace was replaced with NameFormat and more liberal
> wildcarding.
We put in notes for these because we advertised in V1.1 that they were
going to come out in V2.0 in backwards-incompatible fashion. I can see
an argument for removing the notes since we also did a lot of other
invasive stuff between then and now.
>>7. Line 1046: While I know what the "or both" clause is
>>referring to once you read the schema, it's not a very clear
>>description.
>
>
> But it's precise. And the schema is part of the spec. You aren't expected to
> be able to read the spec without it. I think we've been less than firm on
> that point. Syntactically, the schema is the spec.
Slightly OT, but it was recently pointed out to me that our text
explaining the precedence of schemas/prose is somewhat out of whack.
What we had wanted to say is that the schema listings in the specs are
illustrative only (the machine-readable real .xsd files hold sway if
there's any discrepancy), but that the prose often contains extra
constraints beyond the schema grammar and is therefore authoritative.
We hadn't wanted to use wording saying the (non-schema-snippet) prose
literally "takes precedence", but in fact that's the only practical
solution when we have these added constraints. What we've got is
therefore confusing.
S'okay with folks if I change from this:
"This specification uses schema documents conforming to W3C XML Schema
[Schema1] and normative text to describe the syntax and semantics of
XML-encoded SAML assertions and protocol messages. In cases of
disagreement between the SAML schema documents and schema listings in
this specification, the schema documents take precedence. Note that in
some cases the normative text of this specification imposes constraints
beyond those indicated by the schema documents."
to this?
"This specification uses schema documents conforming to W3C XML Schema
[Schema1] as well as normative text to describe the syntax and semantics
of XML-encoded SAML assertions and protocol messages. The schema
listings in this specification are illustrative only, and in cases of
disagreement between them and the machine-readable SAML schema
documents, the schema documents take precedence. However, the normative
text in this specification provides the authoritative interpretation of
all SAML semantics and processing. (In some cases, the text
deliberately defines constraints that go beyond those expressed in the
schema documents.)"
I believe this appears in all the specs containing schema snippets, so
it would have to be changed throughout.
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
