[calsify] draft-ietf-calext-subscription-upgrade-09

[Ken Murchison <[e-mail]>]

Waaaay overdue review, but I Just did a complete re-read of this 
document and I think it could use some editorial changes as listed below

Abstract: I think we need a short description of what the document 
actually specifies, in addition to the registry changes.

Sec 1, first sentence: "The author would also like to thank..." -> "The 
author would like to thank..."

Sec 1, second para: This paragraph seems redundant given the first, but 
if kept: "The authors..." -> "The author..."

Sec 2, first sentence: "'webcal' scheme" -> "'webcal' URL scheme"  (or 
maybe "URI scheme")

Sec 2, para 2: Do we want to reference RFC 9110, Section 8.8 when we 
mention ETag and Last-Modified?

Sec 4.1: We should reference RFC 6578 when we introduce WebDAV Sync.

Sec 4.1: This section contradicts itself by first stating that if the 
Sync-Token is invalid that the server should respond with the full set 
of data.  It later states that an invalid Sync-Token should result in a 
409 response.

Sec 4.1: Does the client have to use Prefer:subscribe-enhanced-get on 
the initial fetch in order to receive a Sync-Token?

Sec 4.1: Shouldn't the server always respond with a Sync-Token if the 
client uses Prefer:subscribe-enhanced-get?  I think Preference-Applied 
indicates to the client whether the server sent the entire set of 
components or just the changes.  Overall, I think this section was 
written as a quick outline of the protocol, but probably needs 
re-working to make it more clear.  I'm willing to help with that effort.

Sec 4.2: Do we need to describe what we mean by "skeleton" entity?  Or 
can we just say "minimal"?  I haven't looked to see if RFC5545/46 use 
either term.

Sec 5: Do we want to create an IANA registry for STATUS values?

Sec 8.5: This should say that the access point supports the protocol as 
specified in Sec 4.

Appendix A: Do we want to solicit input from HTTPBIS now or wait for 
IESG to kick it back?  I don't think IESG will approve a doc with Open 
Issues.

--
Kenneth Murchison
Senior Software Developer
Fastmail US LLC