Atom Community Meeting Report

Herewith notes and reporting from the Atom Community Meeting, June 2nd at Sun’s Santa Clara campus. I’ll update this fragment all day and see how that goes. IRC is irc://irc.freenode.net#atom, lots of people there. I’m writing this in chronological order, not blog order, so the new stuff is at the bottom. Here are Walter Underwood’s notes. [Update: 4:40PM]

Hoffman on IETF · Read The Tao of the IETF. Paul’s not really saying much that isn’t in that document. 250 people on atom-syntax; we got two waves of subscriptions, one connected to the IETF charter submission, and a second when the W3C put up its hand. Important: per IETF rules, everything material and official has to happen on the mailing list. Not on the wiki, not at IETF meetings, on the mailing list. ¶

General discussion of how consensus is established. Bob Wyman: “If you’re asking about process, the IETF is the wrong place for you.” Eric Miller: “The workload on an editor is about the same in both organizations.” ¶

Miller on W3C · W3C is a membership organzation, 60+ full-time staff. They work on social engineering, but determined people can drive things off the rails. W3C technical infrastructure is good. Lots of focus on internationalization and accessibility. ¶

Eric is explaining the Working-Group/Interest-Group setup. IG was very important in the RDF and XML processes. ¶

Discussion of the fact that W3C culture is to take decisions in the face-to-face and telecon conference, as opposed to all-mailing-list IETF. ¶

Relative Merits · There is little support for a joint IETF-W3C approach. ¶

Discussion of the advantages/disadvantages of doing things in a closed room where marketeers can’t see & issue competing press releases. ¶

If Atom goes to IETF, the W3C staffers probably won’t participate; they have day jobs. ¶

Mark Nottingham worries about intervention at the W3C from other interested parties, e.g. WSDL, RDF, etc etc. ¶

TBray: We’ve invested a lot of work in the IETF option, so the W3C would have to win by a more than 5% margin to make it attractive to me. ¶

Substantial disagreement in the room as to whether the W3C has a better IPR story to tell than the IETF. ¶

MNot again: in the IETF it’s easier to shut down a solo raving loony. W3C consensus-seeking could really stretch out the process in an area like Atom with a history of contentiousness. ¶

Eric on the W3C: The advantages of the test-cases and spec translation stuff at the W3C. Also, the co-ordination with all the other work is a feature not a bug. Things happen faster when it’s part of people’s day jobs. ¶

Don Park: W3C Specs have a tendency to keep rolling out new versions. Hoffman agrees: When you supercede an RFC, it’s usually a multi-year process and often never happens. Underwood: In W3C, a Version 2 charter could be written going off in an entirely different direction. TBray: W3C tech infrastructure is excellent (mailing lists, IRC, etc.) ¶

We held an IETF-style "group hum" to see which way the room was leaning, and the leaning was heavily in the direction of the IETF. ¶

Multi-Part Entry Posting · Now we’re discussing the issue of how to post multi-part entries (including graphics or other binary objects). ¶

Two use-cases: First, an ongoing post with a couple of flower pictures, each in large and small versions. Second, a cellphone with a camera: take a snap, write a caption, post to blog. ¶

There seem to be the following proposed solutions in play: ¶

1. Do nothing, post non-top-level resources top a different URI. Apparently Six Apart does this now. ¶

2. The <html:object> proposal; borrow the semantics of HTML’s object element. ¶

3. The “DontSyndicate” proposal, put your non-textual object in an <atom:entry> but add an attribute saying “Don’t put this in the top-level feed or syndicate it.” ¶

4. The <atom:resource> proposal, like the previous one only use an element other than entry (might have a very similar content model). ¶

5. The MIME-type proposal; package all the pieces up in a mime/multipart message (binary OK). ¶

A crucial decision point seems to be whether you try to package up multiple pieces in one message, or not. ¶

MNot suggested that for posting non-top-level binary components (pictures etc.) we don’t need Atom at all, just use HTTP Post and get back where it landed in Content-location. ¶

Now the idea has come up of just using a small subset of WebDAV. While WebDAV is a great big thick complicated spec, it is claimed that the lower levels of the protocol are really minimal and easy to understand. ¶

So, Kevin Marks and John Panzer are advocates for the naked-HTTP plus WebDAV approach; Steve Jenson for the <atom:resource>. We seem to have killed #2, #3, and #5 from the list above. ¶

Other Issues · Heh, Dave Orchard got remotely tasked to write up a proposal for getting extensibility points right, with MustUnderstand and MustIgnore and so on. ¶

Computers · Looking around the table, I see 11 Macintoshes and 3 other computers, including Robert Sayre’s drop-dead-cool little Vaio with integral camera and so on. ¶

Compound Feeds · Use-case raised by PubSub, but has lots of applications: he wants to publish a feed containing entries from lots of different feeds, so how do we cram the provenance information into the individual entry elements? Most popular suggestion seems to be a subelement of <atom:entry> called <provenance> or something that replicates arbitrary feed-level elements. ¶

It turns out that this is a hard problem with icky corner cases and lots of tricky bits. This group doesn’t have a solution at hand; PubSub is going to charge ahead try to figure it out, and we’ll see what we all learn.