Re: proposed part 1 section 6.3

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

Received on Friday, 5 August 2011 13:01:07 UTC