Re: Tsvart last call review of draft-ietf-jmap-core-12

Allison Mankin <allison.mankin@xxxxxxxxx> · Sun, 30 Dec 2018 08:22:09 -0500

Bron,

Thanks for detailing that and explaining where to find it in the draft.

Best wishes,

Allison

On Fri, Dec 28, 2018 at 11:09 PM Bron Gondwana <brong@xxxxxxxxxxxxxxxxx> wrote:
Hi Allison,

The blob deliberately isn't validated at upload time, so that it can be used by any Foo/import function or referenced in the generation of a later object of any type.  For example I uploaded a PDF file as a blob:

Content-Length: 312597
Content-Type: application/pdf

And my server returned the details I gave:

{
  "expires":"2018-12-30T03:57:18Z",
  "type":"application/pdf",
  "size":312597,
  "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412",
  "accountId":"uac7641b2"
}

But that type field isn't saved on the server at all, it's just there in the response (as can be seen in the "Downloading" section, where "type" must be included in the request URL pattern and filled by the client)

When that blob gets later used as an email attachment, the interpretation of the blob is given by the client as part of the bodyStructure (see the draft-ietf-jmap-mail document for how Email/set uses uses blobs as part of email creation if you're interested):

{
  "blobId":"Gb5eb763ad75e77101226181e01bb5c20f6aaf412",
  "cid":null,
  "disposition":"attachment",
  "name":"certificate.pdf",
  "size":312597,
  "type":"application/pdf"
}

And then the server uses that to generate an appropriate representation of the object that's being created:

--fa073057ee4b4ff58e7209f66d32cd7a
Content-Disposition: attachment;filename="certificate.pdf"
Content-Type: application/pdf; name="certificate.pdf"
Content-Transfer-Encoding: BASE64

[...]
--fa073057ee4b4ff58e7209f66d32cd7a--

Cheers,

Bron.

On Sat, Dec 29, 2018, at 05:30, Allison Mankin wrote:
Reviewer: Allison Mankin
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.

This standards track specification is in good shape from a transport point of
view. Topics considered in this assessment were its discovery mechanism, its
support of tools for denial of service and rate control issues on both the
server and clients side, its ordering and data flow for the allowed disparate
client endpoints, and its transport mapping, which is mandatory HTTPS.

One question that is referred to other areas is what recommendations would be
given (or what spec referenced) for validation of uploaded blob objects (it
looks like the flow control for these is fine).

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@xxxxxxxxxxxxxxxx