Subject: PaceEntryMediatype

From: James M Snell <[email-masked]>
Date: Wed, 29 Nov 2006 08:16:37 -0800

http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...

Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.

== Status ==

Proposed

== Rationale ==

The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.  We have
an opportunity to fix this problem now.

== Proposal ==

Add to Section 6.1

{{{
Atom Entry Documents are identified with the "application/atomentry+xml"
media type (See section 15).
}}}

Renumber existing section 15.3 to 15.4

Insert..

{{{
15.3 Content-type registration for 'application/atomentry+xml'

   MIME media type name:  application
   MIME subtype name:  atomentry+xml
   Mandatory parameters:  None.
   Optional parameters:
      "charset":  This parameter has semantics identical to the charset
         parameter of the "application/xml" media type as specified in
         [RFC3023].
   Encoding considerations:  Identical to those of "application/xml" as
      described in [RFC3023], Section 3.2.
   Security considerations:  As defined in this specification.
      In addition, as this media type uses the "+xml" convention, it
      shares the same security considerations as described in [RFC3023],
      Section 10.
   Interoperability considerations:  RFC 4287 registers the
      application/atom+xml Content-Type for both Atom Feed and Entry
      Documents.  For Atom Entry Documents, the use of the
      application/atom+xml type should be avoided.
   Published specification:  This specification.
   Applications that use this media type:  No known applications
      currently use this media type.

   Additional information:

   Magic number(s):  As specified for "application/xml" in [RFC3023],
      Section 3.2.
   File extension:  .atomentry
   Fragment identifiers:  As specified for "application/xml" in
      [RFC3023], Section 5.
   Base URI:  As specified in [RFC3023], Section 6.
   Macintosh File Type code:  TEXT
   Person and email address to contact for further information:
     This specification's author(s)
   Intended usage:  COMMON
   Author/Change controller:  IESG
}}}

== Impacts ==

== Notes ==

----

CategoryProposals

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 29 Nov 2006 17:52:05 +0100

> Deprecate the use of application/atom+xml for Entry Documents.

That is a *very* good idea!!

+1

Jan

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 29 Nov 2006 12:33:53 -0500

-1

- there's nothing special about an entry document
- AFAICT (because they're not referenced from the pace), the problems
referred to have other causes.  I prefer we fix those instead.

Mark.

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 29 Nov 2006 10:10:20 -0800

Hi Mark,

would you suggest to put service and categories into application/atom+xml as well?

Hmm, ah, I think I see what you mean: When a peer declares it understands application/atom+xml the understanding of <entry/> is mandatory anyhow. Despite the additional inspection into the documents root element feed and entry belong into the same family you cannot have one without the other therefore the media type should not be split.

Is that what you think?

Jan

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Nov 2006 10:22:40 -0800

One such problem occurs in atom:link and atom:content elements.
Specifically:

  <atom:link type="application/atom+xml" href="a.xml" />
  <atom:content type="application/atom+xml" src="b.xml" />

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Nov 2006 10:40:38 -0800

I'm fine either way. Wouldn't take that long for me to write up a draft.

- James

Tim Bray wrote:
> On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
> 
> Irrespective of the merits of the new media type, the APP spec seems
> like the wrong place to define it.  Since nobody wants to obsolete 4287,
> why not a short clean standalone I-D?  -Tim
> 
>

---

From: Henry Story <[email-masked]>
Date: Wed, 29 Nov 2006 10:39:43 -0800

There are all kinds of other things you don't know: like what's  
inside the document, if the server is up, what the title is, ... What  
interoperability problem is solved by having a new mime type? And  
would that not be solvable by

<atom:link rel="entry" type="application/atom+xml" href="a.xml" />

Not that I really care that much.

Henry

---

From: Tim Bray <[email-masked]>
Date: Wed, 29 Nov 2006 10:36:13 -0800

Irrespective of the merits of the new media type, the APP spec seems  
like the wrong place to define it.  Since nobody wants to obsolete  
4287, why not a short clean standalone I-D?  -Tim

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 29 Nov 2006 13:56:04 -0500

> would you suggest to put service and categories into application/atom+xml as well?

I haven't paid much attention to those, but AFAICT they have different
processing models (e.g. extensibility rules) and so IMO, comprise
different document formats.  Separate media types are fine.

> Hmm, ah, I think I see what you mean: When a peer declares it understands application/atom+xml the understanding of <entry/> is mandatory anyhow. Despite the additional inspection into the document…

Yes, but more than that.  An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata.  It's processing is a subset of feed processing.  If the
processing or content model of entry is extended, it applies to both
feed documents and entry documents.

And +1 to what Henry just said in response to James.  It's also not a
huge deal to me.  But I've just raised the rel="feed" inference issue
with the WHAT WG, so we'll see how that goes; if resolved to my
liking, then there's one less reason for a new media type.

Mark.

---

From: Bill de hOra <[email-masked]>
Date: Wed, 29 Nov 2006 18:56:14 +0000

> Create a new media type for Atom Entry Documents: application/atomentry+xml

+0

cheers
Bill

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 29 Nov 2006 20:03:22 +0100

> Deprecate the use of application/atom+xml for Entry Documents.

I'd largely prefer augmenting the existing media type with a 'type' parameter:
 - application/atom+xml => either feed or entry (as defined in RFC4287)
 - application/atom+xml;type=feed => feed
 - application/atom+xml;type=entry => entry

> {{{
> Atom Entry Documents are identified with the
>  "application/atomentry+xml" media type (See section 15).
> }}}

How about defining a "tree" similar to the */vnd.* one?
 - application/atom+xml => feed or entry document
 - application/atom.categories+xml => category document
 - application/atom.service+xml => service document
...and of course, if this proposal is finally accepted:
 - application/atom.entry+xml => entry document

As for Tim's concerns, I'd also prefer having it done outside the APP.

Also, the APP draft would need to be updated to remove the "entry"
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Thu, 30 Nov 2006 09:52:42 +1100

> <atom:link rel="entry" type="application/atom+xml" href="a.xml" />

not if you want to do this:

<atom:link rel="something-else" type="application/atom+xml" href="a.xml" />

where 'something-else' might be 'comments' or 'history' or 'unexpurgated' or
'disemvowelled' or many other as yet unknown opaque-strings, some of which
would be used when linking to feed documents, some when linking to entry
documents.

e.

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Nov 2006 22:44:48 -0800

Mark Baker wrote:
> [snip]

Hmm.. I understand what you're saying but I don't think I agree.  In the
APP implementations I've put together, Feed and Entry documents
generally serve two entirely different purposes and are usually intended
for two entirely different audiences.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 29 Nov 2006 22:57:38 -0800

John Panzer wrote:
> [snip]
 > +1 to doing this outside of APP (but concerned about deprecating...)
> [snip]

An I-D / RFC can update another RFC without deprecating the entire
thing.  In this case the hypothetical new document would deprecate only
the use of the application/atom+xml media type for Atom Entry Documents.
 The rest of RFC 4287 would be unaffected.

- James

---

From: John Panzer <[email-masked]>
Date: Wed, 29 Nov 2006 20:32:46 -0800

So this needs a decision tree:

+1 to having some way to modify type= (either new media type, or 
appending ";type=entry", +0 to either)
   +1 to application/atom.entry+xml if new media type is used
+1 to doing this outside of APP (but concerned about deprecating...)

My use case:  A web page that contains both a blog entry, and the 
comments for that entry.  I want to be able to autodiscover alternates 
for both, using separate documents, for example:

<link rel="alternate" type="application/atom.entry+xml" href="entry.xml" 
title="This entry"/>
<link rel="alternate feed" type="application/atom+xml" 
href="comments.xml" title="This entry's comments"/>

-John

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 30 Nov 2006 02:09:00 -0500

On 11/30/06, James M Snell <[email-masked]> wrote:
> An I-D / RFC can update another RFC

I think John should edit.

-- 

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 30 Nov 2006 08:43:39 +0100

* Mark Baker <[email-masked]> [2006-11-29 20:10]:
> An entry document is, AFAICT, little more than shorthand for
> a feed with one entry, minus the feed-specific metadata. It's
> processing is a subset of feed processing. If the processing or
> content model of entry is extended, it applies to both feed
> documents and entry documents.

I disagree. There’s not much of a point in subscribing to an
entry document, and APP servers will not accept POSTing feeds in
place of entries.

[Note: subscribing to an entry document is actually somewhat
useful in one sense and might become customary in the future,
eg. to track changes to a document. However, that’s still an
entirely different use case from subscribing to feed.]

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 30 Nov 2006 08:52:31 +0100

+1

> - application/atom+xml;type=entry => entry

-0

+1

I like this very much; it would put some order in the
proliferation of Atom-related MIME types.

+0

> Also, the APP draft would need to be updated to remove the
> "entry" special value for app:accept, as it would be equivalent
> to the new or revised media type
> (app:accept=application/atom+xml;type=entry or

+1

Unification is good.

Regards,

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 30 Nov 2006 08:56:36 +0100

Hi James,

>> has repeatedly come up as a problem on more than one occasion.

I took that to refer to the problem I saw (doing an additional check  
on the root element) but Mark's comment
made me realize that this is to small of a problem to warrant the  
media type separation of something so
tied together, IMO.

Are there other problems you had in mind when writing the Pace?

Thanks,

Jan

P.S. Actually, I think that Atom is a real good example to  
demonstrate that media types mean more than single  XML
document types.

>> We have

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 30 Nov 2006 08:12:08 +0000

Jan Algermissen wrote:
> I took that to refer to the problem I saw (doing an additional check on
> the root element) but Mark's comment
> made me realize that this is to small of a problem to warrant the media
> type separation of something so
> tied together, IMO.
> 

One example.
UA POSTs content to a collection. The media type chosen by the client is
application/atom+xml and is accepted by the collection.

Now say the client posted a feed containing several entries. What should
the server decide to do? It could reject the request altogether but on
what ground? How to inform properly the UA? If we had a specific media
type (or at least a ;type=entry) for Atom entries you would avoid such
issue or be able to return a 415 error code.

More generally feed and entry documents are semantically distinct enough
that they should be distinguished in their media-type one way or the
other. I have hard times understanding why it hasn't been done so in the
first place. Better be safe than sorry. Well it seems we are sorry :)

It's interesting however because now that APP has reached a point where
it stable enough to be implemented we can see that issues are not the
same for server and client implementors. Considering what happens still
now with HTTP (see for instance the Content-Location discussion over at
the HTTP-WG) I hope the APP WG and the specification editors are taking
great care to limit the possibilities of future conflicts once APP gets
heavily deployed and used.

If things can safely be changed now then let's do it.

- Sylvain

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 30 Nov 2006 09:13:35 +0100

> references to Feed or Entry documents.

And what is the problem with that?

Jan

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 30 Nov 2006 12:03:30 +0100

>> Deprecate the use of application/atom+xml for Entry Documents.

-0.5.

Using a type parameter seems like a more elegant solution -- and 
achieves the same effect.

> - application/atom+xml;type=entry => entry

+1.

This looks IMHO like a cleaner solution; in particular 
application/atom+xml fits in nicely as special (or rather more generic) 
case of application/atom+xml;type=(feed|entry).

> - application/atom.entry+xml => entry document

-1. I would not go down this road; the trees were designed for a 
different purpose. For (optional) type/profile parameters, however, 
there is precedent.

> As for Tim's concerns, I'd also prefer having it done outside the APP.

+1. A separate "Atom Media Types" RFC would be good.

Andreas Sewe

---

From: Bill de hOra <[email-masked]>
Date: Thu, 30 Nov 2006 11:50:52 +0000

> for two entirely different audiences.

Same here. Feeds are collections; saying that entries are implicit 
collections is something I don't grasp - it's too abstract.

[The only time I've been able to treat feeds and entries uniformly is 
feeding RSS1.0 into a RDF aware system.]

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Thu, 30 Nov 2006 11:56:07 +0000

> entry document, and APP servers will not accept POSTing feeds in

Well, it's kinda undefined - and this is circular - it's undefined 
because feeds and entries share a media-type.

It would be useful to allow collections to accept non-atoms (har har). 
Kyle@google expressed a need for batching, and I could really do with 
this for website/cms publishing. But because error handling semantics 
can be different for batches, it's tricky; some uniformity is lost if 
it's not thought out.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Thu, 30 Nov 2006 08:46:24 -0600

> And what is the problem with that?

Here's one problem: in this and the autodiscovery case, the UA can't  
tell without fetching the remote resource whether it's appropriate to  
display a "subscribe" link.  In fact, even if the remote resource is  
a feed, it may not be appropriate to subscribe to, because it may be  
an archive document rather than the live end of a feed.

Of the options presented, I'd favor adding a type parameter to  
application/atom+xml.  In addition to "feed" and "entry", we may want  
"archive".

---

From: "Judy Piper" <[email-masked]>
Date: Thu, 30 Nov 2006 09:49:44 -0500

Thomas Broyer wrote:
<snip>
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml => either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed => feed
- application/atom+xml;type
> =entry => entry

</snip>

+1

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 30 Nov 2006 10:16:03 -0500

The real problem here AIUI - at least in the context of HTML 5's
inferred rel="feed" bit - is not just entry documents, it's any Atom
document which wouldn't normally be considered a "feed" by a typical
user; something that most people would be interested in subscribing
to.  An example I gave on the whatwg list was an MHTML-like (MIME
multipart) package, but there are many other possible examples of
course; not all RFC 4287 feed documents are "feeds" in this sense.

If HTML 5 (and current practice) doesn't change, but we defer to them
for the specification of autodiscovery, then a new media type would be
one way forward.  But it should be reusable for all non-"feed" (i.e.
from a user POV, as above) Atom documents, not just entry documents;
perhaps application/atom-no-feed+xml.  It's an ugly hack, but it's
better than the alternative of many more specific Atom-related media
types, which atomentry+xml might set a precedent for.

Another way forward, because the rel="feed" inference is triggered not
just by the media type but by the "alternate" relationship keyword, is
to create a non-feed alternate relationship ("alternate-non-feed"?
ick).

I prefer the new relationship to a new media type because it's less
disruptive; it doesn't require futzing around with existing specs and
implementations.

Mark.

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 30 Nov 2006 10:27:13 -0500

Interesting, thanks.  But serving different purposes doesn't
necessitate a new media type.  What's important is how the two types
of documents are interpreted.

How does your processing of an entry document differ from the
processing of a feed containing (only) that same entry?  If processing
the entry is a subset of processing the feed, then you probably don't
need a new media type.

Mark.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 30 Nov 2006 15:32:38 +0000

> the entry is a subset of processing the feed, then you probably don't

Well having two media types also helps at a lower level such as HTTP
(content negotiation for one thing).

- Sylvain

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 30 Nov 2006 16:54:37 +0100

> course; not all RFC 4287 feed documents are "feeds" in this sense.

Yes.

> types, which atomentry+xml might set a precedent for.

-1
This means RSS would need two media types.
This also means an HTML document can be a "feed", or it needs its own
media type.
In an "entry" page in a blog-like scenario, we could find:
   <link rel="feed" href="/feed.atom" type="application/atom+xml;type=feed">
   <link rel="feed" href="/" type="text/html">
which tells you the page "believes" it is an "item" in the linked "feeds".
Then , in /feed.atom:
    <atom:link rel="alternate" href="/" type="text/html" />
and in the "/":
    <link rel="alternate" href="/feed.atom"
type="application/atom+xml;type=feed">

And yes, HTML pages are "subscribable", either using a microformat
(see the W3C's home page, from which the RSS is actually produced
using an XSLT stylesheet), or using user-defined "scrapping" (some
aggregators allow you to subscribe to any web page; they try to infer
the "entries" from the semantical markup –h1, h2, h3, etc.– and you
can customize the mechanism in per-feed basis: this page uses h2, this
one uses h3 with class="article", etc.)

The relation from the "entry" page to the feed or "home page" is the
same (hey, they are alternates!): they are "feeds", whatever their
representation (Atom, RSS, HTML, etc.)
The difference with "container"? a "feed" is known to have a
representation which only exposes a subset of the contained items.

This is the same as:
<link rel="contents" href="/toc.html" type="text/html">
<link rel="contents" href="/toc.opml" type="what's the media type for OPML?">

> disruptive; it doesn't require futzing around with existing specs and

I'd prefer basing autodiscovery on the media types and not at all on
the relationships. A "feed" relationship would only help finding the
"living resource" (similar to rel="current" in the Atom Relationship
Registry) if you're not already "on" it (in which case,
rel="alternate" would be used).

