Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread James Snell

 I have heard interesting arguments It's all about the Entries, stupid!
 that made the opposite assessment: namely that the entries are what is
 important, and that what feed an Entry is part of, is a accident of
 The idea there is that Entries are the stand alone entities. They can
 be made to be part of any feed whatsoever. A feed in this
 is a little like a search engine result listing where the pages they
 to are like entries (notice that search engine results pages are just a
 type of web page too). Which feed your entry appears in will depend very
 much on the type of query the user of the search engine made.

OK, I can buy that, as long as that is indeed how things are supposed
to be defined.  Note, however, that the Atom syntax spec focuses on
feeds as resources and that entries just happen to be contained in
feeds. e.g. from Section 1: Atom is an XML-based document format
which describes lists of related information known as feeds.  Feeds
are composed of a number of items, known as entries, each with an
extensible set of attached metadata.  If the assertion that the
entries are the standalone entities is correct, then the text in the
spec needs to be changed to reflect that assertion.

Granting the assumption that the entries are the standalone entities
and feeds are merely just a convenient container for entries, the
identification of containing parent-feed becomes less important.  The
need to identify where the entity came from, however, obviously still
remains.. although not necessarily as a core requirement.

Back to the original point about HeadInEntry:  HeadInEntry is not
required to achieve the origin/container identification, regardless of
whether or not origin/container identification should be part of the
core.  If there are no other reasons why HeadInEntry should remain in
the core, then by all means, rip that sucker out of there. 
PaceAggregationInSeparateSpec by no means locks it in place.

 Of course if an entry has a tag such as origin (which used to be on
 table) then the entry it points to would be part of the metadata of the
 entry and so be a legitimate way of creating special selection of
 Henry Story

- James Snell

Re: PaceProfile - new

2005-02-04 Thread James Snell

Absolutely, there would be a core default profile defined in the Atom
syntax spec.  @profiles=core syndication @profiles=core blog, etc.

On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
 On Feb 4, 2005, at 3:13 PM, James M Snell wrote:
   If a profile is indicated that the UA does not understand, the UA
  could safely ignore the profile and just work off the minimally
  required core metadata elements.
 Ah, that's the rub; I'm trying to say that that set of 'core' elements
 is, in and of itself, a profile.
 Mark Nottingham

- James Snell

Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-03 Thread James Snell

I will start working on the template this week and will get something
posted by the weekend.

On Thu, 3 Feb 2005 11:46:14 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
 On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
  James Snell wrote:
  I'm just thinking ahead a bit on this, but I am wondering if it would
  be possible for those of us interested in proposing non-core
  extensions to Atom to use the Wiki as the forum for sharing proposals
  for extensions once the core syntax has been finalized?
 Yep, good idea. I can see a few in the intray: ipaddress/host (for
 anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension
 is in the process of being revised, and an Atom-compatible syntax is
 planned; Yahoo's media object extension.
 A Wiki template would be nice - have you started writing anything up yet, 

- James Snell

Re: PaceCollection

2005-02-03 Thread James Snell

On Thu, 3 Feb 2005 09:12:04 -0700, Antone Roundy [EMAIL PROTECTED] wrote:
 On Wednesday, February 2, 2005, at 11:55  PM, James Snell wrote:
  In any case, we're talking about something as simple as the name of a
  single element.  I just don't see any real technical value in changing
  it's name.  It doesn't make processing any easier.  It doesn't change
  any of the functional semantics.  It doesn't address any critical bugs
  in the design.  It just doesn't do anything.
 Allow me to exaggerate.  Had we been using the following names, there
 would obviously be a point in changing them:

You wouldn't need to change them if guacamole had a well-known,
well-understood meaning in relation to what the XML syntax was trying
to accomplish. The term feed has a well-known, well-understood

 blueberryThis is my blog/blueberry
 blueberryJohhny learns to read/blueberry
 blueberryI resolve to blog/blueberry
 Is collection more descriptive than feed of what we're using it
 for?  Would it make for quicker absorbtion of the concept by people not
 already familiar with the term feed?  Would it confuse those already
 familiar with the term feed?

I say yes to all of these.

 My only objection to collection is that it has two more syllables
 than feed.

- James Snell

Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread James Snell

This is excellent to see.  I'm glad to see that you were not afraid to
break the syntax rules to get things started. :-)  The format looks

