Re: [Jmap] I-D Action: draft-ietf-jmap-blob-11.txt

[Neil Jenkins <[e-mail]>]

A few comments on this draft:

It seems to use the type signature conventions of the core spec, but doesn't explicitly say this in the "Conventions Used in this Document" section. Presuming this is the intention thoughm the type for `supportedTypeNames` should be `String[]|null`

> *4.1 The result is the same as for Foo/set in RFC8620* […]

I think this could be clearer. Specifically, it's not the same as a standard `/set` in that there are no state strings in the response (as well as no updated/destroyed of course).

> *NOTE: Servers MUST set the creationIds value to the blobId returned in any successful Blob/upload's created response to allow backreferences, as that is the main purpose of this extensions.*

Again, I feel like this could be clearer. It's really saying an entry must be *added* to the `createdIds` map in the request for each successful upload, so the blob id may be used via back reference in a subsequent method call.

> data: `[DataSourceObject]`

Should be `DataSourceObject[]`. (There are a number of other instances like this in the spec; I won't keep listing them here)

> Exactly one of:
>  * data:asText: String|null
>  * data:asBase64: String|null

These are missing descriptions to specify exactly how they are to be interpreted.

> or a blobId source:
>  * blobId: Id
>  * offset: UnsignedInt|null (MAY be zero)
>  * length: UnsignedInt|null (MUST NOT be zero)

Why must length not be zero? You are allowed a zero length blob. Also

> If `null` then length is the remaining octets in the blob.

So what if there are zero octets remaining?

> 4.1.2. Blob/upload complex example 

Still has properties from `/set` in the responses that should not be there.

> 6.3. Creation of "JMAP Data Types" Registry 

There's no documentation here on how to add or modify entries in this registry in the future.

Cheers,
Neil.