Subject: Feed Thread Question: Identifying Comment Feeds

From: "Roger B." <[email-masked]>
Date: Mon, 10 Apr 2006 18:05:28 -0500

James & Company: Is there any chance of seeing something added to the
spec that could identify a feed or entry as a subordinate comment,
rather than simply a reply?

Here are the situations I'm facing during test implementation... Entry
A is a blog posting, Entry B is a comment posted in response to Entry
A, and Entry C is a third-party blog posting that claims to be a reply
to Entry A.

(1) I consume Entry A, and then Entry B. I note Entry B's in-reply-to
id/ref, see that it matches Entry A, and thread the two together. All
is well.

(2) I consume Entry A, and then Entry C. I note Entry C's in-reply-to
id/ref, see that it matches Entry A, and thread the two together. All
is well.

(3) I consume Entry C, and then Entry A. Since Entry A did not yet
exist when I processed Entry C, I create new threads for both Entry C
and Entry A. All is (basically) well.

Here's where we get into trouble...

(4) I consume Entry B, and then Entry A. Since Entry A did not yet
exist when I processed Entry B, I create new threads for both of them.
Unfortunately, Entry B was never meant to stand alone in any real
sense, unlike Entry C.

If Entry B had a way to clearly convey that it needs Entry A to make
any sense, I could just ignore it until Entry A shows up. Absent such
a mechanism, I can't ignore anything, because for all I know, Entry B
is just like Entry C.

I guess what I'm looking for is an @isrealparent attribute on
in-reply-to. (Bad name, I know.) Just something that allows the
replying entry to assert a closer relationship to the other resource.

--
Roger Benningfield

---

From: James M Snell <[email-masked]>
Date: Mon, 10 Apr 2006 17:16:42 -0700

Roger,

I would model the behavior after the way most email clients (the ones
I've seen anyway) handle the SMTP In-Reply-To header. For example, in
thunderbird, if I receive a note that is a response to another that has
either not yet been received or has been deleted, that note shows up as
a new thread.  If the parent shows up later, the child thread is
automatically moved under the parent. To me, this is ok (desirable in fact).

In other words, I'm not so sure your fourth scenario really is a
problem.  That is, personally, I'd prefer that B was not ignored, even
if it didn't make much sense without A.

Also, a key advantage of thr:in-reply-to is the ability to specify the
source of the parent.  If the source attribute is specified, clients
that have not yet received the parent can go out and grab it.  In fact,
your scenario would make a very strong argument as to why publishers
should use the source attribute.

- James