Hmmmm. The dead horse comes to life with more beating. At the risk of causing further consternation and time-wasting...
At 7:28 PM -0800 1/30/05, Mark Nottingham wrote:
How about "Dereferencability of Identity Constructs"?
Works for me.
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems silly to use a dereferencable scheme if you don't want the URI dereferenced.
I agree, but there was broad WG consensus on this months ago. It is too late to revisit that now.
Secondly, I fail to see how dereferencing a URI would cause interop problems.
The interop problem comes where Atom consumers/readers *expect* an <atom:id> to be able to be dereferenced when it might not be able to be. Such an assumption will lead some to try to (at least sometimes) dereference and report an error when it fails. The failure report is an interop issue.
We see this often in other IETF standards. "When I try to do X on the message from Vendor J, it doesn't work; their implementation is broken." "The spec says you might be able to do X, but not necessarily." "But most vendors' systems work when I do X, so Vendor J is wrong." "No, Vendor J followed the spec, as did the others." "Why is it in the spec if you don't have to do it." Blah blah blah.
At 11:08 PM -0500 1/30/05, Joe Gregorio wrote:
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).
Fine, but then they should duplicate the URL somewhere else in the entry/feed.
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.""
I'm OK with that wording, but prefer Graham's propsal.
At 8:22 PM -0800 1/30/05, Tim Bray wrote:
-1. And I *will* lie down in the road.
For "ongoing", I plan to use the same http: URIs for both the <atom:id> and <link rel="alternate">; I will manage (and have managed) my URI space so that they will meet the requirements of permanence, uniqueness, and so on. In this case the <atom:id> URI will absolutely be dereferenced, but only in its <link> role.
Sorry, that makes no sense. If you have two identical URI strings in your entry, and someone dereferences one of them (the <link>), that does not make the other one any more important. From a protocol standpoint, it is an uninteresting coincidence that the two strings are identical.
The language above could be read as discouraging what I'm planning to do,
No, it doesn't. It says "don't derefernces what is in <atom:id>", not "if the <atom:id> is identical to a <link> reference, don't derefernce the <link>". No one could read it like the latter.
and what I'm planning to do is perfectly good practice.
Agree.
Anyhow, per both IETF RFCs and the W3C web-architecture spec, no harm can be done merely by trying a GET on any URI, so saying SHOULD NOT is just bogus.
I think what you're really trying to say is this:
"When using <atom:id> to ascertain whether two Atom entries or feeds are the same, such operations MUST be based only on the URI character strings, and MUST NOT rely on dereferencing the URIs."
See, it's a MUST, even... would that meet Graham & Paul's issues?
Almost. I'm OK with that if we add something explicit saying consumers MUST NOT assume it can be dereferenced.
At 9:44 AM +0000 1/31/05, Graham wrote:
I'm trying to say that even if I'm using HTTP URIs, client software should not create a link to that address in the interface and has no valid reason to try downloading it.
This is a good addition as well.
This contrasts with RSS 2.0 where guid is by default a permalink, and RSS 1.0 where rdf:about is required to be the same as rss:link.
...and that is a *very* good reason to include it in the document.
--Paul Hoffman, Director --Internet Mail Consortium