UAs would then obviously continue to support autodiscovery using
"alternate" all-over-the-place, this would just be a lucky
side-effect; and everyone would be happy.

-- 
Thomas Broyer

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 30 Nov 2006 11:27:20 -0500

> (content negotiation for one thing).

True, but if entry documents are more or less aliases for single-entry
feeds, why would anybody need to negotiate for one or the other?  I
suggest that would have to be pretty obscure use case. 8-)

Mark.

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 08:23:01 -0800

Well, it's all XML parsing so in one sense the processing is the same.
The key difference arises in how the various documents are used.  In my
experience, Atom Entry Documents are nearly the exclusive territory of
APP Clients and push notification services (e.g. Atom over XMPP) while
Feeds generally provide for the redistribution and indexing of entries.
 When I parse an entry document, there is no implied feed.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 08:43:29 -0800

The key problem with "application/atom+xml;type=entry" is that at least
one major browser (Firefox 2.0) still treats it as a feed and shows the
"subscribe" link. So while the type parameter is a potentially more
elegant solution, the new media type approach would likely be far less
disruptive.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 08:49:28 -0800

> Are there other problems you had in mind when writing the Pace?

Well, there are the issues that came up with regards to the APP accept
element; the issues regarding whether Atom Feeds can be posted to an APP
collection; the issue in the "collection of collections" use case where
it's not clear if <content type="application/atom+xml" src="foo" />
points to an entry or a feed; I'm sure there are others that I'm not
thinking of right at the moment.  It seems that every couple of months
the issue of the media type duality comes up.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 09:00:39 -0800

