Re: [calsify] Working Group Last Call: draft-ietf-calext-subscription-upgrade-07

[Bron Gondwana <[e-mail]>]

Here's my shepherd review as promised!

*Substantive comments:*

The first "SHOULD" here should be a "MUST".  There's no reasonable world in which anything else is legitimate there other than an error if the server isn't working properly, and "SHOULD" isn't for hedging against server failures.

The second "SHOULD" is legit because a server could be reverted to an old version which doesn't support this and just returns the resource without understanding the headers.

   If no Sync-Token header field is supplied the server SHOULD respond
   with a full set of data.  Otherwise, if the token is valid, it SHOULD
   return with a set of changed entities.

---

This is fuzzy.  Is it SHOULD?  Is it MUST?  I'd probably say MUST for the second case and SHOULD for the first, following the logic from above.  If you're sending a partial then you MUST put the Preference-Applied, and you SHOULD if sending the whole resource.

   In both cases the server should set the Preference-Applied header
   field and a new Sync-Token header field value.

---

Again, this should be a MUST.  The client MUST respond to a 409 error by starting from scratch.  Anything else doesn't make progress.

   The client SHOULD respond to this error by restarting the interaction
   from scratch, i.e. retrieve the full set of data then poll for
   updates.

---

This seems like an interop pain - given that the alternative is just fetching the whole thing.  I would at least gate this with "If the prefer header was set" as above, and then say that if the server limits the response then the behaviour MUST be as if the client had provided a preference for that size.

   A server MAY choose to limit the response size.  The behavior SHOULD
   be as if the client had provided a preference for that size -
   allowing the client to retrieve the full set of data in batches.

---

Do you mean `sync-token = DQUOTE URI DQUOTE` here?  And maybe `accept /= sync-token` if there's an ABNF being extended

6.  Header Field: Sync-Token

   This specification defines a new header field Sync-Token for use by
   the enhanced GET method.

       Accept = DQUOTE URI DQUOTE

---

*Open Issues**:
*

Confirm correct use of Vary header and remove the open issues section.

---

*Nits:**
*

There's probably a missing comma after mechanism here...

   The use of subscription upgrade may help reduce load on servers, but
   perhaps more importantly it allows mobile devices to use a more
   efficient update mechanism reducing data transferred and presumably
   improving battery life.

---

Should VARY be all caps?

   To enable proper caching of responses the server SHOULD provide a
   VARY header field in responses that names the Prefer and Sync-Token
   header fields along with any other that are appropriate.

...

I think that's it :)

Thanks,

Bron.

On Mon, Oct 24, 2022, at 20:33, Bron Gondwana wrote:
> Hi all,
> 
> This email starts a 2 week working group last call for https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ - my fault that this wasn't done ages ago but I can't see emails to the effect and if they were, it's been a while!
> 
> Please post any comments / queries / objections to this thread.  If nothing, I'll push the buttons at IETF115 in a couple of weeks and finally ship this thing to the IESG (as our milestones suggest was going to have happened in August)
> 
> Thanks,
> 
> Bron.
> 
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
> 
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]