Subject: Dereferencing Identity Constructs

From: Graham <[email-masked]>
Date: Sun, 30 Jan 2005 17:11:40 +0000

3.5.1  Dereferencing Identity Constructs

    The content of an Identity construct MAY be dereferencable (e.g.  an
    HTTP URI).  However, processors MUST NOT assume it to be
    dereferencable.

The first sentence doesn't say anything. The second is good but doesn't 
go far enough.

	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.

The second sentence is important since we're breaking from guid and 
rdf:about in RSS.

(Actually I think even having a section with this name is asking for 
trouble.

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jan 2005 19:10:23 -0800

At 5:11 PM +0000 1/30/05, Graham wrote:
>The first sentence doesn't say anything. The second is good but 
>doesn't go far enough.
>
>	The content of an Identity construct SHOULD NOT be 
>dereferenced, even when it comes from a

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).

>(Actually I think even having a section with this name is asking for trouble.

We could change it to "Not Dereferencing Identity Constructs"...

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 19:28:05 -0800

> mailing list last year (or was on and skipped over the permathreads).

Ditto.

> We could change it to "Not Dereferencing Identity Constructs"...

How about "Dereferencability of Identity Constructs"?

--
Mark Nottingham     http://www.mnot.net/

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 22:30:16 -0500

Paul Hoffman wrote:
>>     The content of an Identity construct SHOULD NOT be dereferenced, 
>> even when it comes from a

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.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 30 Jan 2005 23:08:11 -0500

> 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

---

From: Tim Bray <[email-masked]>
Date: Sun, 30 Jan 2005 20:22:21 -0800

On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:

> I'm +1 on this,

-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.  The language above could 
be read as discouraging what I'm planning to do, and what I'm planning 
to do is perfectly good practice.  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?  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Mon, 31 Jan 2005 16:16:20 +1100

> strings, and MUST NOT rely on dereferencing the URIs."

+1

---

From: Graham <[email-masked]>
Date: Mon, 31 Jan 2005 09:44:54 +0000

On 31 Jan 2005, at 4:22 am, Tim Bray wrote:

> OFor "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, 
> be dereferenced, but only in its <link> role.  The language above 
> could be read as discouraging what I'm planning to do, and what I'm 
> planning to do is perfectly good practice.

That's a valid bug in the wording.

> strings, and MUST NOT rely on dereferencing the URIs."

No. 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 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.

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 31 Jan 2005 09:19:56 +0000

>     The content of an Identity construct SHOULD NOT be dereferenced, 

Graham,

Would you go with "..MUST NOT rely on dereferencing.." instead?

cheers
Bill

---

From: Graham <[email-masked]>
Date: Mon, 31 Jan 2005 14:53:14 +0000

On 31 Jan 2005, at 4:08 am, Joe Gregorio wrote:

> of XML namespaces not withstanding).

Absolutely not Joe times one billion. Any such convention forming 
jeopardises the persistence of the identifier, since it will get 
changed when people re-organize their site or fiddle with their 
features. The id is an identifier and nothing else. Letting them change 
even once a year is harmful to anyone trying to compile an archive of a 
feed, and just plain shoddy.

Graham

---

From: Henry Story <[email-masked]>
Date: Mon, 31 Jan 2005 16:25:21 +0100

On 31 Jan 2005, at 05:22, Tim Bray wrote:
> For "ongoing", I plan to use the same http: URIs for both the 
> planning to do is perfectly good practice.  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 was thinking of doing something similar with BlogEd. An entry id 
would point to the
directory containing each version of an Entry. The link would probably 
point to the exact
Entry version described by the atom xml entry in which it appears. By 
dereferencing the id
link one could with correct access permissions, see all the versions of 
an entry. Though
the usual behavior would be to default to the last one.

Perhaps a directory tree like this

2005/01/31/entry1/                      <---- the id of all the entries 
below

2005/01/31/entry1/version1/             <---- the url of the link to 
the first version
2005/01/31/entry1/version1/entry.xml    <---- my first published entry 
in atom xml
2005/01/31/entry1/version1/entry.html   <---- first published entry as 
html

2005/01/31/entry1/version2/             <---- the url of the link to 
the second version
2005/01/31/entry1/version2/entry.xml    <---- my first published entry 
in atom xml
2005/01/31/entry1/version2/entry.html   <---- first published entry as 
html

so when, with a browser, you request http://.../2005/01/31/entry1/ you 
would always get the
latest version of the Entry in the format of the mime type requested.

And when you request http://.../2005/01/31/entry1/version1/ you get the 
first version
of your entry in the format of the mime type requested.

So my belief is also that if people really don't want id dereferenced 
they should
use a scheme specifically for that purpose. Those who do that may well 
have much
longer lived web sites, and their blogs may be more flexible in that 
they can be moved
from one server to the next -- but they may also be a lot more 
difficult to find.

One way to get people to have their cake and eat it too, may be to 
allow multiple id tags.
Since an id is an inverse functional relationship between an Entry a 
Resource this should
not cause any trouble. In any case there will never be any way you can 
limit the number of
names a thing has.

Henry Story

---

From: Tim Bray <[email-masked]>
Date: Mon, 31 Jan 2005 07:40:55 -0800

On Jan 31, 2005, at 6:53 AM, Graham wrote:

> features. The id is an identifier and nothing else. Letting them 
> change even once a year is harmful to anyone trying to compile an 
> archive of a feed, and just plain shoddy.

Uh, it seems that you're assuming that "can be dereferenced" is 
equivalent to "will be unstable".  I disagree. -Tim

---

From: Dan Brickley <[email-masked]>
Date: Mon, 31 Jan 2005 10:46:45 -0500

* Henry Story <[email-masked]> [2005-01-31 16:25+0100]
> >-1.  And I *will* lie down in the road.

-1 also; showstopper broken imho
(sorry to reply late in the thread; nearly missed this)

dan

---

From: Lance Lavandowska <[email-masked]>
Date: Mon, 31 Jan 2005 10:06:16 -0600

> How about "Dereferencability of Identity Constructs"?

That should discourage most everyone from reading that section.

Lance

---

From: Graham <[email-masked]>
Date: Mon, 31 Jan 2005 16:20:41 +0000

> equivalent to "will be unstable".  I disagree. -Tim

I agree it's possible for links to be stable. But giving the id a 
functional purpose as an address introduces all sorts of reasons to 
change the address from time to time where otherwise there would be 
none.

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2005 08:19:55 -0800

Hmmmm. The dead horse comes to life with more beating. At the risk of 
causing further consternation and time-wasting...

>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.

>of XML namespaces not withstanding).

Fine, but then they should duplicate the URL somewhere else in the entry/feed.

>  But I do believe

I'm OK with that wording, but prefer Graham's propsal.

At 8:22 PM -0800 1/30/05, Tim Bray wrote:
><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.
>
>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 
>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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 11:47:04 -0500

Paul Hoffman wrote:
>> 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.

> <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.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Jan 2005 08:55:07 -0800

At 11:47 AM -0500 1/31/05, Robert Sayre wrote:
>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
>

That covers my concerns quite well. +1

--Paul Hoffman, Director

---

From: Tim Bray <[email-masked]>
Date: Mon, 31 Jan 2005 09:56:24 -0800

On Jan 31, 2005, at 8:47 AM, Robert Sayre wrote:

>> be.

+1 -Tim