Subject: RFC 4685 & linking to an atom entry

From: "Brian Smith" <[email-masked]>
Date: Fri, 14 Sep 2007 23:22:53 +0700

I am implementing RFC 4685, the threading extension. Section 3 says that the thr:in-reply-to/@ref attribute is mandatory. It further says that if the content producer does not know the atom:id of the linked-to-entry, then the producer should make one up, usually by copying the value of the @href attribute. 

This is it will almost always result in a bad value for @ref. Who is going to use the permalink to the HTML version of an entry as an atom:id? In fact, if you Google for "atom:id" then the first result is an article that goes into great detail to persuade us not to do so (http://www.google.com/search?q=atom:id). If anything, it would make more sense for an Atom(Pub)-enabled weblog to use the URI of the atom entry document as an atom:id. RFC 4685 should not force implementers to give the content consumer bad information.

In particular, if the content producer does not know of an appropriate atom ID to use for a thr:in-reply-to/@ref attribute, it SHOULD NOT include the attribute. Content consumers may always substitute the value of the @href attribute for a missing @ref if it feels like it really needs an atom:id using the same rules that are currently imposed on content producers. 

An example use case: I want to use my weblog to reply to an entry in other person's weblog, and I want to indicate this with thr:in-reply-to. The problem is that the other person only implements RSS 2.0 or some other wacky format, so he doesn't provide me with an Atom ID to use; in fact, I might have only the HTML permalink to his entry. (If the other person was to upgrade to some Atom-enabled weblogging software, then all his entries would have an atom:id. But, the atom:id his weblogging software chooses probably won't match the atom:id I made up for that resource.)

Regards,
Brian

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Sep 2007 09:49:36 -0700

Brian Smith wrote:
> I am implementing RFC 4685, the threading extension. Section 3 says that 
> the thr:in-reply-to/@ref attribute is mandatory. It further says that if
> the content producer does not know the atom:id of the linked-to-entry, then 
> the producer should make one up, usually by copying the value of the @href attribute. 

Well, it's a bit more than just "make it up"  What it says it that the
permalink SHOULD be used.    As it turns out, in my experience, the
permalink is quite quite often as the an id.

> [snip] 
> In particular, if the content producer does not know of an appropriate atom ID 
> to use for a thr:in-reply-to/@ref attribute, it SHOULD NOT include the attribute.
> Content consumers may always substitute the value of the @href attribute for 
> a missing @ref if it feels like it really needs an atom:id using the same rules
> that are currently imposed on content producers. 

As you point out, the ref attribute is mandatory.  If anything, I would
provide both the ref and href attributes.  There's no harm in providing
both.

> 
> An example use case: I want to use my weblog to reply to an entry in other person's 
> weblog, and I want to indicate this with thr:in-reply-to. The problem is that the 
> other person only implements RSS 2.0 or some other wacky format, so he doesn't provide 
> me with an Atom ID to use; in fact, I might have only the HTML permalink to his entry. 
> (If the other person was to upgrade to some Atom-enabled weblogging software, then all 
> his entries would have an atom:id. But, the atom:id his weblogging software chooses 
> probably won't match the atom:id I made up for that resource.)
> 

More than likely but that's not a huge problem.  The other person could
make all kinds of changes to their system that break the links others
have made to their resources.  It happens all the time on the web.  Care
need to be taken when using in-reply-to to link to anything that is not
an Atom entry.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 16 Sep 2007 07:19:49 +0200

Hi Brian,

* Brian Smith <[email-masked]> [2007-09-14 18:40]:
> This is it will almost always result in a bad value for @ref.
> Who is going to use the permalink to the HTML version of an
> entry as an atom:id?

anyone who wants to. An ID can be any valid URI, and HTTP URIs
are valid URIs, so they can be used as Atom IDs.

Tim Bray does that: http://www.tbray.org/ongoing/ongoing.atom

> In fact, if you Google for "atom:id" then the first result is
> an article that goes into great detail to persuade us not to do
> so (http://www.google.com/search?q=atom:id).

And Tim Bray goes into great detail to persuade you that you
should:
http://www.tbray.org/ongoing/When/200x/2004/05/28/LinksAndGuids

(I disagree with both of them on various points and have decided
to use urn:uuid: IDs instead.)

> In particular, if the content producer does not know of an
> appropriate atom ID to use for a thr:in-reply-to/@ref
> attribute, it SHOULD NOT include the attribute.

The rationale was to make it likely that encourage will do their
threading based on the same identifier even in cases where no
Atom ID is known.

> Content consumers may always substitute the value of the @href
> attribute for a missing @ref if it feels like it really needs
> an atom:id using the same rules that are currently imposed on
> content producers. 

So in both cases, a reply to something which has no known Atom ID
is threaded based on its URI.

> If the other person was to upgrade to some Atom-enabled
> weblogging software, then all his entries would have an
> atom:id. But, the atom:id his weblogging software chooses
> probably won't match the atom:id I made up for that resource.

This is a general problem. If @ref attributes could be omitted,
then then migrating from an Atom-unaware weblogging tool to an
Atom-aware one, @ref attributes will continue to be missing even
after Atom IDs are minted for the old entries.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>