Paul Hoffman wrote:
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.
Not what I meant.
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.
How about this:
[Last sentence of the first paragraph, combined 3.5.1 and 3.5, altered first paragraph in "Comparing"]
3.5 Identity Constructs
An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content MUST be a URI, as defined by [RFC3986]. Note that the definition of "URI" excludes relative references. The URI might use a dereferencable scheme, but Atom Processors MUST NOT assume it can be dereferenced.
When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its Identity construct MUST NOT change. Put another way, an Identity construct pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their Identity constructs.
atomIdentityConstruct = atomCommonAttributes, (atomUri)
The content of an Identity construct MUST be created in a way that assures uniqueness, and it is suggested that the Identity construct be stored along with the associated resource.
Because of the risk of confusion between URIs that would be equivalent if dereferenced, the following normalization strategy is strongly encouraged when generating Identity constructs:
o Provide the scheme in lowercase characters.
o Provide the host, if any, in lowercase characters.
o Only perform percent-encoding where it is essential.
o Use uppercase A-through-F characters when percent-encoding.
o Prevent dot-segments appearing in paths.
o For schemes that define a default authority, use an empty
authority if the default is desired.
o For schemes that define an empty path to be equivalent to a path
of "/", use "/".
o For schemes that define a port, use an empty port if the default
is desired.
o Preserve empty fragment identifiers and queries.
o Ensure that all portions of the URI are UTF-8 encoded NFC form
Unicode strings.3.5.1 Comparing Identity Constructs
Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. Processors MUST compare Identity constructs on a character-by-character basis in a case-sensitive fashion. Comparison operations MUST be based soley on the URI character strings, and MUST NOT rely on dereferencing the URIs.
As a result, two URIs that resolve to the same resource but are not character-for-character identical will be considered different for the purposes of Identifier comparison.
For example, "http://www.example.org/thing";, "http://www.example.org/Thing";, "http://www.EXAMPLE.org/thing"; and "HTTP://www.example.org/thing"; will all be considered different identifiers, despite their differences in case.
Likewise, "http://www.example.com/~bob";, "http://www.example.com/%7ebob"; and "http://www.example.com/%7Ebob"; will all be considered different identifiers, because URI %-escaping is significant for the purposes of comparison.
