> On Apr 20, 2015, at 9:41 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Santiago
>
> Please see comments below
>
> On 20/04/15 14:22, Santiago Pericas-Geertsen wrote:
>>
>>> On Apr 20, 2015, at 9:01 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>
>>> Hi Santiago
>>>
>>> I can not comment on the former as we only have an issue reported by a user and hence I can not give a 100% confirmation, but in a nutshell, it is both.
>>>
>>> It is both, but ultimately it is important that the spec is clear on the use of 'q' and 'qs'. Otherwise the users will start misusing the *response* content-negotiation primitives for affecting the resource method selection using (Content-Type + @Consumes) as opposed to (Accept + @Produces).
>>>
>>> Obviously, if the users start using ';qs' on Consumes then they will want to use 'q' on Content-Type but
>>>
>>> Content-Type: text/bar;q=0.7
>>>
>>> does not work in the HTTP land...
>>>
>>> Technically it is easy enough to update the code to do the same process for (Content-Type + @Consumes) where 'q' and 'qs' are checked. But IMHO the spec should do the right HTTP-centric fix.
>>
>> Ok, I will follow up with the TCK team on the test issue.
>
> Thanks.
The TCK test has been excluded.
>
>>
>> As for the spec, I never felt it was confusing on the use of q and qs. Perhaps you can suggest some text to be added to clarify this?
>>
> What about in 3.7.2 Step 3.b, instead of
>
> (b) ... Let a client media type be of the form n/m;q=v 1 , a server media type ...
>
> do
>
> (b) ... Let a client (Accept) media type be of the form n/m;q=v 1 , a server (Produces) media type ...
I'll add some clarification like that.
-- Santiago