[http-state] algorithm definitions

[Julian Reschke <[e-mail]>]

Hi,

from 
<http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.2>:

    A user agent MUST use an algorithm equivalent to the following
    algorithm to parse set-cookie-strings:

    1.  If the set-cookie-string contains a U+003B (";") character:

           The name-value-pair string consists of the characters up to,
           but not including, the first U+003B (";"), and the unparsed-
           attributes consist of the remainder of the set-cookie-string
           (including the U+003B (";") in question).

        Otherwise:

           The name-value-pair string consists of all the characters
           contained in the set-cookie-string, and the unparsed-
           attributes is the empty string.

    2.  If the name-value-pair string lacks a U+003D ("=") character,
        ignore the set-cookie-string entirely.

    3.  The (possibly empty) name string consists of the characters up
        to, but not including, the first U+003D ("=") character, and the
        (possibly empty) value string consists of the characters after
        the first U+003D ("=") character.

    4.  Remove any leading or trailing WSP characters from the name
        string and the value string.

    5.  If the name string is empty, ignore the set-cookie-string
        entirely.

    6.  The cookie-name is the name string, and the cookie-value is the
        value string.

    The user agent MUST use an algorithm equivalent to the following
    algorithm to parse the unparsed-attributes:

    1.  If the unparsed-attributes string is empty, skip the rest of
        these steps.

    2.  Discard the first character of the unparsed-attributes (which
        will be a U+003B (";") character).

    3.  If the remaining unparsed-attributes contains a U+003B (";")
        character:

           Consume the characters of the unparsed-attributes up to, but
           not including, the first U+003B (";") character.

        Otherwise:

           Consume the remainder of the unparsed-attributes.

        Let the cookie-av string be the characters consumed in this step.

    4.  If the cookie-av string contains a U+003D ("=") character:

           The (possibly empty) attribute-name string consists of the
           characters up to, but not including, the first U+003D ("=")
           character, and the (possibly empty) attribute-value string
           consists of the characters after the first U+003D ("=")
           character.

        Otherwise:

           The attribute-name string consists of the entire cookie-av
           string, and the attribute-value string is empty.

    5.  Remove any leading or trailing WSP characters from the attribute-
        name string and the attribute-value string.

    6.  Process the attribute-name and attribute-value according to the
        requirements in the following subsections.  (Notice that
        attributes with unrecognized attribute-names are ignored.)

    7.  Return to Step 1.


Wow -- all of this to say that a string should be tokenized where ";" 
occurs, that the first token and the remaining tokens have different 
roles, and how to parse the individual tokens.

A few ideas how to compress this:

- If part 2 / step 1 removes the leading semicolon, why include it in 
the first place?

- Maybe just say ";" and "=" after stating the Unicode code point once? 
Speaking of which, is *anybody* confused about what these characters 
might be?

- Instead of expressing a for-loop in prose, simply state that the 
string is to be split on semicolons, and a certain set of steps is to be 
applied to each fragment.

Etc.

I've heard that this part is exclusively for those who actually write 
the parsing code, and nobody else need to care. I disagree with that. If 
the spec makes normative requirements on handling non-conforming input, 
then it should be phrased in a way so that it's clear what gets 
processed how.

Giving an example of a conforming algorithm is fine, but substituting 
the description with that algorithm IMHO is not.

For instance, when I debug an HTTP/cookie problem and look at an HTTP 
trace, I want to be able to understand how the recipient is going to 
parse the string. Reading the algorithm really isn't very helpful for that.

Also, if we need algorithms instead of format descriptions, why is it ok 
to define date parsing using an ABNF (see section 5.1.1)?

Best regards, Julian