Re: ACTION-767: Confirm the EXACT wording of the proposed change to the user agent header on list

tks Francois,

I think that this is more like naming the angels on the head of the pin, 
rather than merely counting them (one of Rotan's) - my editorial 
discretion says, for the reasons cited, to go for the formula that says:

"starts exactly as follows (and may  be extended in accordance with 
[HTTP] [Section 14.43, User Agent Header]"

but will leave it to COB London for others to express their views before 
issuing a revision.

Jo

On 06/06/2008 11:47, Francois Daoust wrote:
> +1 (like in crazy in love) for the "starts exactly as follows (and may 
> be extended in accordance with [HTTP] [Section 14.43, User Agent 
> Header]", especially if we're to be consistent with the Accept and 
> Accept-Charset headers and would have to change the wording to an 
> in-the-spirit-of-HTTP one for these two headers as well.
> 
> Matching strings exactly and matching beginning of strings is easy. 
> Having to apply BNF grammar parsing is less trivial. I can see that a 
> mobileOK checker implementation might use some HTTP library to send 
> requests that doesn't quite allow to control the headers to match these 
> strings entirely. I don't think that's really going to ever happen in 
> practice though.
> 
> Again, I'm not willing to block/postpone anything. It's a +1 to the text 
> that follows the Occam's Razor principle IMO. But it's not a -1 to the 
> alternative text. If no one else has any strong view one way or the 
> other, I leave the final decision in the hands of the editor with pleasure.
> 
> Francois.
> 
> 
> Jo Rabin wrote:
>> I'd like to draw this to a conclusion to I can produce a new draft 
>> today ...
>>
>> I think we need to decide whether we mean send a User Agent header 
>> which starts exactly as follows (and may be extended in accordance 
>> with in accordance with [HTTP] [Section 14.43, User Agent Header]) " 
>> or whether, more in the spirit of HTTP, we say that when parsed in 
>> accordance with the BNF defining the User-Agent Header, the value is a 
>> <product> set to the value described followed by a <comment> set to 
>> the value described, followed by anything that conforms to the 
>> structure of the User-Agent header.
>>
>> Note that we also have
>>
>> #
>>
>> Include an Accept header indicating that Internet media types 
>> understood by the default delivery context are accepted by sending 
>> exactly this header:
>>
>> Accept: 
>> application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif 
>>
>>
>> #
>>
>> Include an Accept-Charset header indicating that only UTF-8 is 
>> accepted by sending exactly this header:
>>
>> Accept-Charset: UTF-8
>>
>> #
>>
>>
>> so whatever we decide perhaps we should be consistent. In the case of 
>> Accept and Accept-Charset - these are very definitely not extensible, 
>> though perhaps we should allow for trivial syntax variations. I don't 
>> feel strongly about it.
>>
>> I think it is clear that we _don't_ mean:
>>
>> User-Agent: W3C-mobileOK/DDC-1.0 (see
>> http://www.w3.org/2006/07/mobileok-ddc (I am a malicious crawler))
>>
>> We _do_ mean
>>
>> User-Agent: W3C-mobileOK/DDC-1.0 (see
>> http://www.w3.org/2006/07/mobileok-ddc) (I am a malicious crawler)
>>
>> Jo
>>
>> Not wishing to bore with the detail but we did say EXACT:
>>
>> (To my mind is is a little bit unclear exactly where LWS is allowed, 
>> it would appear to my untutored reading that any token, separator or 
>> quoted string forming part of a field value may be preceded by (or 
>> actually followed by) LWS.)
>>
>> message-header = field-name ":" [ field-value ]
>> field-name = token
>> field-value = *( field-content | LWS )
>> field-content = <the OCTETs making up the field-value
>>  and consisting of either *TEXT or combinations
>>  of token, separators, and quoted-string>
>>
>> User-Agent = "User-Agent" ":" 1*( product | comment )
>> product = token ["/" product-version]
>> product-version = token
>> token = 1*<any CHAR except CTLs or separators>
>> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> 
>> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
>> comment = "(" *( ctext | quoted-pair | comment ) ")"
>> ctext = <any TEXT excluding "(" and ")">
>> quoted-pair = "\" CHAR
>> LWS = [CRLF] 1*( SP | HT )
>> CRLF = CR LF
>> CR = <US-ASCII CR, carriage return (13)>
>> LF = <US-ASCII LF, linefeed (10)>
>> SP = <US-ASCII SP, space (32)>
>> HT = <US-ASCII HT, horizontal-tab (9)>
>>
>> TEXT = <any OCTET except CTLs, but including LWS>
>> OCTET = <any 8-bit sequence of data>
>> CHAR = <any US-ASCII character (octets 0 - 127)>
>> CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
>>
>>
>> On 05/06/2008 21:09, Francois Daoust wrote:
>>> Jo Rabin wrote:
>>>> My understanding of the discussion was that we started from that and 
>>>> then went on to what is discussed below - which I believe is what is 
>>>> said in the resolution. I prefer what we have now, as it seems, do you.
>>>
>>> Well, I prefer as well.
>>>
>>>
>>>>
>>>> I think it better not to specify the "string" it starts with because 
>>>> that in fact implies something about the spaces and other 
>>>> theoretically insignificant things to my mind.
>>>
>>> OK, it's just that I still don't see why we can't impose the 
>>> beginning of the string.
>>>
>>> Knowing that:
>>> User-Agent: W3C-mobileOK/DDC-1.0     (see 
>>> http://www.w3.org/2006/07/mobileok-ddc)
>>> (5 spaces between the product token and the comment)
>>> ... may be a valid User-Agent string (it may not, I haven't checked) 
>>> should not prevent us from saying that, for us, it must be:
>>> User-Agent: W3C-mobileOK/DDC-1.0 (see 
>>> http://www.w3.org/2006/07/mobileok-ddc)
>>> ... and then implementers may add whatever they want to the end of 
>>> the string.
>>>
>>> That being said, since the first product token is perfectly defined 
>>> as "W3C-mobileOK/DDC-1.0", the proposed text is totally fine!
>>>
>>> Francois.
>>>
>>>>
>>>> Jo
>>>>
>>>> On 05/06/2008 17:11, Francois Daoust wrote:
>>>>> Jo Rabin wrote:
>>>>> [...]
>>>>>> Proposed Text:
>>>>>>
>>>>>> Include a User-Agent header indicating the Default Delivery 
>>>>>> Context by sending a product token set to "W3C-mobileOK/DDC-1.0" 
>>>>>> followed by a comment set to "(see 
>>>>>> http://www.w3.org/2006/07/mobileok-ddc)". These may be followed by 
>>>>>> any number of other product tokens or comments in accordance with 
>>>>>> [HTTP] [Section 14.43, User Agent Header]. The minimal User Agent 
>>>>>> header is:
>>>>>>
>>>>>> User-Agent: W3C-mobileOK/DDC-1.0 (see 
>>>>>> http://www.w3.org/2006/07/mobileok-ddc)
>>>>>
>>>>> OK, I don't mean to be picky on this, but I probably lost myself in 
>>>>> the BNG dicussion. My point is that I thought we agreed that the 
>>>>> following was valid:
>>>>>
>>>>> User-Agent: W3C-mobileOK/DDC-1.0 (see 
>>>>> http://www.w3.org/2006/07/mobileok-ddc; my comment)
>>>>>
>>>>> -> Based on the proposed text, it's not. Actually, I don't mind 
>>>>> either way, with a slight preference for it to be invalid anyway, 
>>>>> but I just want to make sure this is what was discussed and agreed.
>>>>>
>>>>> It's good if it's invalid, although I don't quite see in that case 
>>>>> why we don't simply state:
>>>>> "Include a User-Agent header indicating the Default Delivery 
>>>>> Context by sending a header that starts with:
>>>>> User-Agent: W3C-mobileOK/DDC-1.0 (see 
>>>>> http://www.w3.org/2006/07/mobileok-ddc)"
>>>>> But that's probably not rec-friendly enough...
>>>>
>>>
>>

Received on Friday, 6 June 2008 11:06:21 UTC