Subject: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)

From: The IESG <[email-masked]>
Date: Tue, 16 May 2006 12:53:22 -0700

The IESG has received a request from an individual submitter to consider the
following document:

- 'Atom Threading Extensions '
    <draft-snell-atompub-feed-thread-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-06-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 17 May 2006 01:20:09 +0100

> http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt

I'm -0 this becoming a Proposed Standard. I think this is really cool, 
has room for interop problems, probably has security issues, and thus is 
arguably premature/innovative and could be considered informational.

One reason I think it's cool is not for commenting support but for cheap 
full duplex/reliable messaging - traditionally a SOAP use case.

FTR, I have no implementation experience with Feed Thread, haven't 
studiously followed the discussion on atom-syntax and that basis feel my 
opinion doesn't count for that much.

== Multiple references

<thr:in-reply-to
            ref="tag:entries.com,2005:1"
            type="application/xhtml+xml"
            href="http://www.example.org/entries/1"/>

In particular the RNC:

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

varies in co-occurrence constraints.  No one attribute seems to be 
required in all cases, which is a problem imo (if I'm wrong I'll argue I 
still have a point that it's unclear what an implementor should look 
for). I think this will be an interop headache and that either ref or 
href should always be required. Naturally ref to atom:id is to spec the 
right choice, but in practice it seems the first thing anyone will want 
to do unless they are the authority for the comment *and* the entry is 
pull down what's being replied to via href. Otoh, mandating ref implies 
as yet undeployed/unstandardised lookup/query services for atom:id - we 
have enough experience now with identity lookup services 
(CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service 
won't ever be deployed uniformly, or will be deployed in a way that 
isn't some kind of SPOF or business model or outright failure. That, or 
the feature will end being limited to local cases where ref is preferred 
over href (point to point integrations come to mind, hence the mention 
of SOAP).

This of course is fallout from the way identity in Atom is specced, 
which is also a hedge. Feed Thread imvho should consider getting off the 
fence on id v link and providing guidance for follow on extensions.

== @rel optionality

[[[
  allow Atom clients that are not familiar with the in-reply-to
    extension to know that a relationship exists between the entry and
    the resource being responded to, publishers are advised to consider
    including a "related" link referencing a representation of the
    resource identified by the in-reply-to element.
]]]

I think to do anything useful with this relation you would have had 
enough code written to switch on thr:in-reply-to to begin with. It could 
be struck.

== Interop

There are multiple publishing options in terms of how to associate 
comments with entries/comments. That this hasn't bitten anyone yet seems 
to me to be a combination/result of lack of implementations targeting 
the feature, Atom's mU policy for extensions, and (possibly) a lack of 
experience with comment aggregation across publishing and aggregating 
authorities.

Do the WG believe this will work out with multiple authorities using 
multiple stacks?

== Security

[[[
As this specification defines an extension to the Atom Syndication
    Format, it is subject to the same security considerations as defined
    in [RFC4287].
]]]

I have a serious enough quibble with this statement (the ddos attack 
note notwithstanding). As an atom foreign markup extension, it's true on 
  the face of things, but the thr:reply-to semantics introduce 
attribution/repudiation issues as well as providing aggregator/planet 
spamming options. IOW thr:in-reply-to seems to standardise  the same 
attack/spam vectors we see in mail for feeds and this needs to be 
acknowledged given spam mail is a multi-billion dollar sinkhole (or 
industry depending on the pov). That's a dramatic way to state things 
sure, but not without some truth. So - where's the digest/sig hook? 
James, you know this stuff... :)

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 16 May 2006 18:05:08 -0700

Bill,

Thank you very much for the detailed feedback.  Comments inline.

Bill de hÓra wrote:
>[snip]

I am not opposed to informational status for the extension.  I would
prefer Standards Track, of course, but in general, In general, I have a
number of deep concerns over whether or not there is enough of a
consensus in the Atom community about the right ways of extending the
format.  It may very well make more sense to hold off on standardizing
any extensions to the format until the community has had more time to
figure out the "right" approach.  Perhaps it would also make sense to
consider a formal WG focusing on Atom extensions.

>[snip]

This design stems from a design decision to support responses to
resources that do not have an Atom representation (and therefore no
atom:id to reference).  Alternatively, the resource being responded to
may only exist as an entry within an Atom feed and therefore only be
referenceable via it's atom:id.  Or, the resource being responded to may
only exist as an item within an RSS feed that has no guid NOR a stable
URI that may be used to reference it.