> types, which atomentry+xml might set a precedent for.

Blech! :-)

I think it's worthwhile to separate the two distinct issues at play: The
Purpose of the Link and the Type of Resource.

The ambiguity in the media type has come up several times in WG
discussions for more than just autodiscovery.  Every time it comes up
there is some speculation about whether adding a type parameter would be
helpful then folks move on to something else without really coming to a
conclusion.

I agree with you that the HTML5 definition of "alternate" is lacking but
I understand why they've done things that way and I applaud their
effort.  They're documenting existing practice even if it is
fundamentally flawed.  At least they're moving things in the right
direction with the "feed" link relation but it's too early to tell if
that effort is going to pan out in the end.

> disruptive; it doesn't require futzing around with existing specs and

Possibly. But at this point I'm not yet convinced.

- James

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 30 Nov 2006 12:00:36 -0500

On 11/30/06, James M Snell <[email-masked]> wrote:
> "subscribe" link.

Of course it does. Any program interested in consuming information is
going to ignore unknown parameters.

-- 

Robert Sayre

---

From: Bill de hOra <[email-masked]>
Date: Thu, 30 Nov 2006 17:11:27 +0000

"Well it's all octets so in one sense the processing is the same."

I have to agree with James.

The right questions in my mind is this - how is processing an entry 
different from processing a feed with that and 42 entries?

