Re: proposed part 1 section 6.3

You are correct sir, I saw the User-Agent example there in part 1 section
6.3 and did not realize User-Agent had its own separate section.

Regards

Dale

2011/8/5 Amos Jeffries <squid3@treenet.co.nz>

> On 05/08/11 19:17, Dale Anderson wrote:
>
>> Good evening. To -hopefully- conclude my series of talking to myself
>> about section 6.3, here is a proposed new section 6.3. And following
>> that a few example User-Agent headers for reference when considering
>> language to do with what I call the "bonus" information generally
>> referring to system architecture, particularly the two alternative
>> endings to the proposed section 6.3.
>>
>
> You seem to be confusing Product Tokens (part 1, section 6.3) and the
> User-Agent: header which makes use of them (part 2 section 9.9) as being the
> same thing.
>
> A "product" representation can appear in at least 3 places. Not all of
> which allow comments, or multiple products.
>
>  ie "HTTP/1.1" is a product according to the Upgrade: header definitions.
>
> IMO the existing product token section 6.3 is simple, clear, and has a BNF
> which almost all common agents conform to.
>
>
>
>> 6.3.  Product Tokens
>>
>>
>>    Product tokens are used to allow communicating applications to
>>    identify themselves by software name and version.
>>
>>    A product token SHOULD consist of a product and a product-version,
>>    separated by a slash “/”.
>>
>>    Product tokens are separated by linear whitespace.
>>
>>    When software versions change, the product SHOULD stay the same
>>    and only the product-version portion vary, to aid parseability and
>>    comparison.
>>
>>    By convention, the products are listed in order of their significance
>>    for identifying the application.
>>
>
> This is where you start talking about things that will cause problems.
>
>
>
>>    In practice, clients exhibit bonus information parenthetically
>>    between product tokens. This information is proprietary and SHOULD NOT
>>    be attempted to be used meaningfully.
>>
>> -or-
>>    In practice, clients exhibit bonus information parenthetically
>>    following product tokens. This information refers to the preceding
>>    product token and identifies information about the host system
>>    architecture upon which the client runs.
>>
>
>
> Neither.
>
> A quick look at the UA registry shows an utter mess inside the comment
> fields. With at least three defacto conventions being used. Because the
> parenthesized comment is already part of the existing specifications...
>
>  Server = product *( RWS ( product / comment ) )
>  User-Agent = product *( RWS ( product / comment ) )
>  Upgrade = 1#product
>  Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
>
>  product = token [ "/" product-version ]
>  product-version = token
>
>  comment = "(" *( ctext / quoted-cpair / comment ) ")"
>
>
> You can also see from the above why it uses the wording "most fields". For
> there are places where product tokens are used singularly and with no
> comment permitted. The HTTPbis drafts only formalize Upgrade: header, but
> there are other places like defacto syntax in Via: comments where product is
> used in the singular.
>
> The status quo allows somebody to one day formalize the defacto standard
> inside those comments as a separate RFC.
>
> AYJ
>
>