Hi Christian,

the RESTXQ spec. or/and our implementation may need to be extended to support subtypes. Reg. your use case.. Do you depend on the support of subtypes, or would it "just" make life easier?

Aren't subtypes already supported by RESTXQ? I was talking about the parameters of a media type which is the "type=entry" part in the following media type:

application/atom+xml;type=entry

I've used such parameters in "produces" as in

%rest:produces("application/atom+xml;type=entry")

I could omit this annotation but what I like in specifying this annotations is that it will not map to media types that would not be understood such as "application/foo" for that URI. I would like to find a generic way of returning a 406 (not acceptable) eventually. That is what rfc2616 suggest:

If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

But what I understand from rfc2046 is that the server should map according to media type and subtype and not from parameters:

MIME implementations must also ignore any parameters whose names they do not recognize.

So I guess we could still use the full media type string along with the parameters but that they (the parameters) are ignored by RESTXQ for the mapping of the request to a function. Then in the response function we could access the parameters array to figure out the additional constraints applicable by the presence or not of some parameters.

-- Philippe