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

[Michael Douglass <[e-mail]>]

And here's my very belated response...

Just published 08 with these changes

On 11/10/22 12:41, Bron Gondwana wrote:
> 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.
>
Replaced this section with these paras

    If no Sync-Token header field is supplied or the token is invalid the
    server MUST respond with a full set of data and SHOULD set the
    Preference-Applied header field and a new Sync-Token header field
    value.

    Otherwise, (the token is valid), it SHOULD return with a set of
    changed entities and MUST 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.
>
Changed to MUST
> ---
>
> 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.
>
Changed to MUST
> ---
>
> 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
It should have been sync-token not accept. Changed
>
> ---
>
> *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.
Done
>
> ---
>
> 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.
>
Probably not
> ...
>
> 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]
>
>