On Thu, 3 Feb 2005 21:50:51 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
 At, we've started generating CAP over Atom files. By this I
 mean we're publishing using Atom files to encapsulate a stream of message
 which are encoded using the CAP (Common Alerting Protocol) format. See:
 Because CAP is an XML format, we're using atom:content elements with
 type=text/xml. In order to ensure that there is something for aggregators
 to display if they don't understand CAP, we're generating atom:summary
 elements that contain a textual summary of the CAP message which is in the
 atom:content. My hope is that aggregator developers will commonly implement
 a pattern of displaying the atom:summary rather then the atom:content in
 cases where they don't understand the XML type of the content element. 
 I would appreciate any review comments that you might be able to make on our
 use of Atom in this application. 
 For a sample Atom feed containing CAP messages which describe recent
 earthquakes, please see: 
 A sample atom:entry extracted from this Atom Feed is below: 
 title![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA
 2005-02-04T02:00:43.100Z ]]/title 
 link rel='alternate' type='text/html'
 summaryAn earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude
 1.6 event has been located in NORTHERN CALIFORNIA. (This is a
 computer-generated message and should not be considered authoritative.)
 content type='text/xml' 
 alert xmlns=; 
   sender[EMAIL PROTECTED]/sender 
 senderNamePubsub Earthquake Service/senderName 
 headlineEarthquake: M 1.6 (D) NORTHERN CALIFORNIA
 descriptionAn earthquake occurred at 2005-02-04T02:00:43.100Z. The
 magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a
 computer-generated message and should not be considered authoritative.)

 parameterMagnitude=1.6 MD/parameter 
 parameterDepth=2 km/parameter 
   areaDesc2 km depth at latitude 38.8168, longitude -122.7915 at
 location: NORTHERN CALIFORNIA/areaDesc 
   circle38.8168,-122.7915 0/circle 
 Note: I am aware of a few issues with our current use of Atom: 
 1.   We often issue files that contain more than one entry with the same
 atom:id. For instance, you might have a message which is followed in the
 file by an update concerning the same incident or a Cancel message for
 the event. I know this is a violation of the specification. We will
 eventually stop doing this Please bear with us. 
 2.   We currently don't provide an atom:link element with
 rel=alternate when we insert a CAP Cancel message into the feed. This
 is, of course, because we have no page to point to for a deleted or
 cancelled event. In the future, we'll consider having all such Cancel
 messages point to a common static help page which explains a variety of
 reasons why a message may have been deleted. 
 3.   If you view the Atom feed in a web browser, the result may not be
 terribly pleasing We're still working on the style sheet.  Please pay
 attention only to the source of the feed (i.e. do View Source). 
 This service compliments the Earthquake service that I recently mentioned on
 this list. We will be publishing both raw Earthquake messages/feeds as well
 as CAP messages/feed in the future. These two formats are targeted at
 different audiences. 
 Your comments and/or suggestions would be appreciated. 
 bob wyman 

- James Snell

Re: On organization and abstraction

2005-02-03 Thread James Snell

On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
 Tim Bray wrote:
  So I think I'm +1 on PaceAggregationDocument.  (And I think
  if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
 PaceAggregationDocument does not seem to me to add much benefit for
 all the costs that it entails. I'm particularly concerned that adding a new
 type of root document aggregation is likely to add enough to the
 complexity of Atom that only a subset of developers will actually get around
 to supporting this third type of document -- a type which doesn't exist in
 the simple RSS aggregators that exist today.

+1 to this -1.  The aggregation element is not a necessary part of the
core and adds complexity without adding *significant* benefit to the

 2. As mentioned before, the introduction of a new level of
 abstraction (i.e. aggregation) is likely to scare off a good proportion of
 the aggregator developers. Current aggregators don't have the concept of
 aggregation in them. Thus, new design and new architecture will be
 required to address this Pace. On the other hand, staying with HeadInEntry
 is much more gentle on the existing systems and thus much more likely to be
 useful in the field.

