On Sun, 30 Jan 2005 22:30:16 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Paul Hoffman wrote: > > > > At 5:11 PM +0000 1/30/05, Graham wrote: > >> > >> The content of an Identity construct SHOULD NOT be dereferenced, > >> even when it comes from a > >> normally dereferencable scheme. There is no requirement for the > >> content to represent a URI > >> where a version of the feed or entry may be found. > > > > > > I'm +1 on this, but would be fine if the WG doesn't want to change. > > Graham's wording is more useful to an implementer who wasn't on the > > mailing list last year (or was on and skipped over the permathreads). > > > > Well, it seems silly to use a dereferencable scheme if you don't want > the URI dereferenced. Secondly, I fail to see how dereferencing a URI > would cause interop problems.
I disagree with Graham in that someone may come up with a good thing to stick at the resource that an Identity construct points at (the lessons of XML namespaces not withstanding). But I do believe that we need to be explicit about dereferencability, even if it means we state: ""This specification makes no assertions as to the content of any resources pointed to via Identity constructs that come from a dereferencable scheme. In the normal processing of Atom documents the Identity Construct URI is only used in character by character comparisons and does not require the dereferencing of such a URI."" We could go further and state: ""Atom generators should realize that consumers may not always be dedicated Atom parsers and as a matter of course could dereference Identity URIs. As such, Identity Construct URIs MUST be constructed in a manner that dereferencing such URIs MUST NOT cause any ill effects."" But I'm not sure if that belongs in the security section, or if we even skip it completely and just lean on the reference to the security section of RFC 3986. -joe -- Joe Gregorio http://bitworking.org
