It’s just data

Draft Atom IETF charter

AtomI've posted a draft IETF working group charter for Atom on the wiki.  I've presumptuously placed my name as (one of the) chairs of this group, but there really shouldn't be any surprises in this draft.

In March, I expect the names of the IETF director(s) and advisors to be filled in, each bullet in the description to be replaced by a paragraph, and dates to be determine in the goals and milestones section.


Are the IM references in the Goals and Milestones because of copy and paste syndrome or do you really expect to fit in with IMPP documents?

Posted by Adrian Bateman at

Adrian: EEK!  Removed.  Thanks!

Posted by Sam Ruby at

"The working group will use draft-nottingham-atom-format-02"

I know it's not all been constructive, but are you really planning to disregard all of the work and discussion done on the mailing list in the last 2 months? Seems a little harsh.

Posted by Graham Parks at

Graham, absolutely not!  Note that I am proposing that the IETF working group use that exact same mailing list to do its business.

The question is whether that input should be rolled into a final round of updates, or whether there should be a series of interim updates.  Watching various places around the blogosphere, I'm seeing various noises about how rapidly Atom is evolving and people wanting to wait until it slows down.  While this puzzles me, it is something that needs to be dealt with. 

My thought at the moment is to make the increments further apart so that adoption and experience with the current revision of the spec can be used as feedback into the process.

Posted by Sam Ruby at

OK. But you need to be clearer about these things.

Having snapshots closer together would seriously help the process of improving the spec, which is surely the most important thing? If there'd been a couple more snapshots in the last month or two, we'd be in a much better position to declare it stable for a few months, and everyone would be happy. 0.3 has a couple of big flaws that should have been fixed ages ago.

(btw The dates in your RDF feeds have the timezone set incorrectly. The RSS 2.0 one is fine though)

Posted by Graham Parks at

I definitely agree with Graham's suggestion. Release early, release often.

Posted by Dare Obasanjo at

Graham, the dates in my RSS 1.0 feed have been fixed.  Thanks!

Posted by Sam Ruby at

It would also be helpful if the specs themselves were converted to wiki pages around which a set of discussion pages can be created for each section.  Controversial paragraphs should also be given a discussion page.

This way, the specs can be used as the points of reference.

Posted by Don Park at

This is rather brilliant. I haven't been able to keep up with the pace of the Atom movement lately, and thus have fallen off the wagon. Completely. I have 1302 unread messages in my «Atom-syntax» folder. I have no clue of what's the latest topic, what needs to be done, or how the spec looks like at the moment. This wiki page might help to bring me up to date.

I'm looking forward to seeing it evolve, and hope I can contribute something to the process (again).

Posted by Asbjørn Ulsberg at

Sam Ruby has posted a Draft Atom IETF charter to the Wiki: I've presumptuously placed my name as (one of the) chairs of this group, but there really shouldn't be any surprises in this draft. In March, I expect the... [more]

Trackback from Finally Atom

at

Great stuff - forward movement.

I think there probably has been enough discussion for another draft of the format spec, even if most of the change is just clarifications - though increments do pile up! I reckon we need a show of hands on a http POST fallback (from PUT, DELETE) before any changes there.

Don: I posted a copy of the format spec to the Wiki [link] a while back, at the time the API seemed settled enough not to need the same degree of tweaking.

Posted by Danny at

Danny, IMHO the Wiki version should be THE spec until it's approved at which point it can be switched into an annotated spec.  Otherwise, it loses it's usefulness as the point of reference just as a picture of the Empire State Building is not a point of reference.

As the approval process, I suggest that everyone who is currently on the list of supporters be given a vote to cast.  If the vote is not decisive (i.e. 5% difference) then the chair (Sam) gets to decide.

Posted by Don Park at

That sounds reasonable, Don. +1.

Posted by Asbjørn Ulsberg at

Note that the IETF process doesn't look to voting. It requires a rough consensus, which means that while not necessarily unanimous a dominant body of opinion must be in support. It is the role of the WG chair(s) to determine consensus.

"We reject kings, presidents and voting. We believe in rough consensus and running code."

Posted by Adrian Bateman at

Whatever.  I never participated in an IETF process before although I might do that just to have a reason to visit Korea. :-p

Posted by Don Park at

IETF working groups do not always reach consensus. The XMPP and SIMPLE groups were created because the original IM working group could not reach consensus on whether the new protocol should be XML or SIP based. There were good arguments for both sides, and the chair decided (with the area director) to forward both proposals for further work.

The better technology will survive. (That's the theory at least)

Posted by Christian Mogensen at

That's sort of what happened. The IMPP group spawned three different groups to produce different implementations of protocols that would be interoperable with a common communications profile. A consensus was achieved using RFC's 2778 and 2779 with the addition of the common profile documentation produced by the IMPP group. However, you are correct that consensus couldn't be reached on the content of the protocol itself. Sometimes reaching consensus in the IETF means reducing the scope of what you want to achieve. XMPP wasn't one of the original three groups and was added to this effort some time later.

Posted by Adrian Bateman at

Good stuff Sam. Fwiw, I agree with Graham and would rather see faster releases.

Posted by Bill de hOra at

Simple examples

Sam: People who want to produce a syndication feed in a consistently correct manner will find that they will need to master not only the syndication format, but also HTML, and XML. Randy: People who want to produce a syndication feed in a...

Excerpt from iBLOGthere4iM at

W3C and Atom

Being a librarian, I have become partial to standards that start with the letter Z like Z39.50. But I also...... [more]

Trackback from LibraryPlanet.com

at

Add your comment