- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 20 Jun 2015 12:16:47 +1200
- To: ietf-http-wg@w3.org
On 20/06/2015 5:08 a.m., Cyrus Daboo wrote: > Hi Martin, > > --On June 19, 2015 at 9:56:11 AM -0700 Martin Thomson > <martin.thomson@gmail.com> wrote: > >>> Indicates whether the client prefers a CalDAV server >>> >>> to send "VTIMEZONE" iCalendar components in responses. >>> >> >> >> This is a very general type of solution to what appears to be a highly >> specific problem. Isn't this just content negotiation? Could you use a >> MIME type? >> >> I understand that there might be compatibility issues, but this seems >> like >> a poor use of the Prefer mechanism. > > Content negotiation at the HTTP level (Accept header) is not possible > here because some of the CalDAV responses actually contain calendar data > embedded in an overall XML response - i.e., the HTTP response is > application/xml, that contains XML elements with text/calendar data in > them. We want those embedded calendar data elements to be subject to the > "preference". 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. 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. Amos
Received on Saturday, 20 June 2015 00:17:23 UTC