---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 12 January 2011 09:52 Subject: Re: content negotiating for package formats To: Graham Klyne <g...@ninebynine.org> Cc: techadvisorypa...@swordapp.org
Hi Graham, On 11/01/11 19:05, Graham Klyne wrote: > > Richard - a small thing: rather than using the X- header convention, > just pick a suitable name and request provisional registration via IANA, > per [1]. This avoids messing around if the new header goes standards > track. And, anyway, X- headers don't have the same reserved for > experimentation status that applies for email headers. > > [1] http://tools.ietf.org/html/rfc3864 That's an interesting idea. Shouldn't we do this with all SWORD headers, then, though? Probably this is a decision that we need to make as a project as to whether we go right away towards something which can be put onto a real standards track in the future, or whether we stick with X- headers. I'm in favour of being able to go standards track, but there are a few things which nag at me, including: 1/ the amount of time required to do the work to even to provisional registration of the headers 2/ backwards compatibility with SWORD 1.0. If we drop, say, X-On-Behalf-Of and go for just On-Behalf-Of we'd be breaking the back compat or placing the onus on the server to interpret both headers. What do you think? > I'm also wondering about your combination of content-type and internal > packaging format. The media feature description framework [2] was > intended to capture this kind of combination of features in a more > structured fashion. Thus, I would imagine something like: > > Accept-media-features: > (| (& type="application/zip" package=METSDSpaceSIP);q=1.0 > (& type="application/atom+xml" atomtype=entry package=AtomSIP);q=0.8 ) > > This would require IANA registration of the new header field, and a new > media features called "package" and "atomtype", per [4]. Feature "type" > is already registered [3]. > > [2] http://tools.ietf.org/html/rfc2533 > > [3] http://tools.ietf.org/html/rfc2913 > > [4] http://tools.ietf.org/html/rfc2506 This seems like the "proper" way to do it, and just comes with the same caveats as above. What is the status of this RFC? Are we safe to go ahead and use it? (incidentally, we wouldn't need to register atomtype, as the param type=entry is part of the mimetype already). I'd be interested in the rest of the advisory panel's and project team's opinions on this, as this may well define the way that I work for the duration of the project. Cheers, Richard > > Richard Jones wrote: >> >> Hi Folks, >> >> Thanks, this is really great stuff. >> >> On 10/01/11 16:05, Robert D. Sanderson wrote: >>>> >>>> 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. >> >> Ok, it sounds like this option then is simply out altogether. >> >>>> 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. >> >> I have to confess to having overlooked the accept-extension rule, as >> there wasn't an example of usage in that document. Can you give us an >> example as to how that is used? >> >>>> 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. >> >> It's looking like a separate header is the way to do this, with the >> following couple of options immediately standing out: >> >> Accept-Features (or X-Accept-Features if it isn't sufficiently official) >> X-Packaging >> X-Accept-Packaging (which I just made up for the purposes of this >> discussion) >> >> Some comments on these: >> >> Accept-Features >> Having looked at the document [1] (thanks Graham (K)) it looks like it >> would give us the leeway that we need to describe requirements while >> ensuring that Graham (T)'s concerns (which I share) about matching up >> package format requirements with mimetypes would be dealt with. On the >> other hand, this document is 12/13 years old and the header has not >> made it into the HTTP content negotiation documentation and is >> significantly different in format to all the other Accept- headers. It >> could also be a substantial effort for servers to implement the full >> requirements of this header. >> >> X-Packaging >> I'm against using this in this way as it is already used to alert the >> server during POST as to the package format that is being supplied. >> The format of the header for content negotiation would have to be >> totally different to this usage: a list of package formats and q >> values for example, rather than a single definitive URI. I see scope >> for confusion. >> >> X-Accept-Packaging >> Given my concerns about X-Packaging and the comments above about >> Accept-Feature, perhaps there is a middle ground that we can define >> which does something more minimal with just mimetypes, package formats >> and q values in a way similar to having a mimetype that has added >> parameters. >> >> For example: >> Accept: application/zip; q=1.0, application/atom+xml;type=entry;q=0.8 >> >> X-Accept-Packaging: application/zip;{package=METSDSpaceSIP};q=1.0, >> application/atom+xml;type=entry;{package=AtomSIP};q=0.8 >> >> Or some other suitably neat and unambiguous serialisation which is in >> line with how the other Accept- headers work and also gives us the >> information we want in a totally definitive mimetype<->package format >> way. This could be supplied alongside the usual Accept header so that >> clients which can't generate the X-Accept-Packaging header can fall >> back easily to the usual content negotiation route. >> >> Thoughts? >> >> Cheers, >> >> Richard >> >> [1] http://www.ietf.org/rfc/rfc2295.txt >> >> > > ------------------------------------------------------------------------------ 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
