On Aug 19, 2008, at 11:16 AM, Reto Bachmann-Gmür wrote:
> Marc Hadley wrote:
>> For 1.0 we fix the q (or qs) value for methods and providers to 1.0
>> so the product is always the same as that specified in the Accept.
> As the q-value is syntactically just an argument to the media-type
> it's hard to forbid it. Would something like the following do?
>
> "This specification does not define how server-side q-values are
> handled, the algorithms described in this specification assume a q-
> value of 1.0 for methods and providers,
I'm in agreement this far.
> implementations MAY use server side q-values to select the best
> available contents, if they to do the interpretation of the Accept
> header SHOULD conform to the interpretation provided by RFC 2616".
>
I'd prefer to defer any support for server-side quality-of-source
until a later revision of the spec. Having different implementations
doing different things is likely to cause application portability
issues.
>>> If multiple media-type result to the same q-value product the one
>>> that is not produced by a provider provided by the implementation
>>> is used.
>>>
>> I don't understand, can you give an example.
> This was an attempt to realize the second requirement of the
> following assertion in the current spec:
> "An implementation MUST support application-provided entity
> providers and MUST use those in preference to its own pre-packaged
> providers when either could handle the same request."
>
Sorry if I'm being dense but I can't work out if you think there's a
problem or not ? The above requirement is there to allow applications
to override the implementation-supplied standard entity providers.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.