This is precisely why I don't think this belongs in the core.  For
those who need this type of functionality, the opportunity exists for
them to create a separate Internet-Draft that describes how to
aggregate feeds -- without adding complexity to the core syntax by
introducing elements that the vast majority of users will *likely*
never use.  (I obviously base this assumption on the reasoning that
most Atom users will use it as a drop in replacement for RSS).

 3. Since there will be at least some subset of aggregators that
 won't understand the aggregation thing, it is likely that we'll have a
 chicken and egg problem. No one will produce aggregation documents since
 not everyone supports them. Thus, no one will support them since no one
 generates them. 

Well, I wouldn't go this far.  There is obviously a requirement for it
for some folks and those folks are likely to make good use of it. 
What I would rather see the WG do is take a minimalist approach with
this.  Right now, I see aggregated feeds falling into that limited 20%
of use cases that could be done, but aren't necessarily critical to be
done.  Aggregation could be defined as an extension to Atom, and
later, based on an analysis of its implementation over time, can be
merged into the Atom core if deemed appropriate.  Merging it into the
core now does not guarantee that its adoption and use will be any
greater than if it were done as an extension.

 4. Massive changes need to be made to the specification when we
 don't have a great deal of time left before we're supposed to be doing a
 Last Call. This is dangerous.

+1. Big +1.  

 -1. I really don't see any compelling benefit in exchange for the
 tremendous risk and cost of accepting PaceAggregationDocument and dropping
 HeadInEntry. Let's avoid adding to the levels of abstraction here and keep
 it simple. We should have feeds and entries -- nothing else.

One point, HeadInEntry solves the problem of having a standalone Atom
Entry document be able to reference a feed of which it is a part. 
Unless I'm misreading something, if PaceAggregationDocument gets rid
of the ability to put Head elements in the entry, don't we lose this
capability?  (this is something that is important, for instance, in my
Atom Notification Protocol proposal)

  I would like Atom to be more like Visual Basic and less like Lisp.
 As an ex-Visual Basic Product Manager, I think this would be a good
 idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to
 reader: Visual Basic .NET is .NOT Visual Basic...

Aargh! VB... it burns!  (sorry, temporary flashback to past hell. 
Sorry Bob, VB was an excellent product, I just was forced to be
witness to some extremely bad uses of it.  Nightmares, I tell you,

 bob wyman
- James Snell

Re: PaceRemoveInfoAndHost

2005-02-03 Thread James Snell


On Thu, 3 Feb 2005 20:24:06 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
 Welcome to the club :)
 On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
  Remove atom:info and atom:host from The Atom Syndication Format.
  Remove atom:host
  No one seems to like the atom:host element. It doesn't do what its
  original proponents wanted and many of its detractors still oppose it.
  Design by committee at its worst.
  Remove atom:info
  Back when we were arguing about IETF vs. W3C, mnot said in the IETF,
  it's easier to shut down a solo raving loony. In the threads on
  atom:info, it seems I am playing the role of solo raving loony. So,
  let's have the process take over.
  Robert Sayre
 Mark Nottingham

- James Snell

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread James Snell

 Potential solutions that occur to me:
 1. Ignore the problem
 2. PaceEntriesElement could handle this
 3. PaceFeedRecursive could handle this
 4. PaceAtomHeadInEntry could handle this
 5. PaceAggregationDocument could handle this
 I honestly can't say which I prefer.  Would anyone like to try to put
 together examples of the solution in #2 through #5 so that we can
 consider the alternatives?

6. Handle the problem in a non-core extension.  

The core Atom syntax does not have to deal with all these cases as
long as it does not interfere with someones ability to deal with cases
later on. Get version one out the door.  Get folks to start
implementing it.  Start writing up extensions.  Get folks to implement
those extensions.  Figure out which extensions are Really Useful.  Add
those Really Useful Extensions to the core later.

- James Snell

New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell

Figured I would formalize what I've been evangelizing the past couple of days.

== Abstract ==

Defer the definition of solutions for aggregated feeds to a separate
Internet-Draft that is not a part of the Atom core syntax

== Status ==

Proposed (by [JamesSnell])

== Rationale ==

Aggregated feeds, while important, are currently not supported by the
existing RSS mechanisms and are relatively rare in comparison to their
single feed cousins.  Given the guidelines for proposals set forth in
this Wiki, this alone would justify moving the aggregation stuff off
to a separate document, at least for now.

