Re: Atom Notification Protocol Published
In article <[EMAIL PROTECTED]>, James Snell <[EMAIL PROTECTED]> wrote: > 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. Super, thanks. That's quite helpful. It even has a nice XMPP example. :-) Peter
Re: Atom Notification Protocol Published
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. On Wed, 22 Dec 2004 16:51:43 -0700, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]>, > Peter Saint-Andre <[EMAIL PROTECTED]> > wrote: > > > In article > > <[EMAIL PROTECTED]>, > > "Bob Wyman" <[EMAIL PROTECTED]> wrote: > > > > > 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. > > > > 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. > > 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 > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Atom Notification Protocol Published
In article <[EMAIL PROTECTED]>, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > In article > <[EMAIL PROTECTED]>, > "Bob Wyman" <[EMAIL PROTECTED]> wrote: > > > 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. > > 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. 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
Re: Atom Notification Protocol Published
On 22/12/04 11:44 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > Eric Scheid wrote: >> Looking at the list of elements one would find in a 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. 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. Are you suggesting that before an entry can be authored, a feed must first be established into which it would then be placed? e.
RE: Atom Notification Protocol Published
Eric Scheid wrote: > Looking at the list of elements one would find in a 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
Re: Atom Notification Protocol Published
On 18/12/04 5:42 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > 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. >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. has similar rules. Looking at the list of elements one would find in a 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.
Re: Atom Notification Protocol Published
In article <[EMAIL PROTECTED]>, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > 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. 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
Re: Atom Notification Protocol Published
In article <[EMAIL PROTECTED]>, James Snell <[EMAIL PROTECTED]> wrote: > On Sat, 18 Dec 2004 02:34:18 -0500, Bob Wyman > <[EMAIL PROTECTED]> wrote: > > 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. > > 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 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
Re: Atom Notification Protocol Published
On Sat, 18 Dec 2004 02:34:18 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote: > 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.) You're absolutely correct of course. > 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. > 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 > bob wyman > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Atom Notification Protocol Published
Requiring atom:head in entries posted without an enclosing feed is fine. I'll go ahead and make that change. On Sat, 18 Dec 2004 02:42:34 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote: > 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 > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
RE: Atom Notification Protocol Published
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
RE: Atom Notification Protocol Published
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
Re: Atom Notification Protocol Published
On Fri, 17 Dec 2004 14:44:38 -0700, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]>, > James Snell <[EMAIL PROTECTED]> wrote: > > > (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. > > 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: > 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. >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? > 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. > 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 > 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. > Peter > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Atom Notification Protocol Published
In article <[EMAIL PROTECTED]>, James Snell <[EMAIL PROTECTED]> wrote: > (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. 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
Atom Notification Protocol Published
(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 PROTECTED]
