I put this on the standards track (as opposed to being experimental)
primarily for the fact that it is currently being used in production
environments. IBM and SixApart, for instance, have both deployed
non-experimental applications that utilize the extension.
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. -- http://www.ietf.org/tao.html#anchor44
I believe that it's already clear that there is interest in implementing
feed thread and that the spec will work.
Regarding the bit about extensions needing be on the standards track
because Atom is, I think that's wrong. There is a place for
experimental RFC's, in fact, that's likely where things like the feed
rank and person construct extensions are likely to initially end up.
- James
Julian Reschke wrote:
> James M Snell schrieb:
>> Just a general FYI..
>>
>> The IESG has approved the Atom Threading Extensions (aka "feed thread")
>> as a Proposed Standard making it the first standardized syndication
>> extension. It is now in the RFC Editors queue and will be assigned an
>> RFC #.
>>
>> I would like to extend my thanks and appreciation to the members of the
>> WG who offered constructive feedback on the spec. I know we all didn't
>> see eye-to-eye on various aspects of the extension, but the spec was
>> significantly improved through the open discussions and debate we had
>> here on the list.
>
> Congratulations.
>
> Related to this, I'd still like to find out the background history on
> why this is on the standards track. It was claimed that extensions to
> standards track documents need to be on the standards track as well, but
> that doesn't seem to be correct, as far as I can tell. It certainly
> doesn't make sense (because it would prohibit experimental extensions to
> standards track protocols), nor does it reflect past decisions (for
> instance, see RFC2774 and RFC4437).
>
> (sorry for getting off-topic)
>
> Best regards, Julian
>