The idea that an entry is a degenerate feed is interesting, but 
unsubstantiated. Seriously, i'm not getting it. My experience is the 
opposite now, across 3 protocols; feeds are the odd men out (http needs 
them to deliver collections) and entries are not subsets of feeds. If 
there's real uniformity, I don't see it. To see it, I'd need to see that 
feeds and entries are closed under processing, and probably structurally 
isomorphic.

We've enough field experience that suggests having entries and feeds 
sharing a media type is at best inconvenient.  I only have to start 
thinking about how an APP collection handles partial update failures on 
a feed to think I need a dedicated media type for dealing with feeds.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Thu, 30 Nov 2006 17:17:12 +0000

Mark Baker wrote:

> [..] it it's

One question and one observation. The question: how will this set a 
precedent? The observation: if we really want to avoid this problem 
(assuming there is a problem), then RDF was the answer, not a pretence 
of uniformity.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 09:26:53 -0800

> "Well it's all octets so in one sense the processing is the same."

Btw, My apologies if my original comment about the xml parsing came
across as being snarky; that was not the intention.  The point I was
making was that how these things are "processed" depends entirely on how
you intend to use 'em.  So far I've seen no evidence that anyone intends
to use Entry Documents in the same way they use Feed Documents.

- James

---

From: Antone Roundy <[email-masked]>
Date: Thu, 30 Nov 2006 12:21:59 -0600

