Re: Unknown text/* subtypes [i20]

Sorry that I was off from this list for a month that was very busy...

"Roy T. Fielding" <fielding@gbiv.com> writes:

> And here is what I suggest for a rewrite, merging both of the above
> sections under Media Types and inverting the "fantasy island"
> requirements of the original text to what is permitted in HTTP
> beyond the registration defaults of MIME.

+1: I prefer this alternative for minimizing new security concerns.

Julian's text (at least implicitly) allows clients to guess any
character encoding when no charset value is provided, which is
unacceptable for HTTP/1.1 because many existing applications
immediately become vulnerable due to this change (and existence of
UTF-7).  I strongly suggest that this must be treated as an
incompatible normative change, and it is hard to realize even if the
version number is raised to HTTP/2.0.

Roy's suggestion (and my previous one) is moderate in this scope,
acceptable within version 1.1 in reality, and almost consistent to
on-going HTML5 updates which will be actually implemented in real user
agents.

Possible my comment to Roy's proposal is

  - Auto-detection under explicit "iso-8859-1" charset label is dirty.
    I suggest either drop it or state it as "if required for backward
    compatibility".  I do not want to give server owners a permission
    for blindly adding ISO-8859-1 charset label without consulting the
    real contents any more in future.  I think it will not be
    supported under HTML5 rules.

  - We may need some clarification on the definition of whether "the
    encoding is a superset of US-ASCII".  There are several well-used
    character encodings which are marginal on this property.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]

Received on Thursday, 14 February 2008 10:35:40 UTC