Hi Ian,
On 18/01/11 12:11, Ian Stuart wrote:
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'"
I think that the problem is that you can't guarantee that the list of
content types and the list of packaging types are combinable in a
meaningful way; Graham T's email had an example.
So suppose a server can give you content type A with packaging formats X
and Y, or content type B with packaging format Z:
A + (X or Y)
B + Z
and your content negotiation header says:
Accept: A; q=1.0, B; q=0.8
Accept-Packaging: Z; q=1.0, X; q=1.0
Which combination do you return?
On the other hand, this is a general problem and even within the Media
Feature syntax that Graham K describes in his RFC acknowledges this
effectively limits the use of "q" values to top-level feature sets. So,
you would be limited to content negotiating for:
Accept-Media-Feature: A(X), B(Z), A(Y)
for example; i.e. explicitly declaring your preference of the
combination of content-type and packaging format.
I've spent the last 3 or 4 days looking at the Media Feature stuff in
detail, and I have to confess it does feel like a sledgehammer to crack
a nut. At the moment I'm playing with specifying restricted version of
it to see if we can get the effect that we want without the huge
overhead of a full implementation.
As a consequence, I'm still open to Ian's suggested approach here,
provided that we can decide a) what the new HTTP header should be
called, and b) what the rules for resolving content negotiation
ambiguities as shown above should be.
Cheers,
Richard