* The 80/20 rule: If a feature will only be used by a small number of
people, and will create extra work and headaches for everyone else, it
probably doesn't belong in the core spec.
* Pick stuff that's already been proven to work and be interoperable,
and writing it down in a clean, clear way
* Keep it simple: The simplest thing that can possibly work tends to
be preferred over more complex solutions.

I absolutely acknowledge that there are a subset of folks for whom
aggregated feeds are very important.  But this is a subset.  Let that
subset document their ideas in a separate Internet-Draft; let them
implement those ideas and build momentum for them; then let us later
come back later and discuss the merits of merging those ideas into the

== Proposal ==

(see abstract)

== Impacts ==

Defers PageAggregationDocument and PageFeedRecursive to a separate

* Lets Atom 1.0 get out the door faster.  
* Lets folks gain valuable implementation experience before committing
to major changes to the Atom core spec to support what is currently an
edge case
* Keeps the Atom core simple

== Notes ==

- James Snell

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell

On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
 Antone Roundy wrote:
  leaving things as they are
  and deferring deciding how to handle aggregation would irreversibly
  enshrine HeadInEntry into the format, which all of the current
  organizational proposals are trying to replace.
 That's right. Besides, HeadInEntry is trivial to do as an extension, so
 there's no reason to leave it in.

I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs.  That
mechanism does not have to be atom:head, but it does need to be part
of the core.

 Robert Sayre

- James Snell

Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-02 Thread James Snell

On Wed, 02 Feb 2005 15:18:46 -0800, Tim Bray [EMAIL PROTECTED] wrote:
 On Feb 2, 2005, at 11:58 AM, James Snell wrote:
  I'm just thinking ahead a bit on this, but I am wondering if it would
  be possible for those of us interested in proposing non-core
  extensions to Atom to use the Wiki as the forum for sharing proposals
  for extensions once the core syntax has been finalized?
 Sounds like a good idea to me.  Mind you, it's Sam's wiki :) -Tim

Heh, good point ;-) ... Sam? Ultimately it is your call. 

- James Snell

Re: PaceCollection

2005-02-02 Thread James Snell

-1. A name change of the top level element accomplishes nothing. 

On Thu, 03 Feb 2005 16:55:35 +1100, Eric Scheid
 == Abstract ==
 Rename the top level element name for the atom document format which holds a
 collection of entries, to better communicate it's collection nature, and
 more easily allow non-feed collections.
 == Status ==
 == Related and Conflicting Proposals ==
 == Rationale ==
 The term feed has generally held the special meaning of the collection of
 entries which were recently published, and into which new entries will also
 be published, with older entries being removed sliding window style (or
 something like that)
 Which has meant it has been a pain to refer to Atom Feed Documents which
 don't obey that semantic, instead being (say) an archive of all posts within
 a specific period of time (eg. June 2004). A given resource (eg. the June
 2004 archive) could be said to be both an Atom Feed document, but also
 ''not'' be a feed. Confusing.
 Atom Feed Documents are properly collections, of which feeds are just one
 semantic. Other semantics for Atom Collection Documents include archives,
 directory, comments, trackbacks, pings, parts, versions, and so
 == Proposal ==
 Rename the top level element for Atom Feed Documents to atom:collection,
 and rename Atom Feed Document to Atom Collection Document.
 no spec text -- this is really just a job for the editor, i hope.
 *s/Atom Feed Document/Atom Collection Document/
 == Impacts ==
 none. it's just a name change.
 == Notes ==

- James Snell

Re: Call for final Paces for consideration: deadline imminent

2005-02-02 Thread James Snell

+1 Eric.  sub-feeds can easily be nested by reference using the
existing link mechanism as opposed to nesting by containment.  Overall
this would be a cleaner model and would be easier on bandwidth by
allowing nested feeds to be broken up over several documents rather
than stuffed all into a single document.

On Thu, 03 Feb 2005 16:21:42 +1100, Eric Scheid
 On 3/2/05 4:01 PM, Robert Sayre [EMAIL PROTECTED] wrote:
  4.) Atom sucks at blogs with comments or trackbacks
  5.) Atom sucks at anything with a representation of its own and
 collection membership
 link href=... type=application/atom+xml rel=comments /
 link href=... type=application/atom+xml rel=trackbacks /
 link href=... type=application/atom+xml rel=parts /

- James Snell

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

