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

["Neil Jenkins" <[e-mail]>]

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.*

> > > 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.

Cheers,
Neil.