Subject: [calsify] WGLC for draft-ietf-calext-subscription-upgrade

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

This email starts a WGLC for the
document draft-ietf-calext-subscription-upgrade [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-subscription-upgrade/

---

From: Michael Douglass <[email-masked]>
Date: Tue, 19 Nov 2019 11:20:24 -0500

(Reposted Neil's reply to the wrong list)

> 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.
A number of people have asked for this. I can specify that they MUST be 
returned on GET as well. The issue for some people is that they want to 
farm the download off to another process as it's potentially very large.
>
>> 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.
I'd need to read the Prefer spec again but (also http). I suspect it 
doesn't matter if it's one or two header fields.
>
>> 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:
because it has to be in WebDAV sync (perhaps a point to consider in 
jscalendar). Anything can be turned into a data URI. As to why it's a 
URI in WebDAV sync maybe the authors can tell us (or maybe the spec does)
>
>> 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.
I think that we started there. However it might conflict with other 
intended uses. I'd really prefer a specific option for this purpose.
>
>> 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?
Maybe a leftover
> Neil.

On 11/5/19 21:09, Daniel Migault wrote:
> document draft-ietf-calext-subscription-upgrade [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-subscription-upgrade/
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Wed, 20 Nov 2019 12:30:12 -0500

>> Shouldn't this just be an opaque string?
It's in section 3.2 of webdav sync

   The synchronization token itself MUST be treated as an "opaque"
    string by the client, i.e., the actual string data has no specific
    meaning or syntax.  However, the token MUST be a valid URI to allow
    its use in an If precondition request header (seeSection 5  <https://tools.ietf.org/html/rfc6578#section-5>).  For
    example, a simple implementation of such a token could be a numeric
    counter that counts each change as it occurs and relates that change
    to the specific object that changed.  The numeric value could be
    appended to a "base" URI to form the valid sync-token.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 22 Nov 2019 11:28:08 +0800

On Thu, 21 Nov 2019, at 01:30, Michael Douglass wrote:
>> Why is this a URI? It's unclear to me the purpose of that, especially given the spec says:
> because it has to be in WebDAV sync

OK, but this is not WebDAV. The reason given in WebDAV is so you can use it with an `If` header field, which is WebDAV specific I believe so not relevant here. An opaque token removes an unnecessary constraint for implementors; they can always use a URL if they want (e.g. if they are basing this off a WebDAV backend) but don't have to.

Neil.