+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 cha
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
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) mi
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 -=
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
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
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 t
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?
I agree that there exists sentiment in favor of there
being a way to distinguish between Feed a
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 RFC
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
*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 th
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/
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 exampl
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
application/ato
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 d
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.
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
At 10:32 06/12/11, Franklin Tse wrote:
>
>> Option B) New Entry media type
>
>> application/atom.entry+xml
>
>+1
+1
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
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
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
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
distinct
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
22 matches
Mail list logo
