Subject: XML2004Hackathon

From: steve jenson <[email-masked]>
Date: Wed, 20 Oct 2004 12:13:52 -0700

Sofar, only 5 people have signed up for the Interop Hackathon at 
XML2004[*]. I want to book my reservations but is this going to be 
cancelled as the last IETF Meeting did?

If so, let's put together an IRC channel and a time/date to have this 
interop hackathon.

Thanks,
Steve

[*]http://www.intertwingly.net/wiki/pie/XML2004Hackathon

---

From: Tim Bray <[email-masked]>
Date: Sun, 24 Oct 2004 11:45:43 -0700

> If so, let's put together an IRC channel and a time/date to have this 

It's been paid for, it's totally not gonna be canceled.  There may be 
only 10 or so of us there, so what?  But.... having an IRC channel is a 
good idea.  -Tim

---

From: Greg Stein <[email-masked]>
Date: Sun, 24 Oct 2004 16:09:22 -0700

> only 10 or so of us there, so what?  But.... having an IRC channel is a 

Because Steve has no reason to go to the conference *other* than the Atom
interop. If we're going to test Blogger with one other piece of software,
then it is much more preferable for Steve to pick up the phone and talk to
that person.

As of right now, there are only three pieces of software listed. It is
*very* hard to justify Steve's time and expense for what could otherwise
be accomplished with an afternoon conference call.

Cheers,
-g

---

From: Tim Bray <[email-masked]>
Date: Sun, 24 Oct 2004 19:53:02 -0700

> be accomplished with an afternoon conference call.

FWIW, I'm going to try to construct a client from scratch -T

---

From: Dave Beckett <[email-masked]>
Date: Mon, 25 Oct 2004 12:03:08 +0100

> only 10 or so of us there, so what?  But.... having an IRC channel is a

I've added details of the #atom channel on irc.freenode.net to the wiki page.
It's a permanent and publically logged channel that I've been providing
for the atom group for some months, available for use 24x7.

Dave

---

From: "Mark Birbeck" <[email-masked]>
Date: Mon, 25 Oct 2004 15:55:53 +0100

Greg,

> Because Steve has no reason to go to the conference *other* 
> than the Atom interop. If we're going to test Blogger with 
> one other piece of software, then it is much more preferable 
> for Steve to pick up the phone and talk to that person.
> 
> *very* hard to justify Steve's time and expense for what 
> could otherwise be accomplished with an afternoon conference call.

I sympathise with Google having to keep an eye on its expenses budget ;) --
and since I will not be heading for XML 2004 and the Hackathon, I thought
I'd list here some of the issues with the Blogger.com Atom API. (Though if
there is a way to remotely join the event on the day, we'll make every
effort to do so.)

Background -- we have implemented an Atom client using declarative mark-up,
namely XForms [1]. During the course of this we identified a number of
problems with Blogger's Atom API implementation, as follows:

 * GET SOAP requests don't return well-formed XML (link tags are opened but
   never closed). This is such a fundamental problem that I don't know how
   other people are managing to use your API, unless either (a) they are
   using SAX and so can be a bit more tolerant of errors, or (b) they do
   what we have to do and use the atom.xml document.

 * Since we can't use GET SOAP requests, then we have to use the initial
   feed (atom.xml) to obtain the item list. However, since there is a delay
   after publication before this document is updated and ready, we can't
   update a blog and then immediately re-request the list, we have to wait.
   We're hoping that this is not a problem when we are able to use the GET
   SOAP request.

 * Authentication doesn't seem to be implemented correctly, so a replay
attack
   would be possible.

 * PUT SOAP requests seem to incorrectly require that certain attributes are
   *not* present.

 * atom:content wraps all text with html:div, including content that is
already
   contained in a div, which means that if you do nothing about it you get
an
   ever growing number of blank lines as you edit and re-edit.

I hope that helps, and it would be great to see these issues solved.

Regards,

Mark

[1] <http://www.imc.org/atom-syntax/mail-archive/msg10741.html>

Mark Birbeck
CEO
x-port.net Ltd.

e: [email-masked]
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

---

From: Danny Ayers <[email-masked]>
Date: Mon, 25 Oct 2004 19:16:29 +0200

On the subject of blogger.com Atom, I also tried unsuccessfully to get
a SOAP client to work, as have others, check this blog post
(especially comments):

http://dannyayers.com/archives/2004/10/02/it-just-works/

It sounds like Mark was able to get over the hurdles that stopped me.
It would be great to see the issues resolved. If that happens in the
next few weeks then Blogger's interface will get a little bit of free
publicity in a book on the subject.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Mark Birbeck" <[email-masked]>
Date: Mon, 25 Oct 2004 19:14:50 +0100

Danny,

Yes, we too had many hair-pulling moments!

In fairness to Blogger, the *really* big problem I would say is not
returning XML from a SOAP GET, since without that feature you can't get the
workflow on the client right. In other words is prevents you from building a
'correct' application.

That's not, of course, to say that the other issues aren't important, but
things like being open to a replay attack are hopefully just things that
will get sorted soon, and since we've implemented our client to use nonces
correctly, it will hopefully 'just work' when it is fixed.

Since we have managed to get over many of the hurdles, anyone who is having
problems building a Blogger client in whatever language they are using might
find it useful to look at our XForms client [1]. Even if you don't install
formsPlayer, and instead just look at our code, you'll probably find some
useful stuff in there.

Regards,

Mark

[1]
<http://www.formsplayer.com/demo/web-services/atom-blogging/atom-blogger-com
.html>

Mark Birbeck
CEO
x-port.net Ltd.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Danny Ayers
> Sent: 25 October 2004 18:16
> To: Mark Birbeck
> Cc: Greg Stein; [email-masked]; Tim Bray
> Subject: Re: XML2004Hackathon
> 
> 
> 
> On the subject of blogger.com Atom, I also tried 
> unsuccessfully to get a SOAP client to work, as have others, 
> check this blog post (especially comments):
> 
> It sounds like Mark was able to get over the hurdles that 
> stopped me. It would be great to see the issues resolved. If 
> that happens in the next few weeks then Blogger's interface 
> will get a little bit of free publicity in a book on the subject.
> 
> Cheers,
> Danny.
> 
> -- 
> 
> http://dannyayers.com
> 
> 
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Oct 2004 14:34:40 -0400

>  * PUT SOAP requests seem to incorrectly require that certain attributes are

I found that SOAP PUTS seemed to have PostURI POST request body 
constraints applied. Blogger wouldn't let me send <modified /> and 
required <generator>. This assumes draft-gregorio-09 support.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Oct 2004 17:55:24 -0400

Mark Birbeck wrote:
> Robert,
> Good detective work! That does seem to explain most of them, although we
> also found that atom:issued was not allowed, and that is actually required
> by both EditURI/PUT and PostURI.
> 

That's not my experience. MobileAtom J2ME[0] sends atom:issued and it 
works fine. However, your observation about the nesting divs was a new 
one on me, and I verified it in my implementation. I swear it didn't 
used to do that.

Robert Sayre

[0] http://www.franklinmint.fm/2004/09/27/mobile_atom.html

---

From: "Mark Birbeck" <[email-masked]>
Date: Mon, 25 Oct 2004 22:48:24 +0100

Robert,

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: "Mark Birbeck" <[email-masked]>
Date: Mon, 25 Oct 2004 23:04:21 +0100

Robert,

> > ... although 
> > we also found that atom:issued was not allowed, and that is 
> actually 
> > required by both EditURI/PUT and PostURI.
> > 
> 
> works fine.

Thanks for that -- we'll check it again. Perhaps we formatted the date
wrong, or something.

> However, your observation about the nesting divs 
> was a new 

I couldn't say how long it's been there, because we only recently managed to
get the authentication working, and so have only recently started drilling
into the detail.

> [0] http://www.franklinmint.fm/2004/09/27/mobile_atom.html

Looks very good, and a useful tutorial. Thanks for the reference.

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: steve jenson <[email-masked]>
Date: Mon, 25 Oct 2004 16:39:51 -0700

>    what we have to do and use the atom.xml document.

Digging through the code, I see where this bug is, and a couple of unit 
tests will pin it down.

>  * Authentication doesn't seem to be implemented correctly, so a replay

We're going to be moving to Basic over HTTPS by the end of this year so 
I don't plan to fix this. If we were going to keep it long-term, it 
would definitely be fixed.

>    ever growing number of blank lines as you edit and re-edit.

I will fix.

> I hope that helps, and it would be great to see these issues solved.

Thank you for the feedback, it's been super helpful. I will get these 
issues taken care of. I apologize for the crappy state of our SOAP API.

In general, I think this highlights the need for a strong 
community-supplied test suite. The only one I know of is bikini, which 
doesn't look very active. Does anybody know the status of this or any 
other public test suite that I could contribute to?

-steve

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 25 Oct 2004 17:05:23 -0700 (PDT)

> would definitely be fixed.

Doesn't this run counter to Section 3.7 of the most
recent draft of the Atom API spec at
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt
which requires one of either HTTP Digest or CGI
authentication (whatever the hell that is) ?

So you plan to wilfully ignore the spec in this
regard? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: steve jenson <[email-masked]>
Date: Mon, 25 Oct 2004 17:14:53 -0700

> So you plan to wilfully ignore the spec in this

I'm afraid we have no option for implementing Digest, just
like many other providers.

Steve

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Oct 2004 20:18:56 -0400

> like many other providers.

So far, the requirements in that section of the draft have gotten a 
rather cool reception. I now agree that it's kind of silly to require a 
certain authentication mechanism. What if someone only wants their 
service available through full Kerberos authentication? Seems silly to 
say such a service isn't compliant.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 25 Oct 2004 17:27:34 -0700 (PDT)

> say such a service isn't compliant.

There are two points here. The first is that the spec
implies that if clients support CGI or Digest
authentication they should be covered when it comes to
authentication. However we have a major blogging tool
vendor claiming that they plan to ignore that part of
the spec which makes the spec not worth the much. 

More importantly, restricting what authentication
mechanisms people can use is just plain silly. 

Perhaps we should take this to atom-protocol? 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Walter Underwood <[email-masked]>
Date: Mon, 25 Oct 2004 17:53:27 -0700

> mechanisms people can use is just plain silly. 

No, it is all about interoperability. If a server and a client
implement incompatible set of auth mechanisms, they cannot talk.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 25 Oct 2004 20:45:01 -0400

> like many other providers.

That section shouldn't be so explicit. It should be 
reworded to encourage (via SHOULD) both RFC 2617 compatible 
authentication and also some sort of encryption, such 
as HTTPS.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 25 Oct 2004 18:05:26 -0700 (PDT)

> implement incompatible set of auth mechanisms, they

So? The spec does not prevent that from happening
since I can create a client that doesn't support auth
or only supports one kind of authentication. 

Preventing more sophisticated authentication
mechanisms in capable clients the name of
interoperability doesn't seem like a good idea in
today's extremely malicious and hostile Web. 

=====

---

From: Danny Ayers <[email-masked]>
Date: Tue, 26 Oct 2004 12:50:40 +0200

On Mon, 25 Oct 2004 20:45:01 -0400, Joe Gregorio <[email-masked]> wrote:

> That section shouldn't be so explicit.

+1

SHOULD on Digest and/or HTTPS

