Re: [security-services] Suggested schema tightening for 2.1

["Cantor, Scott" <cantor.2@osu.edu>]

On 8/15/12 10:04 AM, "Ian Young" <ian@iay.org.uk> wrote:
>
>I suspect that the '+' could be omitted without changing the meaning.

Yes, vestige of earlier attempt.

>One is the question about of URI values with white space around them are
>intended to be reliably interoperable (in which case we should warn
>implementers to strip leading and trailing white space) or not (in which
>case we might take the opportunity to constrain the lexical space to
>exclude things like this:
>
>	<md:OrganizationURL>
>		http://example.org
>	</md:OrganizationURL>

It applies to the strings too, I think, at least some of them. I agree, we
need to provide guidance on this. At a minimum, I think most of the URIs
could be handled with "SHOULD produce with no leading/trailing whitespace"
and "SHOULD trim" without breaking anything.

>[As I recall the discussion, *validating* XML processors are allowed to
>remove such white-space, but non-validating ones don't and even
>validating ones might not.]

Generally a validating processor only could remove it when normalizing
data if the data type mandates it. String data definitely wouldn't. I
don't know about anyURI.

>I won't pretend that actually enforcing absolute URI in the places the
>standard already reads that way would be neutral for all implementers.
>Although most people in my space have used proper full URLs for entity
>IDs, for example, there are places where things like entityID="HHS" are
>being used without problems.

Yeah, but we are certainly within our rights to do so. It becomes more of
a "wisdom" question. We'd break Google for example.

>Finally, there are a couple of places where the spec says specifically
>"URL" but the schema says "anyURI".  Pushing things all the way in the
>direction of the schema enforcing a restricted selection of URI scheme
>names is probably pushing things way too far, but I'll just include it as
>a possibility here for completeness.

Any place we could limit it would likely be a co-constraint (e.g., if the
Binding is X, then the Location MUST be http or https), which XSD can't
do. And then you have the admittedly unlikely possibility that Google
might just unilaterally start inventing new schemes for Chrome to use or
something.

-- Scott