Re: [Tsv-art] Tsvart last call review of draft-ietf-jmap-core-12

["Bron Gondwana" <[e-mail]>]

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
> [e-mail] 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
 [e-mail]