FYI: IETF LC for draft-reschke-rfc2231-in-http

On 22.02.2010 15:04, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP)
>     Header Fields '
>     <draft-reschke-rfc2231-in-http-10.txt>  as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2010-03-22. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-10.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17647&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

Hi there,

this spec is now in Last Call, ending March, 22.

A few issues are open, and those are summarized in Appendix D. I'm 
particularly looking for feedback on:

- parameter-abnf

    In Section 3.2:

    Type: change

    julian.reschke@greenbytes.de (2010-02-20): The ABNF for reg-parameter
    and ext-parameter is ambiguous, as "*" is a valid token character;
    furthermore, RFC 2616's "attribute" production allows "*" while RFC
    2231's does not. (reported by Alexey Melnikov).

    julian.reschke@greenbytes.de (2010-02-21): Proposal: restrict the
    allowable character set in parameter names to exclude "*" (and maybe
    even more non-name characters?).  Also, consider extending the set of
    value characters (for the right hand side) to allow more characters
    that can be unambiguously parsed outside quoted strings, such as "/".

and

- iso8859

    In Section 3.2:

    Type: change

    julian.reschke@greenbytes.de (2010-02-20): The protocol could be
    further simplified by mandating UTF-8 only (reported by Alexey
    Melnikov).  On the other hand and not surprisingly, testing shows
    that ISO-8859-1 support is widely implemented.  The author is looking
    for community feedback on this choice.

Feedback on these specific issues would be appreciated,

Julian