Eric Scheid wrote:
> On 15/12/06 7:29 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote:
>
>> Besides, if you want to do fancy thing with a member, simply post a
>> media resource which is an atom entry. This won't be modified by the
>> server and will solely be treated a media resource.
>
>
On 12/14/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
This requirement has to be stated explicitly, at least as a SHOULD. This is
the kind of thing that clients come to completely rely on, and then you find
some special-purpose server that decides this doesn't fit in its model.
"Well, the spec
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.
http://www.imc.org/atom-protocol/mail-archive/msg05425.html
In an
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 -=
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.
In case you haven't noticed, the WG is hopelessly split
between
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
On 15/12/06 7:29 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote:
> Besides, if you want to do fancy thing with a member, simply post a
> media resource which is an atom entry. This won't be modified by the
> server and will solely be treated a media resource.
promise? does the spec support
On 14/12/06 3:23 PM, "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
>
> 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.
>
Could it be?
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0228.html
- Sylvain
Lisa Dusseault wrote:
Can a server ever ignore part of an edit and successfully process the
rest?
Yes. Think of a client that throws in a slew of random link elements with
relations my server implementation doesn't understand. Same with foreign
markup. The server is in charge.
I complete
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.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter opt
>>> 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 machine A
Thanks for responding to my review. I look forward to seeing a
revised draft. Below I've excerpted the stuff that is still giving
me serious problems.
On Dec 7, 2006, at 8:36 AM, Joe Gregorio wrote:
Can a client modify an entry to contain a link relation element in
the
following cases
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.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter opt
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.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter opt
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.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parame
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 implementa
"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
defin
+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
>
> Bob Wyman wrote:
>> There is, I think, a compromise position here which will avoid breaking
>> those existing implementations which follow the existing RFC's.
>
> In 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.
In case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter option.
If a few peo
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) assu
--- 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
> b
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
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
27 matches
Mail list logo
