W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 22 Feb 2010 16:01:16 +0100
Message-ID: <4B829C3C.3070901@gmx.de>
To: IETF Apps Discuss <apps-discuss@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Monday, 22 February 2010 15:01:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT