- From: Ken Murchison <murch@andrew.cmu.edu>
- Date: Thu, 19 Sep 2013 11:53:35 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Cyrus Daboo <cyrus@daboo.name>, WebDAV <w3c-dist-auth@w3.org>
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) "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." -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Received on Thursday, 19 September 2013 15:54:05 UTC