Ok, so we've had more than just a few people put up their hands and say
what Bob said. This week I'll go ahead write up an initial draft of
this using the type param option while we wait for the co-chairs to do
their hasty consensus grab :-)
- James
Tim Bray wrote:
[snip]
co-chair-modeIn
On Tue, 19 Dec 2006 21:27:07 +0100, James M Snell [EMAIL PROTECTED]
wrote:
Ok, so we've had more than just a few people put up their hands and say
what Bob said. This week I'll go ahead write up an initial draft of
this using the type param option while we wait for the co-chairs to do
On Sat, 16 Dec 2006 01:31:29 +0100, John Panzer [EMAIL PROTECTED] wrote:
Or both. Millions of blog entry pages have both an entry and a set of
comments on that entry. Yes, it's stretching the concept of 'alternate'
a long, long way.
Yes, it's a long stretch. RFC 4685 specifies how to build
* Bob Wyman [EMAIL PROTECTED] [2006-12-14 05:45]:
1) Define ;type=feed and ;type=entry as optional parameters.
(i.e. get them defined, registered, and ready to use.)
2) Leave RFC4287 unchanged. i.e. do NOT re-define
application/atom-xml
3) New specifications MAY require that ;type=entry be
Thursday, December 14, 2006, 9:04:00 AM, Henri Sivonen wrote:
On Dec 13, 2006, at 17:51, Mark Baker wrote:
But
given that an alternative exists which shouldn't break those servers,
why not use it when there's no apparent downside?
The downside is that implementations that (quite
On Fri, 15 Dec 2006 13:43:58 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote:
1) Define ;type=feed and ;type=entry as optional parameters.
(i.e. get them defined, registered, and ready to use.)
2) Leave RFC4287 unchanged. i.e. do NOT re-define
application/atom-xml
3) New specifications MAY require
I've always interpreted a kind of inheritance relationship between
MIME types.
It's never wrong to label an Excel file, an XML document, or an Atom
Feed as application/octet-stream, because all of those types ARE
octet-streams. It is just not as helpful as it could be.
Likewise, it is never
On 12/14/06, Tim Bray [EMAIL PROTECTED] wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the
On 12/15/06, David Powell [EMAIL PROTECTED] wrote:
I've always interpreted a kind of inheritance relationship between
MIME types.
It's telling that James felt it natural to choose the name type for
the parameter. Because it really is naming a new type of document.
In programming, whenever
On 12/15/06, Hugh Winkler [EMAIL PROTECTED] wrote:
It's telling that James felt it natural to choose the name type for
the parameter. Because it really is naming a new type of document.
What would be better than type? Might root work better?
It seems to me that
On 12/15/06, Bob Wyman [EMAIL PROTECTED] wrote:
On 12/15/06, Hugh Winkler [EMAIL PROTECTED] wrote:
It's telling that James felt it natural to choose the name type for
the parameter. Because it really is naming a new type of document.
What would be better than type? Might root work better?
On 15 Dec 2006, at 12:47, David Powell wrote:
An example would be an HTML page with rel=alternative links
pointing to a feed and an Atom Entry document. This seems quite a
reasonable use-case, yet if we don't create a new MIME type, then I'd
expect that all current feed reader
On Fri, 15 Dec 2006 13:47:05 +0100, David Powell [EMAIL PROTECTED]
wrote:
An example would be an HTML page with rel=alternative links
pointing to a feed and an Atom Entry document.
My thought on this is that that's actually broken. If not according to RFC
4287 or anything else, it's
Asbjrn Ulsberg wrote:
On Fri, 15 Dec 2006 13:47:05 +0100, David Powell
[EMAIL PROTECTED] wrote:
An example would be an HTML page with
rel="alternative" links
pointing to a feed and an Atom Entry document.
My thought on this is that that's actually broken. If not
2006/12/14, Bob Wyman:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
It was exactly the point behind my proposal for this 'type' parameter.
--
Thomas Broyer
On Dec 13, 2006, at 17:51, Mark Baker wrote:
But
given that an alternative exists which shouldn't break those servers,
why not use it when there's no apparent downside?
The downside is that implementations that (quite reasonably) assume
that application/atom+xml == feed are also reasonable
--- Bob Wyman [EMAIL PROTECTED] wrote:
1) Define ;type=feed and ;type=entry as optional
parameters. (i.e. get them
defined, registered, and ready to use.)
2) Leave RFC4287 unchanged. i.e. do NOT re-define
application/atom-xml
3) New specifications MAY require that ;type=entry
be used.
On 12/14/06, Henri Sivonen [EMAIL PROTECTED] wrote:
On Dec 13, 2006, at 17:51, Mark Baker wrote:
But
given that an alternative exists which shouldn't break those servers,
why not use it when there's no apparent downside?
The downside is that implementations that (quite reasonably) assume
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter option.
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter
+1 to yeah, what Bob said. We'll still have to manage the transition
around clients that don't send type=entry to GData services, but if we can
point at an APP spec where this param is required on POST/PUT, it's possible
to push through this.
-- Kyle
On 12/14/06, Tim Bray [EMAIL PROTECTED]
yeah what Bob said
I'm not sure it is ideal, but it seems the closest to consensus we're
ever going to get.
+1
On Dec 14, 2006, at 7:08 AM, Rogers Cadenhead wrote:
--- Bob Wyman [EMAIL PROTECTED] wrote:
1) Define ;type=feed and ;type=entry as optional
parameters. (i.e. get them
defined,
I've found the arguments in favor of the type param to be more
convincing than those in favor of the new media type...
...so +1 to what Bob said.
- James
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations
2006/12/14, Tim Bray:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
Tim Bray wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid
breaking those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the
On Thu, 14 Dec 2006 18:00:17 +0100, Tim Bray [EMAIL PROTECTED] wrote:
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly
Consider GData apps. Their docs aren't clear (tsk, tsk!) about the
use of a media type when inserting entries[1], but if they're doing it
properly then their services should be keying off of
application/atom+xml, and so will break if that's changed.
And? Should a status quo be better on
At 13:14 06/12/13, James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so on.
In the case of atom entries, atom-entry is more in line
Martin Duerst wrote:
James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so on.
In the case of atom entries, atom-entry is more in
On 12/13/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Consider GData apps. Their docs aren't clear (tsk, tsk!) about the
use of a media type when inserting entries[1], but if they're doing it
properly then their services should be keying off of
application/atom+xml, and so will break
At 4:41 PM +0900 12/13/06, Martin Duerst wrote:
At 13:14 06/12/13, James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so on.
In
Very helpful. Thank you.
- James
Martin Duerst wrote:
At 13:14 06/12/13, James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so
Other server implementations should have the same issue, of course.
So please explain me what a server currently does upon receiving an Atom
feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?
Returning a 415 error code seems like the wrong option since the
Sylvain Hellegouarch wrote:
[snip]
The GData server implementation requires a Content-Type value of
application/atom+xml when POSTing or PUTting an Atom entry to a
collection
(for all non-media collections). It will respond with a 400 (Bad Request)
http error on any other content type.
James M Snell wrote:
Sylvain Hellegouarch wrote:
[snip]
The GData server implementation requires a Content-Type value of
application/atom+xml when POSTing or PUTting an Atom entry to a
collection
(for all non-media collections). It will respond with a 400 (Bad Request)
http error on
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them
defined, registered, and ready to use.)
2) Leave RFC4287 unchanged. i.e. do NOT
On 12/13/06, Bob Wyman [EMAIL PROTECTED] wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
That's what I thought the type parameter option was, so sure, +1 on that too 8-)
Mark.
I seems obvious to me that Atom Feed and Entry docs are potentially
quite different things which can be used for entirely different
purposes. The contention that an Entry doc is somehow really the same
as a one-entry Feed doc is entirely unconvincing.
The Architecture of the Web
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
- James
Tim Bray wrote:
[snip]
(James, did you really mean atom.entry with the ugly dot?)
-Tim
Tim,
On 12/12/06, Tim Bray [EMAIL PROTECTED] wrote:
I seems obvious to me that Atom Feed and Entry docs are potentially
quite different things which can be used for entirely different
purposes. The contention that an Entry doc is somehow really the same
as a one-entry Feed doc is entirely
42 matches
Mail list logo
