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

[Benjamin Kaduk <[e-mail]>]

On Tue, Mar 12, 2019 at 10:14:53PM -0400, Neil Jenkins wrote:
> On Sat, 9 Mar 2019, at 06:44, Benjamin Kaduk wrote:
> > > > An authenticated client can fetch the JMAP Session object with
> > > > details about the data and capabilities the server can provide as
> > > > 
> > > > nit: maybe this is "a JAMP session object" with the indefinite article?
> > > 
> > > I used the definite article here because the client is authenticated, and therefore has access to one specific JMAP session object associated with those credentials.
> > 
> > Would that indicate "their"/"its", then?
> 
> I'll make it *the *user's* JMAP session object.*
> 
> > > > The 'prefixed with a "#"' laguage seems like it has some potential for
> > > > confusion; is it better to write this like "the first character of the
> > > > creation ID MUST be octothorpe ('#')"?
> > > 
> > > The # is not part of the creation id. References to a creation id may be used in a context where an id is expected by prefixing the creation id with a #. Since this is not a valid character in an id, it is easy to determine that this must be a creation reference. I have added a reference at this point to the /set definition where this is explained in more detail.
> > 
> > That will help, though I'm not sure exactly how much.
> > Looking at this again, I think the biggest thing that confused me on my
> > first read is that I didn't internalize that creation ids and
> > ResultReferences are different things (since they both use the magic "#"
> > prefix), and I was trying to reconcile them into the same bucket.
> > So maybe when ResultReference is introduced there could be a note about how
> > "the ResultReference performs a similar role to that of the creation id, in
> > that it allows a chained method call to refer to information not available when
> > the request is generated. However, they are different types and not
> > interchangable; the only commonality is the octothorpe used to indicate
> > them". But, maybe I'm unusual for being confused about this and it's not
> > worth the extra text.
> 
> I don't think it hurts to clarify; I'll add this in.
> 
> > > > Section 5.4
> > > > 
> > > > o *destroyFromIfInState*: "String|null" This argument is passed on
> > > > as the "ifInState" argument to the implicit _Foo/set_ call, if
> > > > made at the end of this request.
> > > > 
> > > > This is "the Implicit _Foo/set_ call that effectuates the destruction of
> > > > the original", right?
> > > 
> > > Yes.
> > 
> > I think I was asking for a little more text here, basically to reiterate
> > that the Foo/set call is a deletion call.
> 
> OK, I'll clarify this.
> 
> > > > o *fromAccountId*: "Id" The id of the account emails were copied
> > > > from.
> > > > 
> > > > o *accountId*: "Id" The id of the account emails were copied to.
> > > > 
> > > > I assme the "emails" are copy/paste bugs.
> > > 
> > > Yes, good spot. I've fixed this.
> > > 
> > > > Section 7.2
> > > > 
> > > > o *deviceClientId*: "String" (immutable) An id that uniquely
> > > > identifies the client + device it is running on. The purpose of
> > > > this is to allow clients to identify which PushSubscription
> > > > objects they created even if they lose their local state, so they
> > > > can revoke or update them. This string MUST be different on
> > > > different devices, and be different from other vendors. It SHOULD
> > > > 
> > > > What's the first vendor that's the basis for comparison?
> > > 
> > > Sorry, I'm not quite sure what you're asking here.
> > 
> > I think my fundamental confusion here is about where the device ID is
> > coming from -- is this supposed to be something like the serial number or
> > IMEI number from my phone, that is a fixed and permanently bound to a
> > specific device (and not changeable)? I think we delved into related
> > topics for Alissa's Discuss, but not quite into this aspect of things. If
> > I start talking about "vendors", is there some implication that the
> > identity of the current device's vendor is input to the
> > deviceClientId-generation process (whether explicitly or implicitly via a
> > manufacturer prefix in some other identifier)? So the literal answer to my
> > question here is something like the "first vendor" is the manufacturer of
> > the device being identified, or the author of the app generating this
> > specific deviceClientId.
> > 
> > Even in the current text (-16), I wonder if "a device id" is quite enough,
> > as opposed to "a unique identifier associated with the device where the
> > JMAP client is running" or similar.
> 
> Yes, this should be clearer. I have rewritten this to be:
> 
> *This string MUST be different on different devices, and be different from apps from other vendors. It SHOULD be easy to re-generate, not depend on persisted state. **It is RECOMMENDED to use a secure hash of a string that contains:*
> *
> *
>  1. *A unique identifier associated with the device where the JMAP client is running, normally supplied by the device's operating system.
> *
>  2. *A custom vendor/app id, including a domain controlled by the vendor of the JMAP client.
> *
> *
> *
> *To protect the privacy of the user, the deviceClientId id MUST NOT contain an unobfuscated device id.*

Thanks, this is a big help.

> > > > Section 8.3
> > > > 
> > > > DNS SRV-based autodiscovery seems the only type of autodiscovery
> > > > available that is susceptible to the attack described here; you should
> > > > probably just state that explicitly.
> > > 
> > > OK, will do.
> > > 
> > > > Section 8.4
> > > > 
> > > > While true, 8529's security considerations are pretty sparse; we could
> > > > say more here about not overscanning, limiting string length, being
> > > > strict about tokenization, etc.
> > > 
> > > Do you have any suggested text?
> > 
> > As for any serialization format, parsers need to thoroughly check the
> > syntax of the supplied data. JSON uses opening and closing tags for
> > several types and structures, and it is possible that the end of supplied
> > data will be reached when scanning for a matching closing tag; this is an
> > error condition and implementations need to stop scanning at the end of the
> > supplied data.
> > 
> > JSON also uses a string encoding with some escape sequences to encode
> > special characters within a string. Care is needed when processing these
> > escape sequences to ensure that an escape sequence is fully formed before
> > the special processing is triggered, with special care taken when the
> > escape sequences appear adjacent to other (non-escaped) special characters
> > or the end of data (as in the previous paragraph).
> > 
> > If parsing JSON into a non-textual structured data format, implementations
> > may need to allocate storage to hold JSON string elements. Since JSON
> > does not use explicit string lengths, the risk of denial of service due to
> > resource exhaustion is small, but implementations may still wish to place
> > limits on the size of allocations they are willing to make in any given
> > context, to avoid untrusted data causing excessive memory allocation.
> 
> Great, thanks, I'll add that in.
> 
> > P.S. I appreciate the separate "description" column for the error registry
> > in the -16, but the formatting of the current table is basically
> > unreadable. I had to go find
> > https://github.com/jmapio/jmap/commit/3f4b7f83c99596a553bd81324c092516a9babbcf#diff-3004124a0560c91bfc79eb996bd81433
> > to get something useful to look at.
> 
> Yes, I'm hopeful the RFC editors may help with this; I'm not sure what the best approach is. (Just as an FYI, I also publish the latest version of the spec in a more readable HTML format at https://jmap.io/spec-core.html and https://jmap.io/spec-mail.html.)
> 
> I'll post a -17 when submissions reopen and hopefully this can progress through to join the mail spec in the final editing stage.

Alexey should be able to approve a manual posting by the secretariat during
the blackout; the usual reason for denying draft submission (so that
everyone can read drafts in preparation for meeting sessions) doesn't
really apply for drafts in this stage.

Thanks again for all the updates!

-Benjamin