Subject: Feed thread updates

From: James M Snell <[email-masked]>
Date: Fri, 19 May 2006 10:47:09 -0700

All,

I am preparing an update to the Feed Thread draft based on the Last-Call
feedback received so far.  The intent is to publish an update in time
for the May 26 cut-off date that has been set for the next IETF
face-to-face being held in Montreal in July.

Before sending that draft off, I wanted to run a number of the proposed
changes by the WG and request that folks weigh in on whether or not they
think the changes appropriately address the issues raised in the recent
discussions.  If you do not feel the changes appropriately address the
issues, if would be very helpful if you would please either list the
specific issues not addressed or, better yet, propose some alternative
spec text that you think would deal with the issue more appropriately.

First, there is the question over the thr: attributes. To handle these
concerns, I would like to insert the following:

== snip ==
Considerations for using thr:count and thr:when

The thr:count and thr:when attributes provide additional metadata about
 a resource linked to an Atom feed or entry using the "replies" link
relation. The values are intended to make it easier for feed consumers
to display basic contextual information about the thread of discussion
without requiring those consumers to dereference, parse and analyze the
linked resource. That said, there are a number of considerations
implementors need to be aware of.

First, the thr:count and thr:when attributes MUST NOT be considered to
provide completely accurate information about the thread of discussion.
 That is, the  actual total number of responses contained by the linked
resource MAY differ than the number specified in the thr:count
attribute.  Feed publishers SHOULD make an effort to ensure that the
meta is accurate.  The non-authoritative nature of "external reference
metadata", like the replies link attributes, is discussed in detail in
section 3.3 of the W3C document "Tag Finding 12: Authoritative Metadata"
<xref target="TAG12" />.

Second, the values of the thr:count and thr:when attributes are
volatile. Frequent updates to the value of the attributes, or to any
part of the Atom document, could have a detrimental impact on the
cacheability of Atom documents using the attributes, leading to an
increase in overall bandwidth consumption.

Feed publishers MUST consider a change to the thr:count and thr:when
attributes to be an "insignificant" update, meaning that the value of
the containing feed, entry or source element's atom:updated element MUST
NOT be affected by a change to the values of either of these attributes.

Lastly, implementors need to be aware that while the Atom specification
 <xref target="RFC4287" /> explicitly allows the link element to contain
arbitrary extensions, the specification does not require that
implementations support such extensions.  Specifically, relating to the
use of extensions, Atom does not define any level of mandatory
conformance on the part of feed consumers beyond a requirement that
implementations ignore any extension the implementation does not
understand. As a result, some implementations MAY NOT be capable of
fully utilizing the extensions defined by this or any specification.
== snip ==

Regarding the thr:in-reply-to element, there was a concern raised over
the optionality of the ref and href attributes and a potential for
interop issues.  There was also a suggestion that the spec include a
comparison to the in-reply-to header defined by RFC 2822.  To address
these concerns, I propose making the following change:

== snip ==
The "in-reply-to" element is used to indicate that an entry is a
response to another resource. The element MUST contain a "ref" attribute
identifying the resource that is being responded to.

The element is not unlike the references and in-reply-to email message
headers defined by <xref target="RFC2822" />, with the exception that,
unlike those headers, the "in-reply-to" element is required only to
identify the unique identifier of a single parent resource as opposed to
the listing all of the unique identifiers for each preceding resource in
the thread.  If the entry is a response to multiple resources,
additional "in-reply-to" elements MAY be used.

  in-reply-to =
    element thr:in-reply-to {
      atomCommonAttributes,
      ref,
      href?,
      source?,
      type?,
      ( undefinedContent )
    }

  ref = attribute ref { atomURI }
  href = attribute href { atomURI }
  type = attribute type { atomMediaType }
  source = attribute source { atomURI }

The "ref" attribute specifies the persistent, universally unique
identifier of the resource being responded to.  The value MUST conform
to the same construction and comparison rules as the value of the
atom:id element. Though the IRI might use a dereferenceable scheme,
processors MUST NOT assume it can be dereferenced.

If the resource being responded to does not have a persistent,
universally unique identifier, the IRI used to retrieve a representation
of the resource MAY be used so long as that IRI could also be used as a
valid atom:id value and so long as the "href" attribute is also specified.
== snip ==

A concern has been raised over what it means when an feed/entry/source
contains multiple replies links (e.g. are they links to alternative
representations of the same set of comments, are they links to different
sets of comments, etc).  To address this concern, I propose adding the
following statement:

