Adding extension for attachments

I am open to an alternative suggestion if you can think of one.

On Mon, Oct 13, 2014 at 3:33 PM, Mike Amundsen <notifications@github.com>
wrote:

> In attachment.md:
>
> > +
> > +* [1341] (http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) - The Multipart Content-Type
> > +* [2388] (http://tools.ietf.org/html/rfc2388) - Returning Values from Forms:  multipart/form-data
> > +* [6266] (http://tools.ietf.org/html/rfc6266) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
> > +
> > +## Write template
> > +A client MAY receive a CollectionJson document containing a Write template which accepts attachments which the client can use to send files.
> > +
> > +### enc-type field
> > +A new _enc-type_ field is introduced on the template element.
> > +* It MUST have a value of "application/json", "application/vnd.collection+json", or "multipart/form-data".
> > +* For templates with attachments, "multipart/form-data" MUST be used.
> > +
> > +### attachment field
> > +A new _attachment_ field is introduced on the data element.
> > +* This field MUST be set to "true" to indicate to the client that this is an attachment.
>
> yes, the attachment field is only valid for data objects when those data
> objects are children of the template object. it is not valid (and should
> not appear) for data objects that are children of item or query objects.
> that's a bummer for parser/validators. not sure there is a way to avoid
> this, but it does bug me.​ so we proly need to say something about what to
> do if/when these show up inadvertently on data objects when these objects
> are not children of the template object. (sigh...)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/collection-json/extensions/pull/7/files#r18799237>.
>