Last Call Review of draft-ietf-jmap-blob-15
review-ietf-jmap-blob-15-secdir-lc-emery-2022-11-06-00

This proposed standards draft specifies an extension to the JSON Meta
Application Protocol (JMAP).  Specifically this draft defines an extension for
creating, identifying, and retrieving "blobs" of data without the need of
utilizing separate roundtrips.

The security considerations section does exist and refers to various ways to
mitigate against attacks related to unsupported data types, unauthorized access
control, blob existence leaks, mismatch between data type and data, and the
fragmentation of data to bypass scanner checks.  I concur with the set of
possible attacks on this extension, though I do have one question on this
sentence:

    The server SHOULD NOT reject data on the grounds that it is not a valid
    specimen of the stated type.

Is there ever a case that one implementation accepts the data that does not
match the specified type and then another implementation assumes that the data
is that of the specified type?  If this is the case then this could lead to
vulnerabilities while parsing said data.

The security consideration section should also initially state something
similar to that of RFC 8621:
   All security considerations of JMAP [RFC8620] apply to this
   specification.  Additional considerations specific to the data types
   and functionality introduced by this document are described [below].

General Comments:

Thank you for the variety of examples, though it would have been easier to read
them if the request and response were in sequence rather than trying to
remember which response went to which request or by scrolling up and down a few
pages to correlate the two.

I'm not for sure I understand the purpose of the Blob/get:properties:digest
function.  Won't the endpoints be able to do this over the datafield for
themselves?

Editorial Comments:

s/of of/of/
s/supportedDigestAlgorithms/supportedDigestAlgorithms:/
s/in future/in the future/