== snip ==
While Atom feed, entry and source elements MAY each contain any number
of atom:link elements using the "replies" link relation, this
specification assigns no significance to the presence or order of
multiple replies links.

Multiple replies links appearing within an atom:entry may reference
alternative representations of the same set of responses, or may
reference entirely distinct resources containing entirely distinct sets
of responses. Processors MUST NOT assume that multiple replies links are
referencing different representations of the same resource.
== snip ==

I will also be making additional updates to the Security Considerations
portion of the draft.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 19 May 2006 11:15:13 -0700

I stand corrected... the cut off is *June* 26th, not *May* 26. (thanks
Peter).  Either way, please take a look at the changes and let me know
your thoughts.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 20 May 2006 04:21:02 +0200

Hi James,

> Considerations for using thr:count and thr:when

I’d still like thr:when called thr:updated, as it follows the
same semantics as atom:updated and its value is of the same type.

> That is, the  actual total number of responses contained by the
> linked resource MAY differ than the number specified in the
> thr:count attribute. Feed publishers SHOULD make an effort to
> ensure that the meta is accurate.

This SHOULD seems way too prescriptive. If you keep this sentence
at all, I suggest changing to an informal “may want to.”

> Feed publishers MUST consider a change to the thr:count and
> thr:when attributes to be an "insignificant" update, meaning
> that the value of the containing feed, entry or source
> element's atom:updated element MUST NOT be affected by a change
> to the values of either of these attributes.

I would clarify this “an "insignificant" update in terms of RFC
4287”. However, I am not sure what this MUST buys, and more
importantly, how it could be enforced. Suggesting SHOULD instead.

> Lastly, implementors need to be aware that while the Atom
> specification <xref target="RFC4287" /> explicitly allows the
> link element to contain arbitrary extensions, the specification
> does not require that implementations support such extensions.

This concern could be partially addressed by including an element
to specify a global reply count for an entry in an atom:entry
Metadata element. The cost of such an inclusion is insignificant,
and there are benefits for all consumers, including those which
can support the namespaced link attributes. I strongly suggest
adding such an element.

I am willing to draft spec language for it if you want me to.

> additional "in-reply-to" elements MAY be used.

This is an inaccurate description of the RFC 2822 headers.
Suggest the following:

    The element is not unlike the references and in-reply-to
    email message headers defined by <xref target="RFC2822" />.
    However, unlike the in-reply-to header, the "in-reply-to"
    element is required to identify the unique identifier of only
    a single parent resource. If the entry is a response to
    multiple resources, additional "in-reply-to" elements MAY be
    used. There is no direct equivalent to the references header,
    which lists the unique identifiers of each preceding message
    in a thread.

> universally unique identifier, the IRI used to retrieve a
> representation of the resource MAY be used so long as that IRI
> could also be used as a valid atom:id value and so long as the
> "href" attribute is also specified.

It would improve interop if multiple disparate publishers
publishing a response to the same resource were led to pick the
same identifier, so I suggest changing this MAY to SHOULD.

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

---

From: James M Snell <[email-masked]>
Date: Fri, 19 May 2006 21:26:36 -0700

> same semantics as atom:updated and its value is of the same type.

I'm still stewing over this and haven't quite made up my mind on it yet.
 The only reason I'm not quite comfortable with it is that it just seems
confusing have both an atom:updated and a thr:updated.

> at all, I suggest changing to an informal “may want to.”

"may want to" is a little too weak for me, but yes, the SHOULD is too
much.  Let me think about it.  If I can't come up with something better,
I'll use the "may want to" suggestion.

> importantly, how it could be enforced. Suggesting SHOULD instead.

Making this a MUST will (hopefully) reduce the likelihood false-updates
for clients that don't understand FTE. That is, if I use a client that
does not understand FTE and I suddenly see an entry that is marked as
updated for no apparent reason, I'm likely to get quite annoyed after a
while.

(note that I included this after running some tests on a couple of feed
readers and discovered that it is indeed quite annoying)

> I am willing to draft spec language for it if you want me to.

Yeah, I'm still stewing over this. I've started and stopped writing a
section for this about a dozen times over the last couple of days.  On
the one hand, it makes a lot of sense for the spec to have this.  On the
other, I could imagine feed reader implementors being quite pissed off
that they have to support an element with identical
form/function/semantics as slash:comments just so feed publishers can
avoid having to declare one additional xml namespace.  Also consider
that even if FTE declares a <thr:count>5</thr:count> element, most folks
are likely going to keep on using slash:comments.   (I mean, heck, look
at the number of Atom 1.0 feeds that are still using <dc:subject> to
indicate the category!!)

