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)
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
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
+1 many times over.
Lisa Dusseault wrote:
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
On Tue, 12 Dec 2006 23:25:44 +0100, Tim Bray [EMAIL PROTECTED] 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
On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell [EMAIL PROTECTED]
wrote:
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
Quite a few folks seemed to have a preference to a separate doc.
- James
Asbjørn Ulsberg wrote:
On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell [EMAIL PROTECTED]
wrote:
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
On Fri, 15 Dec 2006 01:40:01 +0100, James M Snell [EMAIL PROTECTED]
wrote:
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?
--
Asbjørn Ulsberg -=|=-
*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
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
On 12/12/06, James M Snell [EMAIL PROTECTED] wrote:
*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
Mark Baker wrote:
Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.
Erm, isn't it up to the chairs to declare concensus?
co-chair-modeI agree that there exists sentiment in favor of there
being a way to distinguish
On Sun, 10 Dec 2006 20:19:53 +0100, James M Snell [EMAIL PROTECTED]
wrote:
Option A) Optional Type Param
application/atom+xml; type=entry
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
Option A) Optional Type Param
application/atom+xml; type=entry
application/atom+xml; type=feed
+1
IMO, new optional type parameters make more sense.
Judy-
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
Ok, the recent discussion seems to point towards a consensus towards
distinctly
On Dec 10, 2006, at 11:19 AM, James M Snell wrote:
Option B) New Entry media type
application/atom.entry+xml
+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,
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
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
At 10:32 06/12/11, Franklin Tse wrote:
Option B) New Entry media type
application/atom.entry+xml
+1
+1
#-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote:
application/atom+xml; type=entry
application/atom+xml; type=feed
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
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
Ok, the recent discussion seems to point towards a consensus towards
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.
Mark Baker wrote:
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.
Erm, isn't it up to the chairs to declare concensus?
The I-D would be an individual draft, not
Sure you can.
Adding this to mime.types...
application/atom+xmlatom
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
On 12/11/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote:
application/atom+xml; type=entry
application/atom+xml; type=feed
I believe other UA-visible Atom document syntax qualifiers will be
needed/coming downstream. For example. ones
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/
22 matches
Mail list logo