We could require ref at a minimum. Doing so would require that
implementations using the element to reference non-Atom resources would
be required to come up with some way of uniquely identifying those
resources.  I think this is acceptable as I believe it safely covers the
majority of the use cases.

I do not believe that mandating ref would require any kind of atom:id
lookup mechanism.

> enough code written to switch on thr:in-reply-to to begin with. It could

Agree.

> Do the WG believe this will work out with multiple authorities using

What kinds of issues are you anticipating would be a problem?
Specifically, I'm not sure what you mean by "There are multiple
publishing options in terms of how to associate comments with
entries/comments."

Can you expand a bit on this?

> James, you know this stuff... :)

A statement could be added to the Security Considerations recommending
the use of XML digital signatures per RFC4287.  Also, a statement
describing the possibility for abuse, particularly in aggregator/planet
scenarios is a good idea.  I will work on beefing this up.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 May 2006 19:25:03 -0700

At 1:20 AM +0100 5/17/06, Bill de hÓra wrote:
>I'm -0 this becoming a Proposed Standard. I think this is really 
>cool, has room for interop problems, probably has security issues, 
>and thus is arguably premature/innovative and could be considered 
>informational.

These are not reasons to make something an Informational RFC. In the 
minds of developers, there is no difference between Informational and 
standards-track RFCs. The IETF's differentiation between types of 
RFCs has always been confusing, but that is not a reason for us to 
niggle on a particular document.

This document describes an extension to an existing standards-track 
document: it should either be on standards track or it should not be 
an RFC.

If the document has "room for interop problems", and/or security 
issues, they should be stated so that the sponsoring AD, and the IESG 
as a whole, can decide whether or not the document is ready to be an 
RFC, regardless of the type of RFC it will become.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 07:11:59 +0200

> document: it should either be on standards track or it should not be

Where is that written down? Didn't Julian just get some WebDAV
extensions approved as Experimental? You seem to be saying IETF
participants don't get to have anything other than a black/white
opinion on the readiness of this document. I disagree, and I also
think it's kind of inappropriate for you to be managing discussion in
this way. After all, it's not a WG document, is it? I would have said
this should go Experimental, but it's not clear that the author is
willing to change the document in any meaningful way, so there's no
experiment to conduct.

 Informational and Experimental RFCs

   The role of Informational RFCs is often debated in the IETF.  Many
   people like having them, particularly for specifications that were
   created outside the IETF but are referenced by IETF documents.  They
   are also useful for specifications that are the precursors for work
   being done by IETF Working Groups.  On the other hand, some people
   refer to Informational RFCs as "standards" even though the RFCs are
   not standards, usually to fool the gullible public about something
   that the person is selling or supporting.  When this happens, the
   debate about Informational RFCs is renewed.

   Experimental RFCs are for specifications that may be interesting, but
   for which it is unclear if there will be much interest in
   implementing them, or whether they will work once deployed.  That is,
   a specification might solve a problem, but if it is not clear that
   many people think that the problem is important, or think that they
   will bother fixing the problem with the specification, the
   specification might be labeled an Experimental RFC.  If, later, the
   specification becomes popular (or proves that it works well), it can
   be re-issued as a standards-track RFC.  Experimental RFCs are also
   used to get people to experiment with a technology that looks like it
   might be standards track material, but for which there are still
   unanswered questions.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 17 May 2006 09:39:10 +0100

Paul Hoffman wrote:

> standards-track RFCs. The IETF's differentiation between types of RFCs 
> has always been confusing, but that is not a reason for us to niggle on 
> a particular document.

Understood - thanks for educating me.

> If the document has "room for interop problems", and/or security issues, 
> they should be stated so that the sponsoring AD, and the IESG as a 
> whole, can decide whether or not the document is ready to be an RFC, 
> regardless of the type of RFC it will become.

Ok. I'll try to be more specific rsn.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 May 2006 14:41:11 +0200

I'm with Robert here.

To clarify what happened with the WebDAV specs he mentioned...:

- WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda, 
and currently is implemented only by two vendors. Thus, "experimental" 
seems to be absolutely the right category.

- WebDAV Redirect References (RFC4437) was on the working group's 
agenda, but in the end too few implementors seemed to be interested 
(again: two). Thus "experimental" wasn't what I would have hoped to
achieve, but at least this kind of publication preserves the effort that 
was invested, and it also documents running code in some implementations.

