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

[Allison Mankin <[e-mail]>]

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