Summary of thoughts and questions:

*** Problems with the status quo ***

A) Consumers don't have enough information (without retrieving the  
remote resource) to determine whether to treat a link to an Atom  
document as a link to a live feed, a feed archive, or an entry.  (Is  
it appropriate to poll the link repeatedly?  How should information  
about the link be presented to the user?)

B) APP servers can't communicate whether they will accept feed  
documents or only entry documents.

*** Possible solutions ***

1) Add a type parameter to the existing media type:

+ With the exception of a few details, the documents are all exactly  
the same format (does it contain a feed element, or does it start at  
the entry element, is it a "live" feed document or an archive, etc.),  
so a single media type makes the most sense (definitely for live  
feeds vs. archives, less certainly for feeds vs. entries).

- Some existing applications will ignore the parameter and may handle  
links to non-live-feeds inappropriately

- Some existing applications may not recognize application/atom 
+xml;type=feed as something appropriate to handle the same way they  
handle application/atom+xml now.

? I haven't been following development of the APP, so forgive my  
ignorance, but can parameters be included in the accept element?

2) Create (a) new media type(s) (whether like application/atomentry 
+xml or application/atom.entry+xml):

+ Applications that currently treat all cases of application/atom+xml  
the same would ignore non-feed links until they were updated to do  
something appropriate with the new media type.

- Differentiating between live feeds and archives by media type seems  
really wrong since their formats are identical.  This isn't as big a  
negative for entry documents, but it still seems suboptimal to me.

- If a media type were created for archive documents, would APP  
accept including application/atom+xml imply acceptance of archive  
documents too?  Neither yes nor no feels like a satisfying answer.

3) Use @rel values to differentiate:

- That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why make it  
worse?

+ That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why not work  
on all these messy problems in the same place?

- That wouldn't help with the APP accept issue.

4) Create a new media type for entry documents, and add a parameter  
to application/atom+xml to differentiate between live and archive  
feeds (and for any other documents that have the identical format,  
but should be handled differently in significant cases).