Best regards, Julian

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 17 May 2006 15:16:55 +0200

* Robert Sayre <[email-masked]> [2006-05-17 07:25]:
> I would have said this should go Experimental,

+1

We can wait and see what problems crop up in practice with the
contested attributes, and whether extensibility according to Sec
6.4. ff (or lack thereof) turns out to be paramount or, to borrow
Tim’s turn of phrase, a molehill.

If it works out, just reissue it; if not, there’s room to go back
and fix it.

Sounds reasonable enough to me.

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 May 2006 07:27:36 -0700

At 7:11 AM +0200 5/17/06, Robert Sayre wrote:
>Where is that written down?

RFC 2026.

>  Didn't Julian just get some WebDAV
>extensions approved as Experimental?

Maybe, but that's irrelevant. The fact that some WGs don't follow the 
IETF process doesn't mean we should do the same. If our AD (who is 
also the AD for WebDAV) wanted this document to not be on standards 
track, she would not have put out the IETF last call for the document 
to be on standards track.

>  You seem to be saying IETF
>opinion on the readiness of this document.

Correct.

>  I disagree, and I also
>this way. After all, it's not a WG document, is it?

Nope, and that's why I said it as an IETF process weenie, not as WG co-chair.

>  I would have said

If you want to change RFC 2026, that's fine, but this is not the 
right forum to do so.

--Paul Hoffman, Director

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 18:08:02 +0200

> >Where is that written down?

That's a long document that's been updated by other process RFCs. Care
to point me at the relevant section? I didn't see one.

> Maybe, but that's irrelevant.

I don't know much about the IETF, but I do know the process consists
mostly of the unwritten rules, rather than the written ones. So, it
seems to me that it is very much relevant.

In fact, I can quote you on this, from the initial Atom meeting at Sun
Microsystems.
"If you're big on process, the IETF probably isn't for you", or
something to that effect. Why the change of heart?

> The fact that some WGs don't follow the
> also the AD for WebDAV)

That's true in the sense that our AD is in the Apps area. However, Ted
Hardie is the AD advisor for WebDAV, and those documents were approved
before Lisa was an AD, IIRC. But, I suspect you knew all of that.

> wanted this document to not be on standards

OK, phrase it that way. Why does our AD want this document on the
standards track? It was clearly designed without much research, no
input from client implementers, and contains lots of extra cruft. We
also

-- 

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 May 2006 09:24:04 -0700

>to point me at the relevant section? I didn't see one.

Sections 4.1 describes what is appropriate for standards track; 
section 4.2 describes what is appropriate for Informational and 
Experimental RFCs.

--Paul Hoffman, Director

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 09:27:09 -0700

I find it utterly amazing that there is so much contention over two
optional attributes that serve a purely informational purpose.  If a
feed publishers includes them, and a particular feed consumer currently
doesn't see a use for them, that feed consumer can ignore them and
continue processing the feed with ZERO loss of function.

    "I've started thinking about my schema not as the definition of what
     this system needs right now but as the definition of what the data
     should look like if it's present instead."
       - Tim Ewald, "Making everything optional" [1]

There are some folks for whom the attributes will be useful.  I know,
for instance, that SixApart has found a use for them in some stuff they
are doing with Friendster.  I have also used the attributes in a
browser-based feed aggregator I've been toying around with.  Others may
not find a use for the attributes at all.  That's ok.  If you don't have
a use for them right now, **ignore them**.  If someone implements
support for the attributes and finds that they cause some sort of
significant interop issue, that's ok, that's why the IETF process is
iterative. "Proposed Standards" are not set in stone.  They can be
changed if implementation experience demonstrates that change is necessary.

Regarding whether this should be Experimental or a Proposed Standard, I
will defer to the judgement of the IESG, however, RFC2026 has the
following to say about "Proposed Standards":

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.
   ...
   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

Seems appropriate to me.

Regarding how The Evil Attributes could be used?  Given two replies links,

  <entry>
  ...
  <link rel="replies" href="1" title="Comments"
        thr:count="10" thr:when="2006-12-12T12:12:12Z" />
  <link rel="replies" href="2" title="Trackbacks"
        thr:count="5" thr:when="2006-11-11T11:11:121Z" />
  </entry>

You can display two buttons in a GUI.

  "Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)"
  "Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)"

- James

