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
