Re: ID wording

[Walter Underwood <wunder@xxxxxxxxxx>]

I'll try this again, but referencing the wording directly.

--On Wednesday, August 18, 2004 01:57:48 PM -0700 "Paul Hoffman / IMC" 
<phoffman@xxxxxxx> wrote:
> Greetings again. Thanks for keeping the moratorium on ID discussion. I
> thought it would be best to do a sanity check to be sure people were in
> agreement on what it seems the consensus so far was.
>
> - The format for IDs is going to be URIs, not plain strings.

This is a change from Tim Bray's declaration of consensus on Aug 5.
That was for "canonical URIs", not "URIs".

There was one objection, on the grounds that there might be some
RDF out there with non-canonical URIs and that those might end up
in Atom feeds. We can address those by making URI a MUST and
canonical URI a SHOULD, explaining that the SHOULD is only for
legacy IDs.

We have talked about legacy data with LiveJournal dates, so making
exceptions for legacy IDs makes sense, but only if there really are
non-canonical URIs IDs in major implementations. If they are not common,
make canonical URI a MUST.

> - IDs MUST be compared character-by-character, no case-mapping, no %xx
> conversion, and so on.

This is safe for canonical URIs, though there is no need to
forbid fancier comparisons which also work on canonical URIs.
If canonical URIs are a SHOULD, then this is a MUST. If they
are a MUST, then this is implementation advice for fast compare,
but not a MUST for protocol correctness.

In short, we MUST have either canonical URIs or char-by-char
compares. The former is easier to test and probably more robust.
The latter is simple to implement and probably faster (no
canonicalization step).

Personally, I prefer robustness over premature optimization,
but I haven't seen consensus on that.

> - Receiving and gateway systems MUST NOT alter IDs in any way.

This makes sense for gateways. I don't see how it applies to
"receiving systems" whatever they are. Is there something that
gateways are supposed to alter? Shouldn't they leave entries
unaltered anyway?

Perhaps this is a requirement on how entries are stored when
they are not in protocol units? Maybe "IDs MUST NOT be altered
when stored, transmitted, or recieved".

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek