Subject: Atom Notification Protocol Published

From: James Snell <[email-masked]>
Date: Thu, 16 Dec 2004 13:46:00 -0800

(cross posted to both the Syntax and Protocol mailing lists)

I have published the first draft of the Atom Notification Protocol. 
It is available at
http://www.ietf.org/internet-drafts/draft-snell-atompub-notification-00.txt

I would like to discuss the possibility of this work being picked up
by the working group. It may even be feasible to incorporate this into
the main body of the Atom Protocol spec. In the meantime, however,
please take a look and review the draft and please comment on the
protocol mailing list.
-- 
- James Snell
  http://www.snellspcae.com/blog
  [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Dec 2004 14:44:38 -0700

In article <[email-masked]>,

> please take a look and review the draft and please comment on the

It's not clear to me from the I-D as written exactly what functionality 
happens as a result of the protocol you've defined. The I-D states:

   A notification request containing an Atom Entry is intended to 
   notify the receiving endpoint that a specific entry has been 
   created or updated.

What is "the receiving endpoint"? Does the publisher do a POST to a 
special HTTP URI for every receiving endpoint?

It would be interesting to contrast your approach with the approach some 
other folks (me included) have defined using XMPP pubsub:

http://ietf.org/internet-drafts/draft-saintandre-atompub-notify-01.txt

Peter

---

From: James Snell <[email-masked]>
Date: Fri, 17 Dec 2004 15:17:34 -0800

> happens as a result of the protocol you've defined. The I-D states:

If you mean what I think you mean with "what functionality happens as
a result of the protocol"  then the functionality is implementation
specific.  In other words, the only semantic for this protocol is that
one party wishes to notify another party that either an Entry or a
Feed has been updated.  What happens as a result of that notification
is entirely up to what the receiver of the notification is set up to
do.

> special HTTP URI for every receiving endpoint?

Yes, the "receiving endpoint" is an HTTP URL to which a POST operation
is performed, passing in a Feed or Entry element as the entity.

> http://ietf.org/internet-drafts/draft-saintandre-atompub-notify-01.txt

The XMPP approach defined looks good.  What I was wanting to achieve
with this was an approach that could be a fairly simple and natural
drop in replacement for the existing Trackback and Ping mechanisms. 
Each of those use basic HTTP POST operations without the need for XMPP
support. For XMPP-enabled environments,
draft-saintandre-atompub-notify-01 is Goodness. Not every environment
is going to be XMPP-enabled.  Just about everyone is HTTP POST
enabled.

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 18 Dec 2004 02:34:18 -0500

James Snell wrote:
> For XMPP-enabled environments, draft-saintandre-atompub-notify-01
> is Goodness. Not every environment is going to be XMPP-enabled.
> Just about everyone is HTTP POST enabled.
	I think that focusing on the differences between XMPP and HTTP POST
is not really useful in this discussion. Each transport protocol has
advantages in one or another environment. What's interesting is not the
transport protocol but rather the payload that is transported! (i.e. The
slogan "It's about the Entries, Stupid!" applies in this case.)
	I think the important point is that there probably isn't a great
deal of justification for having different payload formats for these
protocols. If we strip away the XMPP and HTTP "transport" wrappers,
overhead, etc. I don't see any reason why it would be useful to have
different messages.

	bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 18 Dec 2004 02:42:34 -0500

I would strongly recommend that it be required that an atom:entry that is
published with no enclosing atom:feed MUST contain an atom:head element. If
this is not the case, the published atom:entries will be essentially
anonymous and thus largely useless. Virtually every Atom processor in
existence requires elements of atom:head when handling entries. I can
imagine very few applications (other than closed ones) that could make use
of atom:entries that do not contain atom:head elements and are not
themselves enclosed in atom:feeds.

		bob wyman

---

From: James Snell <[email-masked]>
Date: Mon, 20 Dec 2004 15:36:42 -0800

> slogan "It's about the Entries, Stupid!" applies in this case.)

You're absolutely correct of course.

> overhead, etc. I don't see any reason why it would be useful to have

Honestly I do not know enough about the use cases of the XMPP based
mechanism to pass judgement on their payload formats.  What I can say,
however, is that for the Atom Notification Protocol (ANP) approach,
nothing more than the entry and feed elements are necessary.  If we
can get some alignment between this and the XMPP stuff, wonderful, but
I'd very much like to avoid adding anything else to the ANP payloads

---

From: James Snell <[email-masked]>
Date: Mon, 20 Dec 2004 15:33:42 -0800

Requiring atom:head in entries posted without an enclosing feed is
fine.  I'll go ahead and make that change.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Dec 2004 10:52:40 -0700

In article <[email-masked]>,

> I'd very much like to avoid adding anything else to the ANP payloads

Well, I think we need to have consistency on what Bob is calling the 
"message" or "payload", which in both cases would be pure Atom, no 
(ignoring the "wrapper" elements that, for instance, define semantics in 
XMPP pubsub). I'll review both documents more closely to make sure that 
we have consistency.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Dec 2004 10:46:38 -0700

In article <[email-masked]>,

> themselves enclosed in atom:feeds.

That makes sense. I probably won't publish another version of the 
Atom-over-XMPP draft until Atom becomes more stable, but I'll at least 
add this to my working copy of the I-D.

Peter

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Dec 2004 08:38:29 +1100

On 18/12/04 5:42 PM, "Bob Wyman" <[email-masked]> wrote:

> anonymous and thus largely useless.

From the spec: 

    The "atom:author" element is a Person construct that  indicates the
    default author of the entry. atom:entry elements MUST contain exactly
    one atom:author element, unless, in an Atom Feed Document, the atom:head
    element contains a atom:author element itself. atom:entry elements
    MUST NOT contain more than one atom:author element.

Seems pretty clear to me that an atom entry outside of an Atom Feed Document
wouldn't be anonymous. <contributor> has similar rules. Looking at the list
of elements one would find in a <head> leaves me wondering what other
elements you might want.

Some entries are posted into multiple feeds simultaneously ... would you
want the entry to have multiple head-in-entry elements? How does that fit
your data model?

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 21 Dec 2004 19:44:33 -0500

Eric Scheid wrote:
> Looking at the list of elements one would find in a <head> leaves
> me wondering what other elements you might want.
	Title, Link, Author, tagline, and others... As well as any
"extension" stuff that might be there. For instance, at somepoint, we're
going to get some way to associate an image with a feed as is done with RSS.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Wed, 22 Dec 2004 16:33:48 +1100

On 22/12/04 11:44 AM, "Bob Wyman" <[email-masked]> wrote:

> "extension" stuff that might be there.

Feed specific stuff is useful for identifying and filling out the feed, but
they don't (shouldn't) have much bearing on the entries themselves.

> For instance, at somepoint, we're going to get some way to associate an image
> with a feed as is done with RSS.

But that image is associated with the *feed*, not the *entry*.

Consider the entry which is simultaneously published in multiple feeds --
does that somehow change the nature of the *entry* itself, other than the
context of circumstance?

And if an entry could exist in multiple feeds, is it possible an entry could
exist without being in any feed? Finding such entry might be a tad
difficult, or maybe not ... it might be a side-entry linked from a regular
feed-entry, and thus discoverable.

    <link type="application/atom+xml" rel="note" href="..." />

Are you suggesting that before an entry can be authored, a feed must first
be established into which it would then be placed?

e.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Dec 2004 16:51:43 -0700

In article <[email-masked]>,
 Peter Saint-Andre <[email-masked]> 
 wrote:

> In article 
> <[email-masked]>,

Forgive my ignorance, but I don't see any examples of atom:head within 
atom:entry, and the spec does not contain a schema. Is head allowed 
within entry?

Peter

---

From: James Snell <[email-masked]>
Date: Thu, 23 Dec 2004 11:45:37 -0800

Head elements in the entry have been discussed on the list and are
described here: http://www.intertwingly.net/wiki/pie/PaceHeadInEntry. 
AFAIK, The proposal has been accepted and is slated for incorporation
into the draft.

---

From: Brett Lindsley <[email-masked]>
Date: Wed, 29 Dec 2004 08:49:17 -0600

I was just reviewing the latest PaceHeadInEntry document and have a
question. Assume that an application was given an entry containing a head,
how does the application determine the source feed URL in order to obtain
more entries from the original feed or to subscribe to it?

Given the example in PaceHeadInEntry, the link in the head within the
entry points to the HTML page. I assume this HTML page would need to
be loaded and then the head would be searched for links (autodiscovery
procedure). The links would then point to the feed where the entry 
originated.

One concern I have is that according to the autodiscovery spec, the head
may have multiple links - there is no way to know which feed contains the
original entry.

Any thoughts on having a mechanism to indicate directly where the
feed was obtained from?  A few thoughts are:

- If an entry contains a head, then it *must* contain an atom:origin (or 
some
other similar construct) to indicate the original source of the entry. I 
realize the
atom:origin would need some re-work for this.

- The head within the entry could contain a link that indicates where 
the source
feed was obtained from such as:
<entry>
    <head>
        <link rel="origin" type="application/atom+xml" 
href="http://example.org/feed.xml />
            ...
    </head>
    ...
</entry>

Brett Lindsley, Motorola Labs