Subject: Atom Entry Documents

From: James M Snell <[email-masked]>
Date: Sun, 10 Dec 2006 11:19:53 -0800

Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.  The only
question is whether or not to use a new media type or an optional type
param.  I'm going to write up an I-D this week.

Please let me know which of the two approaches below y'all prefer...

Option A) Optional Type Param

  application/atom+xml; type=entry
  application/atom+xml; type=feed

Option B) New Entry media type

  application/atom.entry+xml

- James

---

From: Jan Algermissen <[email-masked]>
Date: Sun, 10 Dec 2006 22:11:24 +0100

>   application/atom.entry+xml

+1

Jan

---

From: Geoffrey Sneddon <[email-masked]>
Date: Sun, 10 Dec 2006 22:13:27 +0000

+1

- Geoffrey Sneddon

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 10 Dec 2006 17:32:05 -0500

>   application/atom+xml; type=feed

+1 to Optional Type Parameter. The alternative of a new media type for
entries is too disruptive and breaks existing implementations based on the
current RFC. Such "violence" should not be permitted unless an exceptionally
compelling case has been made. No such case has been presented. (In my
opinion...)

bob wyman

---

From: "Franklin Tse" <[email-masked]>
Date: Mon, 11 Dec 2006 09:32:36 +0800

+1

Franklin Tse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Monday, December 11, 2006 03:20
To: atom-syntax
Subject: Atom Entry Documents

- James

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 11 Dec 2006 18:08:31 +0100

>   application/atom+xml; type=feed

+1. I believe that a type parameter allows more smoothly for new types to  
be introduced in the future, plus it more clearly states that it is an  
Atom resource than a completely new MIME type. All in my humble opinion of  
course. This is just a matter of taste, afaict.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Judy Piper" <[email-masked]>
Date: Mon, 11 Dec 2006 13:31:52 -0500

+1

IMO, new optional type parameters make more sense.
Judy-

---

From: Ernest Prabhakar <[email-masked]>
Date: Mon, 11 Dec 2006 10:55:54 -0800

+1

I presume the whole reason we need this is that *existing* parsers  
are "blindly" assuming that application/atom+xml means a feed  
document. If that is an invalid assumption, then I think (B) is the  
way to go.  If not, them I'm unclear what the problem is.

-- Ernie P.

---

From: "Kyle Marvin" <[email-masked]>
Date: Mon, 11 Dec 2006 12:56:15 -0600

>   application/atom+xml; type=feed

+1.   I believe other UA-visible Atom document syntax qualifiers will be
needed/coming downstream.  For example. ones describing the expected
extension model(s) of the target Atom document.  Feed vs. entry is just one
syntax variant of an Atom document, others of UA interest might be "this is
an Atom document containing OpenSearch results" or "this is an Atom Document
that describes media using Media RSS extensions".

