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

[Michael Douglass <[e-mail]>]

(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:
>
> 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/
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify