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