>> It seems completely unnecessary given the now ubiquitous use of 8-bit
>> clean transports and the presence of UTF-8, which IIRC was defined
>> long after UTF-7. However, the wider community may be aware of
>> some reason why browsers should support it, so I'd like to hear
>> your comments.
The problem, as I see it, is not that the browsers support conversion
using UTF-7. It is that they auto-detect UTF-7. Since UTF-7 uses plain
ASCII characters to form escape sequences, it turns out to be trivial to
fool a browser into detecting UTF-7, causing an XSS security hole.
Some of us have spent more than ample time building anti-UTF-7 code
(such as judiciously replacing '+' in UTF-7 spoof sequences with
'&#43;'). It is nutty.
I agree with the basic premise of Roy's that UTF-7 ought to be banned.
But it would be simpler to remove it from the list of things
auto-detected by user agents. A page that actually uses UTF-7 really
REALLY ought to declare that encoding (in which case no security flaw is
present). Otherwise it should display as mojibake.
Addison
--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Internationalization is an architecture.
It is not a feature.