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

[Bron Gondwana <[e-mail]>]

I've finally addressed all these (I hope) in revision 12 which I just uploaded.

I've also added `digest:<algorithm>` support based on another email to the list.  It's optional (the server has to opt-in by specifying the algorithms it supports).

I expect to have to do another revision fleshing out the `digest` section, including security considerations and advice to both clients and servers regarding how to use it.

Bron.

On Tue, Apr 19, 2022, at 16:14, Neil Jenkins wrote:
> 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.
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]