Atom Community Meeting Report

Search

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.

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:

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

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

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

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

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.