RE: [security-services] URI extensions etc

["david.orchard@bea" <david.orchard@bea.com>]

I couldn't fully parse the messages below, but I'll try my best at helping.
I'll give a short version then a much too long explanation.

I like Phil's suggestion of using fragment identifiers, but I suggest a
tweak that IDREF is used rather than anyURI.  I also support using relative
URIs and xml:base.  These are different issues, believe it or not.

<long>
1. URI references do not need a "#" as defined by rfc 2396.  URI reference
may be absolute, relative or contain a fragment identifier.  xml:base
defines how relative URIs are used to generate absolute URIs and says
nothing about fragment identifiers.  Please note the following statement in
section 4 on URI references from rfc 2396,

[However, "the URI" that results from such a reference includes only the
absolute URI after the fragment identifier (if any) is removed and after any
relative URI is resolved to its absolute form.]

xml:base does not over-ride rfc2396, so I'm not sure what it does.  I've
asked the editor.  I'm not sure fragment identifiers should be used with
relative references.

Now it is common to use fragment identifiers BUT they are typically either
"bare" or absolute and never with a relative URI.

2. I don't think that xml:base has to be defined in SAML schema to be
supported.  SOAP 1.2 supports xml:base but does not include it in the SOAP
1.2 envelope schema.  Sadly, I will even ref the soap envelope namespace
name - http://www.w3.org/2001/12/soap-envelope.  It would be strange if SAML
could be expressed in SOAP 1.2 but did not support xml:base.   It would be a
simple matter to define how SAML would use xml:base in a SOAP 1.1 message.

3. FWIW, xml:base also defines an algorithm for creating a base infoset
property from the protocol.  SOAP 1.2 faithfully does this.  SAML would
automatically get the base infoset item from a SOAP 1.2 processor and it
would be set according to the resolving relative URI references algorithm.

You could use either relative URIs or absolute with fragment identifiers or
fragment identifers.  But not relative URIs with fragment identifiers.

I strongly support use of xml:base for relative URI resolution - in fact I
was a champion of them for soap 1.2 along with Chris Ferris of Sun.  Here is
a sample for SAML:
[All URIs used in SAML MAY be either absolute or relative.  SAML does not
define a base URI but relies on the mechanisms defined in XML Base and RFC
2396 for establishing a base URI that may be used when absolutizing URIs.
SOAP 1.1 does not explicitly support XML Base and the base URI might not be
set by a SOAP 1.1 processor.  A SAML processor MAY be required to determine
the base URI as defined by XML Base, such as examining the xml:base
attribute in the SOAP 1.1 envelope.
SOAP 1.2 supports XML Base.  A SAML processer MUST use the base URI as set
by a SOAP 1.2 processor
]
Another place to put wording on XML Base is in the protocol binding, as the
base uri set by the protocol is part of the xml base and rfc 2396 algorithm.


But this is orthogonal to the use of fragment identifiers as I think Phil
brought them up.  Phil brought up the use of fragment identifiers which is
not covered by the xml:base spec - xml:base talks about relative URIs which
EXCLUDES fragment identifiers.   If you use the anyURI data type, you must
use the fragment identifier syntax, ie #id.  Or you must use an absolute URI
with a fragment identifer, ie http://foo.com/bar#id.    There is NO xml or
XML Schema data type for URIs with only fragment identifiers or absolute
URIs.  Let us not go into the issue of defining URI data types.  So if you
use the anyURI type, then you have to decide what to do about allowing
relative URIs and fragments.  And you can only do it in spec land, not a
schema definition.  And there the merry-go-round begins.

Another option would be to use the IDREF type rather than anyURI type.  This
has the nice feature that most XML parsers will do ID/IDREF checking.  And
lo, SOAP 1.2 had extensive discussions on using IDREF rather than anyURI for
SOAP encoding references (exactly what I think is being proposed here), led
by Marc Hadley of Sun.
http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0131.html.  Most
members of XMLP found the IDREF arguments pretty convincing fwiw, though I
can't say publicly what the xmlp resolution was.  W3C members can find the
XMLP resolution.

I think it's safe to say that relative URIs and IDREFs are acceptable
industry practice.
</long>

My $.02 Canadian worth,
Dave

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Thursday, January 31, 2002 5:56 PM
> To: security-services@lists.oasis-open.org
> Subject: Re: [security-services] URI extensions etc
>
>
> I must have missed this discussion; what was the benefit
> claimed for this
> approach?  (I'm not necessarily against it.)
>
> This approach points up the importance of talking about URI
> *references* in
> the text, not just URIs.  I think I've commented on this
> before.  ("URI
> reference" means the URIs that are allowed to have have fragment
> identifiers on them.)  If we don't say we allow URI references, then
> fragment identifiers technically aren't allowed, though I
> doubt there's
> much software that would hold implementations to this restriction.
>
> (I'm not too crazy about messing with base URIs; their
> semantics are a
> little tricky.  BTW, xml:base is one of those pseudo-native
> XML attributes
> that can't be validly used unless we really include it in our
> schema...  I'd rather have whole URI references be spelled out.)
>
>          Eve
>
> At 05:46 PM 1/31/02 -0800, Hallam-Baker, Phillip wrote:
> >One issue that was raised was the issue of expressing
> identifiers as URI
> >fragments.
> >
> >I.E. if our base spec is http://foo.bar/base then the
> identifiers defined
> >therein should
> >be of the form http://foo.bar/base#X #Y #Z etc rather than the
> >http://foo.bar/base/PKCS7
> >style I used.
> >
> >This would also change RespondWith slightly so that the
> identifiers were all
> >nominaly
> >fragments off the default URI which would be the base URI
> for the spec.
> >
> >All this means in practice is we introduce some # characters
> in several
> >spots.
>
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>