Last Call Review of draft-ietf-jmap-blob-17
review-ietf-jmap-blob-17-artart-lc-jimenez-2022-12-14-00

I am the assigned ART-ART reviewer for this draft and I apologize for the delay.

To my understanding this document defines a data structure for encapsulating a
"blob" of data to be transferred using a JMAP API over HTTP. The document
defines the creation, retrieval and look up for blobs.

In my opinion this draft is ready to be published. I found some nits and
comments that the authors may take into consideration.

Major issues:

Minor issues:
- Somewhere in the draft I would expect an indication that the request MUST be
of type "application/octet-stream". - I am not too familiar with JMAP but to my
understanding for any HTTP API you would need the URL for the resource path to
be well-defined. I assume that the definition of how the request URL is
constructed is out of the scope of this document and left to API
implementations or defined in RFC8620. Similarly how responses like
"notCreated" are carried over HTTP (e.g., 500 Error or similar) are to be
defined elsewhere, right? If they are defined on that RFC or elsewhere, it
might be good to add a reference in the document. If I am completely off, I
apologize cause I do not know the insides of JMAP well. - Another comment is
that the blob itself seems to carry CRUD operations but I only saw examples of
create or "Blob/upload" and read or "Blob/get". The draft indicates that blobs
"can't be updated or deleted" so I am wondering then if it is up to the server
to remove them over time and on which basis as the draft does not seem to
mention that. For example after a "blob lifetime", based on memory usage or
other. - The Lookup operation might be underspecified IMO, as it is currently
stating: "The definition of reference is somewhat loosely defined, but roughly
means "you could discover this blobId by looking inside this object"". I think
that might not be clear enough for a developer implementing this but I leave it
to the group/authors to decide.

Edits-nits:
The document contains apostrophes (can't, don't...). My understanding (which
might be mistaken) is that standards should not be coloquial, so maybe I would
expand those.