Adding extension for attachments

[glennblock]

No description provided.

[mamund]

@glennblock When does the client make an "attachment response" request? how does it know to change the accept header to "multipart/mixed"? or even know that a multipart/mixed is coming?

[glennblock]

If we go with my suggestion that I just made, the client would know if they get a standard CJ response that has "attachment" fields.

[mamund]

not a fan of having to "look inside" in order to sort out content-type
details. wonder if there is something we're missing. HTML doesn't have this
response issue, right?

in fact, why are we offering up a Cj collection as a multipart at all?

seems what most client would expect would be a Cj collection response with
items and maybe one of the data's link element is marked as an attachment
(render="attachment") which means you can download this element (instead of
rendering it as a "link" item or an inline image). clients that don't
understand the [render="attachment" ] directive can render the link as a
simple render="link"

On Sun, Oct 12, 2014 at 2:12 PM, Glenn Block notifications@github.com
wrote:

In attachment.md:

+```
+## Receving attachments
+A client may also receive a response that contains attachments. In these cases the response media type will be "multipart/mixed" containing parts for a collection+json document as well as attachments.
+
+### Parts
+* The first part in the document will be a CollectionJson document. The document will contain pointers back to the attachments in the response.
+* All attachment fields in the data element must have a value set to the name in the content-disposition header of the corresponding part.
+* The document part must have a "name" of "document" as it's content-disposition header
+* All additional parts will be attachments which relate to the document.
+* Each attachment must have a "name" as part of the content-disposition header.
+
+### Attachment Data field
+The attachment field in the response indicates that this item has an associated attachment. The value of the attachment matches the filename in the content-disposition header in one of the parts.
+
+### Example
+Below is an example of a response containing attachments. The first part is a document which contains the list of contacts where each contact has an avatar with an attachment field. Then there are additional parts which are the actual attachments. Each attachment's filename corresponds to the value of the attachment field for the item in the CollectionJson document.

If we go with my suggestion that I just made, the client would know if
they get a standard CJ response that has "attachment" fields.

—
Reply to this email directly or view it on GitHub
https://github.com/collection-json/extensions/pull/7/files#r18748997.

[glennblock]

Well I as offering up multipart to allow returning attachments using the standard attachment mechanism of HTTP. However I see your point. Having a link with a render="attachment" may work fine.

[glennblock]

Another idea would be using rel="enclosure" from atom.

"The value "enclosure" signifies that the IRI in the value of the
href attribute identifies a related resource that is potentially
large in size and might require special handling. For atom:link
elements with rel="enclosure", the length attribute SHOULD be
provided."

[mamund]

maybe "download" is the right word for render="" in the responses.

[mamund]

https://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-05#section-5.2 says content-Disposition header MUST appear, but 2388 is vague. any reason we shouldn't just adopt the new I-D language here?

[mamund]

@glennblock

sorry i've let this languish so long. is this extension still interesting? is the current document healthy/happy?

should I merge it in or just close it as "dead" for now?

[graste]

Looks useful to me. Not that I have a concrete project in mind though. :-)