Joe Gregorio schrieb:
...
This is the documented consensus of the WG. The next draft will have
verbage that makes this position clearer. If some implementations
find that too loose and want octet-for-octet storage they can use
always WebDAV.
[1]
Joe Gregorio wrote:
On 12/14/06, Sam Ruby [EMAIL PROTECTED] wrote:
I believe I first saw this in a response made by Roy Fielding to an
assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I
can't immediately find the reference.
* 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
Lisa Dusseault wrote:
Can a client modify an entry to contain a link relation element in the
following cases:
- To point to a resource on a different server entirely?
There is no reason to believe that any of these resource are on
the same machine to begin with. I could POST to media to
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?
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 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
I guess I'm assuming that one would want clients to be able to extend
Atom unilaterally. The choices that I highlighted as problematic
make it harder for clients to reliably add extensions to Atom
documents. (It remains easy for servers to add extensions to Atom
feeds and entries using
18 matches
Mail list logo
