Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
draft-reschke-rfc2231-in-http-12

[Ballot discuss]
A fine document, but there are three small things I don't understand...

Why isn't RFC 2231 a normative reference?

Why does the text say...
  RFC 2231 (Appendix of [RFC2231]) defines an
  escaping mechanism for use in MIME headers.
...I can't find an Appendix in RFC 2231.

RFC 2231 doesn't actually use the term "escape" or "escaling". It might be nice to harmonise on the terms used by theat RFC.

[Ballot comment]
In section 3.2:
  >
  > Producers MUST NOT use character sets other than "UTF-8" ([RFC3629])
  > or "ISO-8859-1" ([ISO-8859-1]).
  >
  Better to say:
  >
  > Producers MUST use either the "UTF-8" ([RFC3629]) or the
  > "ISO-8859-1" ([ISO-8859-1]) character set.

[Ballot comment]
In Section 3.2, there appears to be confusion between the terms "mime-charset" and "ext-charset".

Section 4.1 of this I-D states:

  Section 4.2 of [RFC2277] requires that protocol elements containing
  text are able to carry language information.  Thus, the ext-value
  production should always be used when the parameter value is of
  textual nature and its language is known.

In fact RFC 2277 states that "[a]ll human-readable text has a language" and appears to emphasize human-readable text. Although it's not truly clear if RFC 2277 makes a distinction between "text" and "human-readable text", it might be useful to incorporate that distinction here because many textual strings included in protocol elements are not intended for human consumption.

[Ballot comment]
In section 3.2:

  Producers MUST NOT use character sets other than "UTF-8" ([RFC3629])
  or "ISO-8859-1" ([ISO-8859-1]).  Extension character sets (ext-
  charset) are reserved for future use.

ext-charset does not appear in the ABNF.  Should it?

[Ballot comment]
In section 3.2:

  Producers MUST NOT use character sets other than "UTF-8" ([RFC3629])
  or "ISO-8859-1" ([ISO-8859-1]).  Extension character sets (ext-
  charset) are reserved for future use.

ext-charset does not appear in the ABNF.  Should it?

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this version
        is ready for forwarding to the IESG for publication?

Graham Klyne (gk@ninebynine.org)
Yes (-08 in some detail, -09 quickly for this report)
(-10 for last call, not personally reviewed)

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

Generally, the document seems to have had adequate review.  The fact of implementation in three common browsers is also encouraging.

There has been some useful discussion of security concerns during the last call period, which are being resolved to the satisfaction of the reviewers.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

Not other than noted above.

There has been some last-call review from the security area experts about spoofing issues and others, which I understand to have been resolved satisfactorily.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

No concerns that this is pointless or harmful.

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

The interested community appears to be either quite small or generally content with what is proposed.  The technical proposals are not controversial as they simplify and clarify use of an existing technical proposal in the HTTP context.  The quality of engaged reviewers seems to more than make up for any lack of quantity.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Not to my knowledge.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
        Checklist and http://tools.ietf.org/tools/idnits/).
        Boilerplate checks are not enough; this check needs to be
        thorough. Has the document met all formal review criteria
        it needs to, such as the MIB Doctor, media
        type and URI type reviews?

Not personally.  The following report was provided by Alexey Melnikov:

[[
idnits 2.12.02

tmp/draft-reschke-rfc2231-in-http-11.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  == You're using the IETF Trust Provisions' Section 6.b License Notice from
    12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
    http://trustee.ietf.org/license-info/)


  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
    first submitted before 10 November 2008.  Should you add the disclaimer?
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.) -- however,
    there's a paragraph with a matching beginning. Boilerplate error?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'


    Summary: 0 errors (**), 2 warnings (==), 2 comments (--).
--------------------------------------------------

The possible downref warning can be ignored.
Julian thinks that the disclaimer about pre-RFC5378 work is not needed.]]

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the strategy
        for their completion? Are there normative references that are
        downward references, as described in [RFC3967]? If so, list
        these downward  references to support the Area Director in
        the Last Call procedure for them [RFC3967].