2005-02-02 Thread James Snell

Comments below..

On Thu, 03 Feb 2005 17:27:33 +1100, Eric Scheid
 On 3/2/05 5:09 PM, James Snell [EMAIL PROTECTED] wrote:
  What is the model for archiving with Atom?  One or more distinct Atom
  feeds that each contain a collection of old entries? If so, what we
  need then is a just container for feeds.  One that encapsulates by
  reference rather than by direct containment.  Perhaps a top level
  document like the following would be sufficient?)
  !-- archive-index.xml --
   archive href=2001/archive-feed.atom
  titleArchive Title/title
 Your example format doesn't include dates for when the referenced items were
 last updated, nor unique IDs for disambiguation, etc etc ... why not
 titleThe 2001 Archive of My Big Fat Fenugreek Blog/title
 titleJanuary 2001 Archive/title
 summary208 posts over 19 days/summary
 link href=... type=application/atom+xml rel=alternate /
 titleFebruary 2001 Archive/title
 summary311 posts over 23 days/summary
 link href=... type=application/atom+xml rel=alternate /

This is better.  I guess I just hadn't grok'd the idea of using
entries to reference feeds, but now that I see the angle brackets I
get it.  (perhaps I just need some coffee).  As long as it is legal
for an alternate link to reference a feed document, this works
perfectly.   I like the containment-by-reference approach.  Best of
all, this could be accomplished without requiring any changes to the
existing core..

  Just a single new @rel value for the link element in an atom feed head
  can then be created that points to this archive index document.
link rel=archive type=application/atom+xml href=... /
 this is exactly what I had in mind with PaceCollections.

Well, from your Pace: Atom Feed Documents are properly collections,
of which feeds are just one semantic. Other semantics for Atom
Collection Documents include archives, directory, comments,
trackbacks, pings, parts, versions, and so on.

If we define a feed as a collection of entries, archives,
directories, comments, trackbacks, pings, parts, versions, and so
forth, then the name feed is descriptive enough to get the point
across.  I'm not sure I follow the connection between PaceCollection
and the archive @rel attribute.  Did I miss something?


- James Snell

ServiceElement and other matters

2005-02-02 Thread James Snell

Ok, so I'm an Atom end-user who has been monitoring the fringes of the
effort to define the spec and am now spending some time going through
the near-finished product to see what issues I can spot.  That said,
likely just as most potential atom-end-users, I am not aware of the
full history of the various conversations and debates that may have
gone on previously regarding any single part of the spec.

In reading through the spec, several things stick out:

1. Service Construct.  While I understand what the Service Construct
is trying to do, and I agree that it is needed, it does not seem to me
to be something that rightfully belongs in the core Atom syntax. 
Rather, it seems better placed as an Atom syntax extension introduced
by the Protocol specification.  The rationale is simple: The Protocol
spec should deal with all service related issues, including any
extensions to the core that are necessary to communicate protocol
related information.  If I were putting this stuff together, I would
move the Service Construct to the protocol spec.

2. Entry id's.  Ok, so they are supposed to be universally unique. 
That's all good and fine.  But what if... hypothetically... my Atom
reader gets two copies of the same Entry with different metadata. 
They are the same entry because they have the same id.  One of the
versions of the entry differs from the other in that some feed
aggregator somewhere added some additional pieces of metadata to it. 
Do I: a) silently reject one of the entries, b) merge the metadata of
the two entry instances into a single logical entry, c) throw up on
the user.  Case in point where this might be an issue: Suppose an
entry in a feed that references a standalone entry document for the
same entry.

!-- feed.xml --
 titleMy Entry/title
 link rel=alternate href=entry.xml type=application/atom+xml /

!-- entry.xml --
  contentHello There/content

Is this legal?  If it is, how should clients handle this situation? 
Do the two separate entry elements merge to form a single logical
entry or does one replace the other?

3. I know this has been discussed elsewhere because I've seen a couple
of recent posts about it.  The version attribute just seems hokey.  It
doesn't add any value beyond what the XML namespace already provides. 
 Just one guys opinion. Take it for what it's worth.

4. What the heck is an introspection document?  I actually do know
what it is, but the current doc doesn't say.  This needs to be fleshed
out obviously.  Of course, if #1 above is addressed, this ceases to be
a problem. :-)

