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