- Doesn't prevent existing apps that ignore the parameter from  
polling archive documents.

+ Does solve the rest of the problems without the negatives of #2 above.

5) Create a new media type for entry documents, and use @rel values  
to solve issues that doesn't solve:

+/- Messy territory

If we were starting from scratch, I'd probably vote for #1.  Since  
we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have  
to think about #5 more first.

Antone

---

From: James M Snell <[email-masked]>
Date: Thu, 30 Nov 2006 10:57:08 -0800

Excellent summarization Antone, thank you.

> ignorance, but can parameters be included in the accept element?

I'd have to double check the definition of "media-range" but the
original intent was that parameters would be allowed but likely rarely used.

> [snip]
> 4) Create a new media type for entry documents, and add a parameter to
> application/atom+xml to differentiate between live and archive feeds
> (and for any other documents that have the identical format, but should
> be handled differently in significant cases).
> 
> [snip]
> 
> If we were starting from scratch, I'd probably vote for #1.  Since we're
> not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think
> about #5 more first.
> 

I personally don't care so much about differentiating archive feeds. At
this point I'm thinking that some combination of 4 and 5 would be best.

- James

---

From: Ernest Prabhakar <[email-masked]>
Date: Thu, 30 Nov 2006 11:01:00 -0800

Hi Antoine,

> Summary of thoughts and questions:

Thanks -- this is incredibly helpful.  However, might I suggest a  
couple more options?

6) Change expectations, not the spec.

Consumers must poll the feed to inspect the metadata, and Servers  
must accept both.

7) Disallow entry-only documents

Require all Atom documents to have a feed wrapper in order to be  
parsed properly. This is basically #4 + procrastination. :-)

I'm not saying these are necessarily _good_ options, but I'd like to  
be sure that whatever we do propose is superior to either of these;  
i.e., is the use of entry-only documents important enough to justify  
all this work?

Thanks,
-enp

> document as a link to a live feed, a feed archive, or an entry.   
> (Is it appropriate to poll the link repeatedly?  How should  
> information about the link be presented to the user?)
>
> + With the exception of a few details, the documents are all  
> exactly the same format (does it contain a feed element, or does it  
> start at the entry element, is it a "live" feed document or an  
> archive, etc.), so a single media type makes the most sense  
> (definitely for live feeds vs. archives, less certainly for feeds  
> vs. entries).
>
> - Some existing applications will ignore the parameter and may  
> handle links to non-live-feeds inappropriately
>
> + Applications that currently treat all cases of application/atom 
> +xml the same would ignore non-feed links until they were updated  
> to do something appropriate with the new media type.
>
> - Differentiating between live feeds and archives by media type  
> seems really wrong since their formats are identical.  This isn't  
> as big a negative for entry documents, but it still seems  
> suboptimal to me.
>
> "alternate" vs. "alternate feed" vs. "feed alternate" -- why make  
> it worse?
>
> "alternate" vs. "alternate feed" vs. "feed alternate" -- why not  
> work on all these messy problems in the same place?
>
> we're not, I'd vote for #4 first, and perhaps #5 second, but I'd  
> have to think about #5 more first.
>
> Antone
>

---

From: Eric Scheid <[email-masked]>
Date: Fri, 01 Dec 2006 07:38:09 +1100

> to think about #5 more first.

Starting from scratch, idealised, I'd want different media types (or params)
for entry documents and feed documents, and link type which clearly
indicates "this is for subscription", as distinct from "this is an alternate
representation", "this is an archive", etc.

Using the two mechanisms together allows combinations such as "here is a
feed you can subscribe to of the comments for this entry" and "here is a
feed document listing related resources, but since it won't likely be
updated don't bother subscribing".

I'd like to be able to use a lot of the link types we currently use for html
(directory, help, toc, related, next, etc) to refer to resources which
happen to be serialised in the atom feed document format, and feel safe in
knowing they won't be automagically treated as being subscription feeds.

e.