Subject: Feed Thread approved as a Proposed Standard

From: James M Snell <[email-masked]>
Date: Fri, 23 Jun 2006 12:07:00 -0700

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.

- James

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jun 2006 21:34:38 +0200

> significantly improved through the open discussions and debate we had

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jun 2006 13:15:30 -0700

At 9:34 PM +0200 6/23/06, Julian Reschke wrote:
>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 is not correct that they *need* to be, but there is no reason for 
them not to be. In general:

- If a protocol is worked on in an open context, standards track is preferred

- If a protocol is worked on in private and the author doesn't want 
to take changes from others, Informational is most appropriate

- If a protocol is really an experiment that may not even get 
implemented, Experimental is most appropriate

>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).

It is not clear to me how people can so consistently misread RFC 
2026, which is the current definition for when something should be an 
Experimental RFC. Both examples you give are poster children for the 
Inappropriately Labelled RFC Foundation.

>(sorry for getting off-topic)

Not off-topic at all, given that we will probably have more 
extensions in the future.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 23 Jun 2006 16:34:09 -0400

> - If a protocol is worked on in an open context, standards track is preferred

The most important parts of an "open" context are well-documented
decisions. That didn't happen here.

It is surely appropriate for IETF members to suggest an alternate
status for the document, no matter what the IESG eventually decides.
In this case, an appeal to "the rules" was made, but RFC 2026 does not
place limits on the sort of feedback the community may give. In
effect, an effort was made to end the discussion, rather than address
the issue.

I don't feel the community has control of this document, and that bothers me.

n.b. -- not inviting a rebuttal.

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Fri, 23 Jun 2006 12:48:20 -0700

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jun 2006 14:02:55 -0700

>status for the document, no matter what the IESG eventually decides.

That's one view, and an unfortunately common one. The view I prefer 
is "follow RFC 2026 because no one is going to remember the logic for 
not following it after the RFC is published." Yes, I'm a bit of a 
priss about these things...

>place limits on the sort of feedback the community may give.

Correct. It is up to the IESG to decide on a case-by-case basis if 
there was adequate discussion.

>I don't feel the community has control of this document, and that bothers me.

Once something is an RFC, the "community" has "control" in that an 
effort can be made to obsolete a document with a new one, or extend a 
document with a new one. That is weak control because it takes a lot 
of effort and elapsed time, and it might not succeed. Fortunately, 
anyone can form a "community" if they feel like doing the work; they 
might be listened to. (This in contrast with other standards bodies 
that do not allow revisions by random developers or other interested 
parties.)

--Paul Hoffman, Director

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 23 Jun 2006 17:20:39 -0400

On 6/23/06, Paul Hoffman <[email-masked]> wrote:
> effort can be made to obsolete a document with a new one,

I guess those scare quotes are appropriate, but the underlying point
is that I now have a Proprietary Standard designation for this
document. That's a bummer, because the stewardship of RFC4287 is also
in a similarly worrisome state. Open standards are not made by people
paid to write mailing list posts until everyone else gives up. I know
I don't have the bandwidth to cut through the brazen obfuscation
anymore.

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Sat, 24 Jun 2006 14:21:20 -0400

On 6/23/06, Paul Hoffman <[email-masked]> wrote:
> The view I prefer

I'm alarmed that this specification is on the standards track in a
vendor-controlled namespace.

<http://purl.org/maint/search_user.pl.cgi?userid=^JASNELL$>

I notice Sam Hartman raised this point in IESG discussion, but I don't
see a record of its resolutoin. What were the procedures followed, and
how can it be said that the IETF has change control here?

-- 

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Sat, 24 Jun 2006 12:09:32 -0700

It's not a vendor controlled namespace; it's an individual controlled
namespace that I'm more than happy to delegate to the IESG.

The IETF has complete change control of the spec at this point --
including changing the XML namespace used by the extension if doing so
would be appropriate.  I trust the IESG and the RFC editor to do
whatever is deemed to be appropriate.

- James

p.s. FUD is generally more effective when not based on generally false
and easily refuted assumptions

---

From: "Robert Sayre" <[email-masked]>
Date: Sat, 24 Jun 2006 17:46:10 -0400

On 6/24/06, James M Snell <[email-masked]> wrote:
> namespace

Irrelevant.

> that I'm more than happy to delegate to the IESG.
>

The IESG approved it with no directions to the RFC editor. So your
conjecture comes at the wrong juncture. If you were qualified to
answer my message, that would be obvious. I'll note that you failed to
answer a single question I asked, which tells me they were good ones.

> and easily refuted assumptions

This is content-free flaming. But I'll note there was nothing false in
my message. And you didn't refute anything either. I'd say you're just
trying to intimidate people.

-- 

Robert Sayre