On 10/01/11 18:49, Richard Jones wrote:
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.
I'm still unclear why there is a need to combine the content type ("application/zip; q=1.0") with the data encoding ("METSDSpaceSIP; q=1.0")
Can't you say "(1) I only deal in .tgz content, and (2) you can package whatevers within that content as 'Foo', 'Bar', or even 'Acme::WhiteSpaceEncoded'"
-- Ian Stuart. Developer: Open Access Repository Junction and OpenDepot.org Bibliographics and Multimedia Service Delivery team, EDINA, The University of Edinburgh. http://edina.ac.uk/ This email was sent via the University of Edinburgh. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