This is what I came up with on my first full read through of the -05
draft.  Maybe more later.

- James Snell

Atom Notification Protocol Update

2005-01-31 Thread James Snell
I have just submitted an update to the Atom Notification Protocol
draft that will hopefully be published in a day or so.  I have
attached the draft for review.

Summary of changes:
  * Rather than POSTing atom:feed elements to indicate an updated
feed, atom:head elements are POSTed.
  * Eliminated the NotificationURI location mechanisms. 
NotificationURI's will be located in some application specific manner.
 It didn't make sense at this point in time to define a common
  * Head-In-Entry has been marked as a SHOULD
  * Expanded treatment of HTTP response codes and HTTP methods

To reiterate the prior discussion that happened on this, I am not
intending this as a competitor to Atom-XMPP.  I think both have their
place and both contribute to the General Good.  I would appreciate
folks giving this a look over and offering any comments you may have.

- James Snell

Network Working Group   J. Snell
Internet-Draft  January 31, 2005
Expires: August 1, 2005

 The Atom Notification Protocol

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   This memo presents a protocol for posting notifications of new or
   updated content using a combination of the Atom Syndication Format
   and HTTP POSTs.

SnellExpires August 1, 2005 [Page 1]
Internet-Draft   The Atom Notification Protocol January 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 1.1   Notational Conventions . . . . . . . . . . . . . . . . . .  3
 1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Atom Notification Protocol Model . . . . . . . . . . . . .  3
   3.  Functional Specification . . . . . . . . . . . . . . . . . . .  3
 3.1   NotificationURI  . . . . . . . . . . . . . . . . . . . . .  3
   3.1.1   Locating the NotificationURI . . . . . . . . . . . . .  4
   3.1.2   Request  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1.3   Response . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
   Intellectual Property and Copyright Statements . . . . . . . .  7

SnellExpires August 1, 2005 [Page 2]
Internet-Draft   The Atom Notification Protocol January 2005

1.  Introduction

   The Atom Notification Protocol is an application-level protocol for
   posting notification of new or updated content using HTTP and the
   Atom Syndication Format.

1.1  Notational Conventions

   document are to be interpreted as described in [1].

1.2  Terminology

   Atom Entry: An Atom Entry is a fragment of a full Atom feed.  In this
   case, the fragment is a single 'entry' element and all its child
   elements.  Each Atom Entry describes a single Web resource, providing
   metadata and optionally a textual representation of that resource.

   Atom Head: atom:head elements are used within the Atom Syndication
   Format as children of both the atom:feed and atom:entry elements to
   provide information descriptive of the feed.

   NotificationURI: A HTTP URI that is used to receive notifications
   about new or updated Atom entries.

2.  The Atom Notification Protocol Model

   The Atom Notification Protocol has been designed to complement the
   Atom Publishing Protocol

Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom

2005-01-17 Thread James Snell

What I'm wondering here is whether or not a retracted / or retracts
/ element could be used for this purpose.  The retracted / element
would be used within an entry to indicate that the entry has been
retracted.  The retracts / element would be used within a second
entry to identify it as a retraction for some preceding entry.  For

  retrated by=urn:my-entry-22005-01-07T12:00:00-8:00/retracted


The retraction elements can be defined externally to the Atom core.

On Sat, 15 Jan 2005 18:00:39 +, Eric Brunner-Williams in Portland
Maine [EMAIL PROTECTED] wrote:
 um... cancel messages?
 look, errors or state change repudiation is latent in all reported state.
 why un-write when you can later-write?

- James Snell

Re: Atom Notification Protocol Published

2004-12-20 Thread James Snell

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

Potential Issue: Section 4.2.2 atom:link

2004-12-07 Thread James Snell

Reading through the current draft I note that in section 4.2.2
referring to the atom:link element, there is the following

   atom:head elements MUST NOT contain more than one atom:link element
   with a rel attribute value of alternate that has the same type
   attribute value.

My question is: what if I want to offer two alternates of the same
type that use different languages? e.g.

   atom:link rel=alternate type=text/html hreflang=en href=... /
   atom:link rel=alternate type=text/html hreflang=fr href=... /

I'm not sure if this is an unreasonable thing to do or not but it did
strike me as being potentially problematic.

- James Snell