Subject: default for q-values in Accept-Language and elsewhere

From: "Javier Godoy" <[email-masked]>
Date: Wed, 7 May 2008 14:42:51 -0300

Julian Reschke wrote:

> I'd recommend that we state the default just once in the section that 
> introduces qvalues 
> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-latest.html#rfc.section.3.4>) 
> and remove the description everywhere else.

That makes sense, but the qvalue cannot default to nothing by itself.
Stating that "the qvalue defaults to 1" would mean that
"text/plain;q=" or "text/plain;q" is to be understood as  "text/plain;q=1"
because of the following ABNF:

[[
qvalue         = ( "0" [ "." 0*3DIGIT ] )
                   | ( "1" [ "." 0*3("0") ] )

Accept         = "Accept" ":"
                     #( media-range [ accept-params ] )

accept-params  = ";" "q" "=" qvalue *( accept-extension )
]]

Maybe we should introduce a "qparam" production, then the qparam (*not* the
qvalue) would default to q=1. I think it is more correct this way.

qparam = "q" "=" qvalue
accept-params  = ";" qparam *( accept-extension )

BTW, it is allowed having extension parameters *without* a q parameter? For
instance "text/plain;atoken=avalue"

In that case, the ABNF could be:

Accept  = "Accept" ":" #( media-range accept-params )
qparam = ";q" "=" qvalue
accept-params  = [qparam] *( accept-extension )

Hope that helps

Best Regards

Javier

----- Original Message ----- 
From: "" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Martin Duerst" <[email-masked]>; "'HTTP Working Group'"
<[email-masked]>; "LTRU Working Group" <[email-masked]>
Sent: Wednesday, May 07, 2008 8:49 AM
Subject: Re: default for q-values in Accept-Language and elsewhere

>
> Adrien de Croy wrote:
>>> Looking at other subsections of Section 14, there is an explicit
>>> default of q=1 for Accept and Accept-Charset, but I also didn't
>>> find a default for Accept-Encoding.
>>>
>>> Please add this issue to your issue list unless you already
>>> have it listed.
>>>
>>
>> also the whole concept of q values only makes any sense if the default 
>> value is 1.
>> ...
>
>
> BR, Julian
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 07 May 2008 20:56:07 +0200

>instance "text/plain;atoken=avalue"

No, but the above would be valid if text/plain allowed "atoken" as media
type parameter. Ambiguity between accept-extension and parameters is the
likely reason why you have to have the "q".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 May 2008 16:44:17 +0200

Javier, thanks for the feedback...

So it seems the less intrusive change is simply to add the missing 
statement to the definition of Accept-Encoding:

+    Each codings value MAY be given an associated quality value which
+    represents the preference for that encoding.  The default value is
+    q=1.

(see 
<http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/115/i115.diff>).

BR, Julian

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 19 May 2008 12:03:19 -0300

> <http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/115/i115.diff>).

+1, I think it is clear enough.

Best Regards

Javier

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 May 2008 11:39:04 +0200

> +1, I think it is clear enough.

Change applied and issue closed with 
<http://www3.tools.ietf.org/wg/httpbis/trac/changeset/248>.

BR, Julian