[1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx

---

From: John Panzer <[email-masked]>
Date: Wed, 17 May 2006 09:41:37 -0700

Experience report:  Our implementation of comments for AOL blogs  
includes the count information in a proprietary extension 
(aj:commentCount), precisely because we need the information for UI 
purposes.  We've found it useful and we'd like to use a more standard 
extension to help enable interoperability. 

The one issue we've had with it was with a partner who used a checksum 
on the retrieved file to determine if something has 'changed' in the 
feed.  We explained how they can use the update timestamps for that 
purpose and everything was solved.

I don't see any issue with these attributes.

-John

---

From: James M Snell <[email-masked]>
Date: Wed, 17 May 2006 09:47:01 -0700

Excellent, thank you.

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 18:40:47 +0200

>Where is that written down?

Don't see it in RFC2026. In fact, I don't see any of the process we're
encountering documented there.

I'm disappointed you didn't answer the more interesting and relevant
questions in my previous message.

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 17 May 2006 19:02:09 +0200

> I don't see any issue with these attributes.

Do you see Windows Feed Platform apps using these attributes? Probably not, huh?
Do you consider that lack of interoperation a feature?

> >optional attributes that serve a purely informational purpose.

Are we supposed to take this seriously? Since you can't coherently
defend a single design decision in the draft, it's safe to conclude
this document is not ready to be an RFC.

> > If a

Well, you clearly don't think they're important. But then you felt
compelled to change them back and got an instant stamp of approval
from our AD. What happened there?

-- 

Robert Sayre

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 17 May 2006 22:57:48 +0100 (BST)

My major issue here is not really whether or not those attributes exist
but the fact that there is no real review of their implications. We mainly
hear of how useful they can be for some existing implementations but it'd
be a shame to realize in a couple of years that they were in fact bringing
more issues than solving problems.

Call me paranoid or picky but I think a few questions that have been
raised here were valid ones. Besides this is the all point of this list
isn't it? ;)

Of course I wouldn't want the community to split.

- Sylvain

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 17 May 2006 16:58:36 -0700

> from our AD. What happened there?

I read this as implying causality between two events.  Those two  
events happened to be near each other in time but weren't causally  
related.  The changes just before the last revision had no impact on  
my decision to post an IETF Last Call for moving this proposal onto  
the standards track.  It could not have had an impact because I  
wasn't so closely tuned into the revisions of this draft that I  
noticed any particular change -- I just reviewed the version  
presented to me with the shepherding request.

My decision to shepherd this document was because I was asked, read  
the proposal, and felt it was not obviously too harmful and could be  
useful.  It's customary to ask the advising AD for a WG, to shepherd  
a document closely related to that WG.

My decision to recommend Standards Track was because I saw evidence  
of multiple independent implementations and even some  
interoperability testing.

I could still recommend Experimental instead of Standards Track if I  
learned of some possible harm to security/privacy or Internet health,  
or some deep barrier to interoperability, but I have not yet learned  
of a high enough risk+severity of such concerns to change my mind there.

I would be less likely to recommend Informational status for a  
document like this which has been implemented and has normative  
statements intended for implementors (e.g. it's not a requirements  
document or a design overview).  Confusingly, Informational is also  
used sometimes for documents which do not undergo significant  
community review (e.g. RFC-Editor submissions) but the 4-week IETF  
last call, previous postings to this list, and comments of  
implementors, combine to make this document one that is getting  
significant community review.

I hope that makes the situation clearer!

Lisa

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 18 May 2006 04:41:15 +0200

> > from our AD. What happened there?

My question has yet to be answered.

> of a high enough risk+severity of such concerns to change my mind there.

I think this is an excellent standard. If another individual, such as
myself, were to submit an individually authored document, it would
have to meet the same standard, right?

> I hope that makes the situation clearer!

Sure does!

-- 

Robert Sayre

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 May 2006 17:51:32 -0700

> My question has yet to be answered.

I answered your question as fully as I could from the information I  
know, as I reviewed one revision of the draft before agreeing to  
shepherd the document.  I can't tell you why James made any  
particular change from one draft to another but I don't find that  
question very relevant to the quality of the final document.

> have to meet the same standard, right?

Yes, along with the other considerations I mentioned earlier in that  
email, about usefulness, adoption and review.

>> I hope that makes the situation clearer!
Good :)

Lisa

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 19 May 2006 10:13:03 +0200

On 5/19/06, Lisa Dusseault <[email-masked]> wrote:
>
> I answered your question as fully as I could
>

Quite true, but I asked James.

-- 

Robert Sayre