Subject: [calsify] WGLC for draft-ietf-calext-icalendar-series

From: Daniel Migault <[email-masked]>
Date: Tue, 5 Nov 2019 21:09:39 -0500

Hi,

This email starts a WGLC for the
document draft-ietf-calext-icalendar-series [1]. In order to move the
document forward, please review the document and state your opinion or
comments until Tuesday November 19.

Note that given the history of the document, it is important to show the
IESG the document is supported by the WG.

Yours,
Bron and Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-icalendar-series/

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 18 Nov 2019 17:59:33 +0800

My notes and queries after reading this through:

> These LINK headers will be delivered when a client carries out a HEAD
> request targeting the URL of the resource.

Is there a reason this isn't added in response to the GET request as
well? If the client is hoping to use CalDAV then it makes sense to do
the HEAD first, but if it only supports the "enhanced get" it'll need to
do the GET next anyway regardless of the response and so it would save
you a request.

> by specifying the Prefer header field preference "limit=n" where n is
> the number of components.

If you want to specify "limit=n" as well as "subscribe-enhanced-get",
it's unclear to me whether that's two Prefer header fields or one (e.g.
comma separated). I'd guess two (since it's not specified), but use of
the definite article "the Prefer header field" implies maybe not. This
needs to be clarified, and an example would be very welcome.

> 5.  Header Field: Sync-Token
>   The value MUST be a URI.

Why is this a URI? It's unclear to me the purpose of that, especially
given the spec says:

> Client MUST not attempt to interpret the data URI value.

Shouldn't this just be an opaque string?

> 7.  Link relations

As discussed in the meeting today, this needs more fleshing out and some spec references.

>  The following preferences have been added to the HTTP Preferences
>   Registry defined in [RFC7240]
>
>   Preference
>    subscribe-enhanced-get

We'll need to check with the HTTP folks whether this is considered
appropriate use of the Prefer header. There's already the
"return=minimal" Prefer option registered, which maybe we could use? If
registering a new one, given how tied this is to calendaring and
iCalendar the name probably shouldn't be quite so generic.

> 9.3.  Link Relation Registrations
>
>   This document defines the following new iCalendar properties to be
>   added to the registry defined in section=8.2.3 [RFC5545]:

I am very confused by this; why is anything being added to the iCalendar
property registry? How are these meant to be used as iCalendar
properties?

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 18 Nov 2019 20:13:35 +0800

Damn, got my threads mixed up. The above reply was of course meant to be about draft-ietf-calext-subscription-upgrade.