[Jmap] Roman Danyliw's Discuss on draft-ietf-jmap-blob-17: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-jmap-blob-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.2.1. The example has a few easy to fix issues:

--  Typo in JSON.  Missing comma between array elements in “ids”
OLD
      "ids" : [
        "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e"
        "not-a-blob"
      ],

NEW
      "ids" : [
        "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e",
        "not-a-blob"
      ],

-- The second request (“R2”) sets properties of “data:asText” and
“data:asBase64”.  However, the response only returns a value for “data:asText”.
 Shouldn’t it have returned the same data in both formats?

** Section 5
   If a server might sometimes return all names empty rather than
   putting a blobId in the notFound response to a Blob/get, then the
   server SHOULD always return the same type of response, regardless of
   whether a blob exists but the user can't access it, or doesn't exist
   at all.  This avoids leaking information about the existence of the
   blob.

Can these behaviors be clarified?

-- If this text introducing a new, normative behavior that if a blobId is not
found or the user isn’t authorized, a get query response could just be both an
empty “list” and “notFound”?  I don’t see that described elsewhere.

-- The consistency in behavior for not found and or not authorized makes sense
exactly for the reason described.  Therefore, why the SHOULD?  What would be
the circumstances where leaking the existence of the blob is acceptable?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Shawn Emery for the SECDIR review.

** Section 3.1.  supportedTypeNames.  Are the values in this array
standardized? If so, can a pointer be provided?

** Section 3.1.  supportedDigestAlgorithms.  Is the order of the algorithms in
the array significant?  For example, is the first array element the one most
strongly preferred?

** Section 4.2.2

  G2: since data:asText was explicitly selected, does not attempt to return a
  value for the data, just isEncodingProblem for b1.

This text is would benefit from more clarity as b2 data is successfully
returned.

** Section 4.3

   If a blob is not visible to a user at all, then the server SHOULD
   return that blobId in the notFound array, however it may also return
   an empty list for each type name, as it may not be able to know if
   other data types do reference that blob.

-- What does is mean for a blob to be “not visible to a user at all”.  Is that
the same as the user is not authorized to access a blob?

-- The construction of the normative text is awkward.  “the server SHOULD <do
x>, however it may also <do y>”.  Are both activities intended governed by the
“SHOULD”?

** Section 5
   The server MUST NOT trust that the data given to a Blob/upload is a
   well formed instance of the specified media type, and if the server
   attempts to parse the given blob, only hardened parsers designed to
   deal with arbitrary untrusted data should be used.

Isn’t this a situation of “_when_ the server attempts ...” rather than “_if_
the server attempts ...” to parse the un-trusted input?  The document mentions
base64 to text decodes and suggested automated media detection (in Section 4.1).

** Editorial

-- Section 3.1.  Typo. s/Alogirthms/Algorithms/
-- Section 4.  Typo. s/specfication/specification/
-- Section 4.1.  Editorial.  s/or detected from content/or detected from the
content by the server/ -- Section 4.1.  Typo. s/sucessful/successful/