I thought this had been dealt with ages ago. Mandating a single
mechanism (e.g. Bob's) is inappropriate in such a heterogeneous
environment. It should to be acceptable to build a zero-authentication
Atom system, use cases include Wikis and whistleblowers. But a typical
Atom system ought to contain something sturdier than HTTP Basic.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Mark Birbeck" <[email-masked]>
Date: Tue, 26 Oct 2004 14:16:38 +0100

Danny,

That all seems reasonable, but there would therefore need to be a way to
tell an Atom client which security mechanism to use for a particular system.

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

> Sent: 26 October 2004 11:51
> To: Joe Gregorio
> Cc: steve jenson; Dare Obasanjo; atom syntax list
> I thought this had been dealt with ages ago. Mandating a 
> single mechanism (e.g. Bob's) is inappropriate in such a 
> heterogeneous environment. It should to be acceptable to 
> build a zero-authentication Atom system, use cases include 
> Wikis and whistleblowers. But a typical Atom system ought to 
> contain something sturdier than HTTP Basic.
> 
> Cheers,
> Danny.
> 
> -- 
> 
> http://dannyayers.com
> 
> 
>

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 26 Oct 2004 12:16:18 -0400

> tell an Atom client which security mechanism to use for a particular system.

That's what a status code of 401 and the 
WWW-Authenticate: header are for.

    -joe

---

From: "Mark Birbeck" <[email-masked]>
Date: Wed, 27 Oct 2004 11:18:06 +0100

Joe,

> > That all seems reasonable, but there would therefore need 
> to be a way 
> > to tell an Atom client which security mechanism to use for a 
> > particular system.
> 

Yes, but that's incredibly long-winded ... you have to fail before you know
how to succeed. And also, if you have an Atom feed that contains references
to entries that are on a number of different servers, you have to fail again
for each server. In fact you may need to fail for each operation, because if
we give one URL for new entries and another for edits, we might choose to
use different security mechanisms for each.

(Note also that WWW-Authenticate is protocol dependent, which -- so far --
much of Atom is not.)

It seems to me that since the Atom architecture is very much about being
able to find interact points 'dynamically', then all we would need to see is
some information that tells us what security technique to use when accessing
a particular URL. We can then avoid the trial and error approach, have a
different security mechanism for each URL if we wanted to, and not fix
things to any particular protocol.

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 27 Oct 2004 08:39:43 -0400

> things to any particular protocol.

So... to avoid fixing things to a particular protocol we should
try to fix things to a specific authentication mechanism?

    -joe

---

From: James Aylett <[email-masked]>
Date: Wed, 27 Oct 2004 14:09:36 +0100

> try to fix things to a specific authentication mechanism?

I don't understand why this is Atom's problem at all. When Atom is
working over HTTP and needs authentication, it uses HTTP
authentication. If someone wants to transfer Atom over BEEP, say, then
an appropriate authentication can be used there.

On Wed, 27 Oct 2004 11:18:06 +0100, Mark Birbeck wrote:

> That's incredibly long-winded ... you have to fail before you know
> how to succeed.

But only the first time; thereafter you can remember what to do next
time. And the only place we can guarantee knows which mechanism to use
is the endpoint that handles it. Anything that points to that endpoint
could hint about mechanisms all it likes and still be incorrect.

> In fact you may need to fail for each operation, because if we give
> one URL for new entries and another for edits, we might choose to

The producer might, but it's not that likely. And if they really
wanted that, it was for a reason. Is a single 401 round-trip during
first connection that costly? And even if it is, how do we make the
hinting mechanism sufficiently flexible that it will work for non-HTTP
transports?

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: "Mark Birbeck" <[email-masked]>
Date: Wed, 27 Oct 2004 14:49:16 +0100

Joe,

> So... to avoid fixing things to a particular protocol we 
> should try to fix things to a specific authentication mechanism?

No ... And I'm trying to see how you could read that into what I said. I
apologise if I didn't explain things very clearly.

I can ask a server for a list of entries, and the server will give me both
the list, and a set of URLs with which I can interact with those entries in
the list. My suggestion is that we really need to have some additional
information from the server to tell us what security information is required
when we interact with those URLs. Ideally we would have one piece of
metadata for each URL, so that not only can some 'blog service' have its
security mechanism set, but each entry could also be accessed with a
different mechanism.

So I am saying the opposite of what you inferred.

Regards,

Mark 

Mark Birbeck
CEO
x-port.net Ltd.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 27 Oct 2004 10:44:11 -0400

On Wed, 27 Oct 2004 14:49:16 +0100, Mark Birbeck
<[email-masked]> wrote:
> the list.

Are you assuming here that accessing the FeedURI does 
not require authentication?

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Wed, 27 Oct 2004 10:51:50 -0400

> security mechanism set, but each entry could also be accessed with a

I disagree that we "really need" it. The requirement that each entry be 
accessible with a different authentication mechanism, yet remain under 
one user's control seems outlandish to me. Wouldn't most people just 
pick a single scheme that allowed flexible definitions of protection 
spaces, such as HTTP Digest?

Robert Sayre

---

From: "Mark Birbeck" <[email-masked]>
Date: Wed, 27 Oct 2004 15:49:18 +0100

Joe,

> not require authentication?

No ... but I was assuming that the whole thing was bootstrapped via the
atom.xml-type file that Blogger.com and others have (which is obtained with
a simple GET). Is that incorrect?

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 27 Oct 2004 11:16:15 -0400

> a simple GET). Is that incorrect?

Ah, ok, that *is* different from the FeedURI. In the 
case of blogger that file is only a GET, but a GET that
requires authorization.

    -joe

---

From: "Mark Birbeck" <[email-masked]>
Date: Wed, 27 Oct 2004 16:40:20 +0100

Joe,

> > No ... but I was assuming that the whole thing was bootstrapped via 
> > the atom.xml-type file that Blogger.com and others have (which is 
> > obtained with a simple GET). Is that incorrect?
> 

I understand.

However, just to clarify what we're talking about here, I'm suggesting that
the following list of entries might be both possible and desirable:

  <feed>
    .
    .
    .
    <entry>
      <link
       href="http://www.blogger.com/atom/8535154/109842389265952253"
       rel="service.edit"
       title="Yet another test"
       type="application/atom+xml"
      />
      .
      .
      .
    </entry>
    <entry>
      <link
       href="http://piki.bitworking.org/atom.cgi/SomeWikiWord"
       rel="service.edit"
       type="application/atom+xml"
      />
      .
      .
      .
    </entry>
    .
    .
    .
  </feed>

As you can see here, the first entry comes from Blogger.com, and the second
from a Wiki maintained using Atom. Each could have different authentication
mechanisms, and until I try to save my changes -- and get a 401 -- I can't
find out what they are.

Going further, I don't see why I couldn't also have something like this:

    <entry>
      <link
       href="http://piki.bitworking.org/atom.cgi/SomeWikiWord"
       rel="service.edit"
       type="application/atom+xml"
      />
      <link
       href="smtp:[email-masked]"
       rel="service.edit"
       type="application/atom+xml"
      />
      .
      .
      .
    </entry>

Here the challenge/response mechanism might be separated by hours or days.
Anyway, I think you can see what I'm getting at.

As to how I 'get' a document that looks like this; it might have come from
my own local machine, as I add a link to every document that I ever wrote,
or my blogging client software may do the same, or it might even be from an
online service, provided by The-next-big-company-after-Google which allows
me to keep a list of all my blogs and anything I've ever written. But all my
point was, that the very flexibility of the Atom architecture already means
that you could be interacting with many different servers.

I hope that explains where I am coming from.

Best regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 27 Oct 2004 13:06:08 -0400

> mechanisms, and until I try to save my changes -- and get a 401 -- I can't

I understand that different implementations could have different
authentication mechanisms. Do you have a proposal for how
to address this besides the traditional 401 mechanism built into
HTTP? 

    Thanks,
    -joe

---

From: Greg Stein <[email-masked]>
Date: Wed, 27 Oct 2004 11:09:24 -0700

On Wed, Oct 27, 2004 at 11:18:06AM +0100, Mark Birbeck wrote:
>...

But that is exactly how HTTP is specified, and how it has worked for many
years. I don't see the need to redesign that or come up with other
solutions. Note that some clients have a way to cache authentication
information and they'll proactively supply it to the server when they
connect (which saves the round-trip you mention).

IMO, I don't see this as a problem. This is simply how HTTP works.

>...

The Atom publishing protocol *is* HTTP specific. Completely. I haven't
heard of any desire nor attempt to deal with protocols other than HTTP. So
I'd suggest that being "specific" is not a problem.

Cheers,
-g

---

From: "Mark Birbeck" <[email-masked]>
Date: Wed, 27 Oct 2004 19:42:35 +0100

Greg,

> > (Note also that WWW-Authenticate is protocol dependent, which -- so 
> >far --  much of Atom is not.)
> 
> The Atom publishing protocol *is* HTTP specific. Completely. 
> I haven't heard of any desire nor attempt to deal with 
> protocols other than HTTP. So I'd suggest that being 
> "specific" is not a problem.

OK .... I'd like to see Atom less protocol-dependent. ;)

Many of the services around at the moment already offer the ability to blog
via email, for example. How is that specified in Atom? From what you've
said, it just isn't. Anyone that offers such a feature simply 'steps
outside' of the Atom protocol. That doesn't bode well for the future, as
people add blogging via mobile phone, email, SMS messages, or whatever.
Surely we need to be able to express end-points dynamically?

As of today, our XForms processor can already 'submit' XML documents in many
different ways from the same form, including via SMTP. So, we could easily
extend our formsPlayer blogging client demo to send updates via email by a
simple change in the submission element -- no additional code. Except we
can't, because we currently could not get the end-point information at
run-time, and so would need to hard-code the email address.

I realise it's not completely trivial to add such a feature, but I suggest
it's worth considering how dependent Atom should be on HTTP if Atom is to
fulfil its promise.

Regards,

Mark

Mark Birbeck
CEO
x-port.net Ltd.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 27 Oct 2004 21:03:40 +0100

Mark Birbeck wrote:

> [...]

Pedantry: Atom isn't depedendent on HTTP - it's a data format and as 
far as I can tell is neutral to transport and application protocols.

The Atom protocol otoh is designed to work smoothly with HTTP; 
perhaps it should be renamed Atom-over-HTTP to avoid confusion.

Seeking protocol neutrality in a protocol spec at the level we're 
talking about (HTTP, SMTP, Jabber, SMS) invites us to make the same 
kinds of mistakes that the WS family of specs has made and is 
currently tried to dig itself out of. Having seen how things are 
working out on that front, I'd like to avoid us repeating the same 
mistakes.

cheers
Bill

---

From: Brett Lindsley <[email-masked]>
Date: Thu, 28 Oct 2004 06:45:35 -0500

Mark,

I have also been having similar thoughts on Atom bindings to protocols. 
An example I
made in passing some time ago (one that I have a lot of working 
experience with) is a
comparison to SyncML specs. SyncML specifies the protocol (MSCs) and 
document syntax,
but then has several bindings to different protocols ( HTTP *and* OBEX).

I also believe Atom specifications should decouple the protocol/syntax 
from the actual
protocols and object framing to make it more flexible and future-proof 
it. This would make
Atom more flexible.As a silly example, one could run OBEX over TCPIP 
(port 650)
with Atom on top of OBEX.

Brett Lindsley, Motorola Labs

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 28 Oct 2004 08:02:55 -0400

From our charter[1]:

"The feed format and HTTP will be used as the basis
of work on a standards-track document specifying the editing
protocol."

[1] http://www.ietf.org/html.charters/atompub-charter.html

    -joe