I'm not sure that treating each syntax variant as a unique MIME type is a
scalable approach for the long haul.  One specific issue is that you will
also have to deal with combinations (ex "this Atom document is a feed that
contains OpenSearch results listing Media RSS entries").

Cheers!

-- Kyle

---

From: Martin Duerst <[email-masked]>
Date: Mon, 11 Dec 2006 16:49:03 +0900

+1

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Eric Scheid <[email-masked]>
Date: Tue, 12 Dec 2006 13:05:10 +1100

> I believe other UA-visible Atom document syntax qualifiers will be
> needed/coming downstream.  For example. ones describing the expected extension
> model(s) of the target Atom document.  Feed vs. entry is just one syntax
> variant of an Atom document, others of UA interest might be "this is an Atom
> document containing OpenSearch results" or "this is an Atom Document that
> describes media using Media RSS extensions".

I'm not so sure. I see the difference between the two being "one" vs "many",
and nothing more. What you want could however be accommodated by additional
parameters..

> scalable approach for the long haul.  One specific issue is that you will also
> have to deal with combinations (ex "this Atom document is a feed that contains
> OpenSearch results listing Media RSS entries").

    application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS

(or syntax to that effect)

e.

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 11 Dec 2006 22:26:55 -0500

On 12/10/06, James M Snell <[email-masked]> wrote:
> distinctly flagging Entry Documents in the media type.

Erm, isn't it up to the chairs to declare concensus?

AFAICT, the discussion I was involved in failed to achieve it.  If I'm
mistaken, I'll be happy to put in my 2c on a solution of course.

Mark.

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Dec 2006 19:32:57 -0800

> Erm, isn't it up to the chairs to declare concensus?

The I-D would be an individual draft, not a WG draft.  The chairs only
decide consensus on WG stuff.  Once I get the initial version of the
draft up, we can see if it makes sense to move it forward as a WG draft,
in which case, I'll gladly let the chairs handle it.  :-)

> mistaken, I'll be happy to put in my 2c on a solution of course.

I think there was consensus that some form of mechanism for identifying
entry documents would be helpful.  Where I see a lack of consensus is on
the specific mechanism to use.

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Dec 2006 21:22:14 -0800

Sure you can.

Adding this to mime.types...

  application/atom+xml                            atom
  application/atom+xml;type=entry                 entry
  application/atom+xml;type=feed                  feed

works just fine in apache2.  Ask for a static file *.atom, and you get
application/atom+xml.  Ask for a static file *.entry and you get
application/atom+xml;type=entry.

- James

Hugh Winkler wrote:
> Another reason for +1 for B: consider serving static files, some of
> type entry, some of type feed. You can give each file type a different
> extension (.atom, .atom-entry) and configure Apache to serve the
> correct mime type for each. You could not configure Apache to serve
> files with the right type parameter, if you choose A.
>

---

From: "Kyle Marvin" <[email-masked]>
Date: Mon, 11 Dec 2006 23:49:01 -0600

On 12/11/06, Eric Scheid <[email-masked]> wrote:
> extension

Exactly.  But the key point is that at some point you _need_ the additional
parameters, so let's stop thinking we can cram everything into the base
media type/subtype and be limited by UAs that understand them (only) and
start using parameters!

> (or syntax to that effect)

Yup.   Pretty close to what I was thinking.

Cheers!

-- Kyle

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Dec 2006 23:22:16 -0800

What would the relationship of that document be to RFC4287?

Cheers,

On 2006/12/11, at 7:32 PM, James M Snell wrote:

> The I-D would be an individual draft, not a WG draft.

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Dec 2006 23:39:25 -0800

*If* the document proceeds to Proposed Standard, the new RFC would
update RFC4287 either by adding a new type param or by deprecating the
use of application/atom+xml for atom entry documents in favor of a new
media type.  No other part of RFC4287 would be affected.

Ideally, I would much rather this be a WG draft.  I pinged Tim about it
the other day and he suggested that I go ahead with a I-D for now and
that we can explore whether or not to move forward with it as a WG draft
later.

- James

---

From: "Kyle Marvin" <[email-masked]>
Date: Tue, 12 Dec 2006 09:47:46 -0600

Hi Mark,

I realize the question is part process and part technical, but here's my
wish for the technical portion:  I'm hoping that whatever is done can be
additive and optional, such that it can enable new capabilities without
disrupting existing usage of 4287 (only).

This is one of the reasons why I prefer that we use optional type qualifiers
(Option A) rather than deprecating one mime type and creating two new ones
(Option B).

Cheers!

-- Kyle

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 12 Dec 2006 11:46:16 -0500

> that we can explore whether or not to move forward with it as a WG draft

I'm uncomfortable with this.

If there's consensus to do something about identifying entry
documents, let's do that.  If there isn't, let's not.

Mark.

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Dec 2006 14:25:44 -0800

> Erm, isn't it up to the chairs to declare concensus?

<co-chair-mode>I agree that there exists sentiment in favor of there 
being a way to distinguish between Feed and Entry documents.  I think 
the notion of consensus is only meaningful in the context of actual spec 
language, so it seems to me that it would be helpful to have some 
proposed language to look at.  So I see no downside in James doing an 
I-D.</co-chair-mode>

  -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 15 Dec 2006 01:28:50 +0100

> that we can explore whether or not to move forward with it as a WG draft

Can't just the APP specification include language that specifies a new  
MIME type for Atom Entries, since it's mostly APP implementations that  
have a use for it? Or would that be totally out of place?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 15 Dec 2006 01:33:36 +0100

On Tue, 12 Dec 2006 23:25:44 +0100, Tim Bray <[email-masked]> wrote:

> [...] So I see no downside in James doing an I-D.

But is a separate I-D really necessary? If, like Kyle Marvin suggests, the  
new MIME type for Atom Entries actually becomes a type parameter of the  
existing Atom MIME type, can't the language that specifies this be  
included in the APP specification?

By that, APP will only extend RFC 4287 and not deprecate anything. It  
might include wording like "SHOULD use the type parameter", but that still  
makes the old and bare MIME type valid. Thus, implementing RFC 4287 will  
not require you to use a type parameter, but implementing the APP  
specification will strongly encourage you to do so. Won't that solve it  
all?

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Dec 2006 16:40:01 -0800

Quite a few folks seemed to have a preference to a separate doc.

- James

Asbjørn Ulsberg wrote:
> --Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 15 Dec 2006 01:48:48 +0100

> Quite a few folks seemed to have a preference to a separate doc.

What does "quite a few folks" mean wrt consensus? What reasons are there  
not to include this in the APP specification?

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Dec 2006 12:35:10 -0800

I don't feel that changing parts of RFC4287 is appropriate for an  
individual draft, particularly when the WG that did RFC4287 exists.   
Certainly in order to update RFC4287 it would *have* to be Proposed  
Standard.  What constitutes an update or change (rather than an  
optional extension) might be open to some debate.

Echoing Tim, I agree there's no problem with James doing an  
individual draft for now so that everybody can evaluate a specific  
proposal and suggest what should be done with it.

Lisa

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 15 Dec 2006 15:51:35 -0500

+1

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: James M Snell <[email-masked]>
Date: Fri, 15 Dec 2006 12:57:30 -0800

+1 many times over.

Lisa Dusseault wrote:
> Standard.  What constitutes an update or change (rather than an optional
> extension) might be open to some debate.
> [snip]