---------- Forwarded message ---------- From: Robert D. Sanderson <rsander...@lanl.gov> Date: 11 January 2011 05:05 Subject: Re: content negotiating for package formats To: Graham Triggs <grahamtri...@gmail.com> Cc: Richard Jones <rich...@oneoverzero.com>, techadvisorypa...@swordapp.org
> On 7 January 2011 17:36, Richard Jones <rich...@oneoverzero.com> wrote: >> 2/ Define an extension to the application/zip mimetype which allows us to >> specify the package format as a parameter. So we could, for example, specify >> a parameter "swordpackage" which can take the URI of a package format, and >> construct mimetypes like >> >> application/zip;swordpackage=uri:METSDSpaceSIP >> (see http://tools.ietf.org/html/draft-ietf-atompub-typeparam-00) >> >> The questions here are: is this a legitimate extension/approach, would this >> break anything else on the web in general, and is it naive to assume that >> all packages have the top level mimetype of application/zip? First of all, no, it's not legitimate to invent new parameters for existing mime types. RFC 2048, Section 2.2.3 ... the names, values, and meanings of any parameters must be fully specified when a media type is registered in the IETF tree ... http://www.faqs.org/rfcs/rfc2048.html So it's not legal to create a parameter swordpackage and attach it to the existing application/zip. > More generally, the HTTP specification defines the accept headers as: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Note that the extension parameter here is for the header, not the mimetype. The BNF allows the accept-extension rule ONLY after the mandatory q value in accept-params. > Which means using Accept-Encoding in this way is potentially problematic, > but Accept does have provision that would make this use legitimate. Like mime types, content encodings also have a registry. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html section 3.5 Basically, there are two routes to avoid breaking the rules, neither easy: 1. Register new Mime Types for every packaging format. 2. Use an x- header and eventually write an RFC to standardize it. We looked at this in both SRU (eg what it would take to have a wrapper format and an internal format: SRU vs Atom, wrapping Simple DC vs METS) and in conjunction with the digital format registry for preservation purposes. So my recommendation would be to go with a new x- header, and if/when the community has implemented it, take it to an RFC. -- Rob ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
