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