The other elements/attributes in FTE don't suffer from this problem
because they introduce useful new functionality/semantics while also
reducing the number of xml namespaces that need to be declared.

I dunno, I guess I'm not really against having the element; I'm just
having a hard time getting myself to define it.

>     which lists the unique identifiers of each preceding message

Yeah, I got to thinking the same thing after I posted the note.  Your
text is much better.

> same identifier, so I suggest changing this MAY to SHOULD.

Good suggestion.

> Regards,

Thanks for taking a look

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 20 May 2006 07:12:37 +0200

* James M Snell <[email-masked]> [2006-05-20 06:40]:
> I'm still stewing over this and haven't quite made up my mind
> on it yet. The only reason I'm not quite comfortable with it is
> that it just seems confusing have both an atom:updated and a
> thr:updated.

How so? I honestly can’t follow that. Explain?

> >> That is, the actual total number of responses contained by
> >> the linked resource MAY differ than the number specified in
> >> the thr:count attribute. Feed publishers SHOULD make an
> >> effort to ensure that the meta is accurate.
> > 
> > This SHOULD seems way too prescriptive. If you keep this
> > sentence at all, I suggest changing to an informal “may want
> > to.”
> 
> "may want to" is a little too weak for me, but yes, the SHOULD
> is too much. Let me think about it. If I can't come up with
> something better, I'll use the "may want to" suggestion.

Oh wait. I was bewildered because I read it as “Feed aggregators”
rather than “Feed publishers.” Sorry! Comment retracted, the
SHOULD is perfectly appropriate.

> >> element's atom:updated element MUST NOT be affected by a
> >> change to the values of either of these attributes.
> > 
> > I would clarify this “an "insignificant" update in terms of
> > RFC 4287”. However, I am not sure what this MUST buys, and
> > more importantly, how it could be enforced. Suggesting SHOULD
> > instead.
> 
> Making this a MUST will (hopefully) reduce the likelihood
> false-updates for clients that don't understand FTE. That is,
> if I use a client that does not understand FTE and I suddenly
> see an entry that is marked as updated for no apparent reason,
> I'm likely to get quite annoyed after a while.
> 
> (note that I included this after running some tests on a couple
> of feed readers and discovered that it is indeed quite
> annoying)

That means it falls into the “compliance cannot reasonably be
tested but non-compliance is likely to cause interop problems”
bucket, which is exactly when a SHOULD is appropriate.

> > This concern could be partially addressed by including an
> > element to specify a global reply count for an entry in an
> > atom:entry Metadata element.
> 
> […] I could imagine feed reader implementors being quite pissed
> off that they have to support an element with identical
> form/function/semantics as slash:comments just so feed
> publishers can avoid having to declare one additional xml
> namespace.

I dunno; it seems like a drop in the bucket compared to the rest
of the spec, and if they’ve already implemented slash:comments
semantics it seems like the effort to support an equivalent
element in another extension is minimal.

> Also consider that even if FTE declares a
> <thr:count>5</thr:count> element, most folks are likely going
> to keep on using slash:comments. (I mean, heck, look at the
> number of Atom 1.0 feeds that are still using <dc:subject> to
> indicate the category!!)

If they were previously already using it, sure. I’m willing to
bet money that next to noone who implemented Atom 1.0 support
from scratch is doing that, though. Rather, I’d posit that these
are (nearly?) all template-based Atom 0.3 implementations that
were upgraded to Atom 1.0 with minimum effort.

I believe that those who come to Atom 1.0 with a clean slate
benefit from the inclusion of a native atom:category element, and
likewise those who come to the FTE with a clean slate will
benefit from the inclusion of a native atom:entry Metadata
element equivalent to slash:comments.

Regards,

---

From: James M Snell <[email-masked]>
Date: Sat, 20 May 2006 09:50:02 -0700

> How so? I honestly can’t follow that. Explain?

Two different things with the same name can lead to confusion...  I
dunno, I guess it boils down to just a personal preference.

>[snip]

:-)

>[snip]

Ok, that's fine.  SHOULD gets the point across.

>[snip]
>[snip] 

I wish I shared your optimism :-) ... if you want to draft up some text,
I'll include it.

- James

---

From: cedric <[email-masked]>
Date: Mon, 22 May 2006 12:01:10 +0200

> same semantics as atom:updated and its value is of the same type.
+1