Yes.  All normative references are published RFCs or ISO specifications.  All-but-one RFCs are either STD or BCP, the exception being RFC2616 (PS).

In or about last call, some references were reclassified from informational to normative.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

IANA considerations section is present and "empty".  I think this is OK, but did wonder in passing if this specification might have some (indirect) impact in existing registries.  I think probably not, but wanted to ask the question.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

Not personally.  The following was provided by Alexey Melnikov:
[[
(after pasting ABNF in there) reports no error. Its output:


attribute = token
value = token / quoted-string
quoted-string =
token =
parameter = reg-parameter / ext-parameter
reg-parameter = parmname LWSP "=" LWSP value
ext-parameter = parmname "*" LWSP "=" LWSP ext-value
parmname = 1*attr-char
ext-value = charset "'" [ language ] "'" value-chars
charset = "UTF-8" / "ISO-8859-1" / mime-charset
mime-charset = 1*mime-charsetc
mime-charsetc = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "+" / "-" / "^" / "_" / "`" / "{" / "}" / "~"
language =
value-chars = *( pct-encoded / attr-char )
pct-encoded = "%" HEXDIG HEXDIG
attr-char = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
; attribute defined but not used
; parameter defined but not used
 

All undefined productions seem to be Ok (defined in the ABNF spec or earlier in the draft).
]]

I understand the ABNF has been updated since that report, but I don't have a clean copy of the current ABNF to re-check.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract and/or
        introduction of the document. If not, this may be an
        indication that there are deficiencies in the abstract or
        introduction.

(mainly copied from the document abstract):
[[
  This specification defines a simplified mechanism for encoding
  arbitrary (e.g. non-ASCII) characters in HTTP header field parameters.

  By default, message header field parameters in Hypertext Transfer
  Protocol (HTTP) messages can not carry characters outside the ISO-
  8859-1 character set.  RFC 2231 defines an escaping mechanism for use
  in Multipurpose Internet Mail Extensions (MIME) headers.  This
  document specifies a profile of that encoding suitable for use in
  HTTP header fields.

  There are multiple HTTP header fields that already use RFC 2231
  encoding in practice (Content-Disposition) or might use it in the
  future (Link).  The purpose of this document is to provide a single
  place where the generic aspects of RFC 2231 encoding in HTTP header
  fields are defined.
]]

    Working Group Summary
        Was there anything in the discussion in the interested
        community that is worth noting? For example, was there
        controversy about particular points or were there decisions
        where the consensus was particularly rough? Was the document
        considered in any WG, and if so, why was it not adopted as a
        work item there?

This document is an individual submission, but has been reviewed on the HTTP mailing list.

    Document Quality   
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to implement
        the specification? Are there any reviewers that merit special
        mention as having done a thorough review, e.g., one that
        resulted in important changes or a conclusion that the document
        had no substantive issues? If there was a MIB Doctor, Media
        Type or other expert review, what was its course (briefly)? In
        the case of a Media Type review, on what date was the request
        posted?   

This document is a clarification and simplification of an existing protocol specification, and reviewers indicate the simplifications are well-judged and match practical use in HTTP.

Also, the draft claims that, as of January 2010, there were at least three independent implementations of the encoding defined in Section 3.2: Konqueror (trunk), Mozilla Firefox, and Opera.

AD review:

> reg-parameter = attribute LWSP "=" LWSP value
>
> ext-parameter = attribute "*" LWSP "=" LWSP ext-value

as attribute as defined as , this means that "*" is already allowed at the end of attribute, which creates a parsing conflict between 2 production. So I think you need to tighten the ABNF a bit.

>  Producers MUST NOT use character sets other than "UTF-8" ([RFC3629])
>  or "ISO-8859-1" ([ISO-8859-1]).  Extension character sets (ext-
>  charset) are reserved for future use.

It would be good if ISO-8859-1 can be demoted to SHOULD NOT.

> 4.2.  Error Handling
>
>  Header specifications that include parameters should also specify
>  whether same-named parameters can occur multiple times.

That might be Ok for HTTP. But I believe MIME doesn't allow multiple parameters with the same name.