Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 21, 2019 at 09:11:40AM +0000, Alexey Melnikov wrote:
> Hi Benjamin,
> Thank you for your extensive comments.
> 
> In this email I will concentrate on [most of] your DISCUSS points:
> 
> > On 21 Feb 2019, at 05:27, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > There's a lot here, and I was not reading in the best of environments,
> > so it's quite possible that I am just confused or missed something while
> > reading.  On the whole, this document is well-written and gives me a
> > good picture of how things work.  That said, there are still some places
> > where it looks like we may need to have some discussions...
> > 
> > This document (twice) has a MUST requirement for HTTP over TLS, which
> > seems to exclude any future usage of HTTP/3 over QUIC.  (It's also
> > probably not needed to repeat the normative requirement in two places; I
> > noted both in the COMMENT section.)
> 
> I think requiring a specific version of HTTP and underlying transport is right. Future versions of HTTP and different transports like QUIC are different mappings and I think would need a separate document, even if a short one.
> 
> Having said that, if you can show some specific wording that would address your concern, the WG should consider.

My original thought was something about "MUST use TLS transport or
transport that provides equivalent cryptographic protections", but that's
subject to interpretation.  Is there a reason why we can't just require the
https:// scheme?  While I haven't been following as closely as I would
like, my understanding was that QUIC's HTTP/3 would continue to use that
scheme.

> > Section 1.6.2 asserts that "all data belong to a single account".  And
> > yet, we seem to have PushSubscription objects in Sections 7.2.1 and
> > 7.2.2 that disclaim any relationship to an account, which seems
> > internally inconsistent.  It's also unclear to me from the text in the
> > latter sections what mechanism is used to determine whether a given
> > request is authorized to see a given PushSubscription object.  Is it
> > supposed to be based on the authentication credentials to the API
> > service directly, or a user abstraction, or something else?
> 
> Editors should reply to this.
> 
> > 
> > Section 5.3
> > 
> >   Some records may hold references to other records (foreign keys).
> >   That reference may be set (via create or update) in the same request
> >   as the referenced record is created.  To do this, the client refers
> >   to the new record using its creation id prefixed with a "#".  The
> >   order of the method calls in the request by the client MUST be such
> >   that the record being referenced is created in the same or an earlier
> >   call.  The server thus never has to look ahead.  Instead, while
> > 
> > I think this means you need to specify what order the server does the
> > create, update, and destroy lists in -- that is, that all creates are
> > done before all updates, etc..
> 
> I think you misunderstood: the order is important and all operations are performed in the order specified (so there is no internal reordering to be done by the server). If the client references something that wasn't yet created, it is a client error and will be reported accordingly.

Okay, so the client gets to pick which order the 'create', 'update', and
'delete' arguments appear, and the server must do everything in order, both
the order within the contents of the 'create' array and amongst
create/update/delete?  That is certainly deterministic enough for me,
though I didn't see much in the text to give the impression that the
order in which arguments appeared was relevant, especially since we claim
to be using I-JSON and RFC 7943 says "the order of object members in an
I-JSON message does not change the meaning of an I-JSON message".

> > Section 5.5
> > 
> > The Unicode Collation Algorithm (<http://www.unicode.org/reports/tr10/>
> > is not listed in the IANA collation registry for internet application
> > protocols; since the session object limits the collationAlgorithms to
> > those in the registry, at present, it is not permitted to use that
> > collation algorithm.  It would seem that this document should stimulate
> > the registration of that collation algorithm in some fashion (whether by
> > explicitly doing so in its IANA Considerations or otherwise).
> 
> I think this is fair. 
> > 
> > Section 7.1
> > 
> >   o  *changed*: "Id[TypeState]" A map of _account id_ to an object
> >      encoding the state of data types that have changed for that
> >      account since the last StateChange object was pushed, for each of
> > 
> > I don't see how these semantics provide the properties stated in Section
> > 7, "[i]t doesn't matter if some push events are dropped before they
> > reach the client; it will still get all changes next time it syncs."  In
> > particular, if the client misses a state change for the CalendarEvent
> > type, and then no other changes that affect CalendarEvents occur, the
> > client will remain unaware of the changes to CalendarEvents, even if
> > other push notifications for other types come in.  Am I misunderstanding
> > one or more of the behavior or stated guarantees?
> 
> I think you do. Clients will periodically poll. Once they do, they will be able to recover all missing notifications due to use of sequence numbers.

Er, you think that I do understand correctly?
We should probably mention the expectation of polling (as well as
subscribing to pushes), then.

-Benjamin