Re: NEW PREFERENCE - vtimezone

On 20/06/2015 12:38 p.m., Cyrus Daboo wrote:
> Hi Amos,
> 
> --On June 20, 2015 at 12:16:47 PM +1200 Amos Jeffries wrote:
> 
>> This is not about the existing application/xml mime type. Martin is
>> suggesting a new mime type. Such as application/xml+vtimestamp.
>>
>> The client would send the HTTP header Accept:*/xml+vtimestamp,*/xml and
>> the server return application/xml+vtimestamp where the XML has embeded
>> vtimestamps.
> 
> That is not very practical in this case as we have three iCalendar media
> types (text/calendar, application/calendar+xml,
> application/calendar+json) in addition to the application/xml.

By making vtimestamp optional, you actually have 6. Regardless of
whether they are named/registered or not.

> 
>> Another way to look at whether Prefer is appropriate is - what can HTTP
>> proxies or HTTP servers that support Prefer but not WebDAV do to meet
>> the preference ?
>>
>> In this case there is nothing. Since payload manipulation requires
>> WebDAV XML format knowledge.
> 
> The Prefer spec says this:
> 
>   The Prefer header field is end to end and MUST be forwarded by a
>   proxy if the request is forwarded unless Prefer is explicitly
>   identified as being hop by hop using the Connection header field
>   defined by [RFC7230], Section 6.1.
> 
> Which implies that an end-to-end preference is just as valid a use case
> as a one where the proxy can intervene.
> 

I know. However it does not mean they can be ignored completely. Just by
existing they affect what would be the best choice.

An HTTP proxy receiving this Prefer option but not supporting it, will
respond with a cached object that does not embed the vtimestamp data as
readily as it would respond with vtimestamp data to a request without
the Prefer header at all.

To resolve that you would have to send Vary:Accept,Prefer from the
server. Which causes a permutation explosion of cached content types
worse than having multiple mime types would have been. At least with
mime types the server can restrict itself to a small subset of emitted ones.

So is it acceptible for the client sending this Prefer to "randomly"
receives responses without any vtimestamp data?
 If yes then Prefer is usable, otherwise a mime type would be better
despite the number of existing types.

Amos

Received on Saturday, 20 June 2015 01:07:13 UTC