Subject: NEW PREFERENCE - vtimezone

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Jun 2015 14:44:56 +0000

Hi,

We would like an expert review for the Preference Header vtimezone. The registration template below is provided by draft-ietf-tzdist-caldav-timezone-ref-03 section 8 [1]:
Preference: vtimezone

      Value: One of either "yes" or "no"

      Description: Indicates whether the client prefers a CalDAV server
      to send "VTIMEZONE" iCalendar components in responses.

      Reference: [this RFC], Section 3.1.3<https://tools.ietf.org/html/draft-ietf-tzdist-caldav-timezone-ref-03#section-3.1.3>.

This RFC designates draft-ietf-tzdist-caldav-timezone-ref-03

[1] https://tools.ietf.org/html/draft-ietf-tzdist-caldav-timezone-ref-03

BR,
Daniel

From: Daniel Migault [mailto:[email-masked]]
Sent: Wednesday, June 10, 2015 10:14 AM
To: [email-masked]
Cc: Cyrus Daboo; Barry Leiba; [email-masked]; [email-masked]
Subject: Registering New Prefer Header

Hi,

We would  like to provide recommendation on how to proceed to register a new Prefer Header and get expert review for that new header. Would you agree with the following text:

"Registration requests should be sent to the <[email-masked]<mailto:[email-masked]>> mailing list, marked clearly in the subject line (e.g., "NEW PREFERENCE - example" to register an "example" preference)."

BR,
Daniel

[Ericsson]<http://www.ericsson.com/>
DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jun 2015 09:56:11 -0700

On 19 June 2015 at 07:44, Daniel Migault <[email-masked]>
wrote:

> Indicates whether the client prefers a CalDAV server
>

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.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 19 Jun 2015 13:08:01 -0400

Hi Martin,

> 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".

Of course we could just invent our own HTTP to indicate this "embedded 
data" preference, but making use of Prefer seems better in that we are 
already encouraging clients to use that (e.g., return=minimal is a very 
useful for reducing response sizes with many of the WebDAV PROPFIND and 
REPORT requests that CalDAV clients use).

-- 
Cyrus Daboo

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 20 Jun 2015 12:16:47 +1200

On 20/06/2015 5:08 a.m., Cyrus Daboo wrote:
> Content negotiation at the HTTP level (Accept header) is not possible
> here because some of the CalDAV responses actually contain calendar data

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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 19 Jun 2015 20:38:37 -0400

Hi Amos,

> the server return application/xml+vtimestamp where the XML has embeded

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.

> 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.

-- 
Cyrus Daboo

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 20 Jun 2015 13:06:38 +1200

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:
> 
> 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.

> 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