+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
t 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.
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 p
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
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
I've realised another use case for atom entry documents.
I'm using del.icio.us to track certain memes. For example:
http://del.icio.us/tag/atom
http://del.icio.us/tag/rss
http://del.icio.us/tag/folksonomy
For each of those pages they offer an RSS feed. The feed's entr
23 matches
Mail list logo