Reviewer: Jaime Jimenez Review result: Ready with Nits 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
