- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Sep 2013 18:07:32 +0200
- To: Ken Murchison <murch@andrew.cmu.edu>
- CC: Cyrus Daboo <cyrus@daboo.name>, WebDAV <w3c-dist-auth@w3.org>
On 2013-09-19 17:53, Ken Murchison wrote: > On 09/19/2013 10:53 AM, Julian Reschke wrote: >> On 2013-09-19 16:43, Ken Murchison wrote: >>> On 09/19/2013 10:38 AM, Cyrus Daboo wrote: >>>> Hi Ken, >>>> >>>> --On September 19, 2013 at 10:05:04 AM -0400 Ken Murchison >>>> <murch@andrew.cmu.edu> wrote: >>>> >>>>>>> If you feel that this is a show-stopper, I can certainly remove this >>>>>>> text. >>>>>> >>>>>> I'd get rid of it. >>>>> >>>>> OK. >>>>> >>>> >>>> Well I do think it is worth mentioning that the Brief header exists >>>> and this new draft is defining a standards-based alternative to that - >>>> emphasizing that servers/clients that currently support Brief can also >>>> implement Prefer without any problems. The only thing to state is that >>>> if a server receives both Brief and Prefer it should prefer Prefer! >> >> Prefer: prefer >> >> /me ducks >> >>> Do you have any suggested text to replace/augment what I have in >>> Appendix A? I think Julian wants me to remove the suggestion that >>> Prefer-based implementations also implement Brief. >> >> Stating where it came from is good (plus having the references). >> >> I just wouldn't recommend to implement it; if you do so, people *will* >> ask what the point of the new spec is. >> > > How about something like this: > > "Client and server implementations that already support the Brief field > header should be able to add support for the return=minimal preference > with little effort." (I had "minimal effort" but it didn't read right) Right. You need a proper parser for "Prefer", after all. > "If a server receives both Brief and Prefer header fields in a request, > it MUST ignore the Brief header field and only apply the Prefer header > field preferences, if it so chooses." Sounds good to me. Best regards, Julian
Received on Thursday, 19 September 2013 16:08:17 UTC