Re: draft-snell-http-prefer: Preference-Applied

[James M Snell <[e-mail]>]

The Preference Header spec has already completed the RFC process. The
Preference-Applied was a MAY because there's no significantly
compelling reason to make it a SHOULD or MUST in all cases... there
are simply many cases where it's just not needed. It's utility really
depends on the nature of the Preferences being used.

On Thu, Jun 6, 2013 at 11:44 AM, Ken Murchison <[e-mail]> wrote:
> All,
>
> I know its a little late for this feedback, but I thought I'd bring it to
> the list anyways.
>
> The members of the Calendar and Scheduling Consortium (CalConnect) are
> beginning to use the Prefer header fairly heavily based on
> http://tools.ietf.org/html/draft-murchison-webdav-prefer   At our latest
> interop testing session earlier this week, one of the CalDAV client authors
> noticed that the use of the Preference-Applied response header by a server
> is currently documented as a MAY in draft-snell-http-prefer.  The ensuing
> discussion in the room reached a consensus of "if a client can't rely on a
> server returning this response header if/when it applies one or more
> preferences, then its not very helpful".
>
> I know that Preference-Applied was reintroduced after a previous CalConnect
> interop session, but I don't recall if the strength of the conformance
> language for Preference-Applied was discussed on the list.  Was there a
> compelling reason behind making the use of Preference-Applied only a MAY for
> servers, or can this be changed into a SHOULD or MUST?  Or would we be
> better served adding such language to my WebDAV Prefer draft?
>
> Obviously, a server can choose not to apply any client requested
> preferences, but is there a use-case for a server applying a preference and
> not wanting to tell the client that it did so?
>
> Regards,
> Ken
>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University