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

[nelkins alan <[e-mail]>]

Looks good.


Sent from Yahoo Mail for iPhone


On Wednesday, June 1, 2022, 9:05 PM, Bron Gondwana <[e-mail]> wrote:


#yiv0639548324 p.yiv0639548324MsoNormal, #yiv0639548324 p.yiv0639548324MsoNoSpacing{margin:0;}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]


_______________________________________________
Jmap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jmap