RE: IRIs, IDNAbis, and HTTP

Mark Nottingham wrote:
> Personally, I am *very* -1 on doing this.
> 
> Changing the allowable characters in a protocol element is a 
> *big* change, and there is not an interoperability gain to doing so.
> 
> There is also not a functionality gain; it is possible (if 
> not pretty) to serialise other characters into HTTP headers.

Because RFC 2616 doesn't specify the integration of the RFC 2047 into
HTTP, the RFC 2047 is basically unimplementable. At least, you cannot be
sure that any two implementations are implementing it the same way
because there are ambiguities.

If the integration of RFC 2047 into HTTP was clarified, then at least it
would be implementable. But, because current implementations are not
implementing RFC 2047, you cannot use it for any existing
headers/subfields. So, the new-and-improved RFC 2047 integration would
only be useful for newly-created headers/subfields. But, RFC 2047 is so
terrible that nobody wants to use it anyway, so why waste effort trying
to fix the RFC 2047 integration? Just deprecate it.

But, if RFC 2047 integration is deprecated, then a new mechanism should
be created that can handle UTF-8. Forget the argument that says RFC 2277
requires the HTTP WG to do this. Whether it does or not, it makes sense
to define a sensible, general-purpose way to include UTF-8 in new
headers and new header subfields. The specification for it can be
written up independently of the HTTP WG, and the WG can decide whether
to include it into HTTPbis; if not, it can be published as its own RFC.
IMO, if somebody is willing to create a new, usable mechanism before
HTTPbis is completed, it would be stupid not to include it in HTTPbis.

- Brian

Received on Friday, 14 March 2008 12:51:39 UTC