On Wed, 2005-11-30 at 18:29 -0800, Paul Hoffman wrote:
No escape mechanism is needed. Non-displayable characters are still
in the RFC, they simply can't be displayed by everyone (but they can
be displayed by many). This is infinitely simpler, and a much better
long-term solution, than "an escape mechanism". Further, there would
be no more "ASCII version" to be authoritative. The Internet Draft
clearly says that there is a single RFC, and it has a single encoding.
Why do you think there is a problem using all possible characters in an
ID, but not in an RFC? Why would it be okay for the RFC not to be
readable for some, but then ensure the ID is limited to ASCII?
I liked the idea that Frank suggested, use the HTML escape
sequence to declare the unicode character. This allows the ASCII
version to remain authoritative.
... as well as unreadable and unsearchable using normal search
mechanisms. The purpose of the proposal is to allow RFCs to be
readable and searchable using the encoding that is common on the
Internet, without resorting to sorta-kinda-HTML or an "escape
mechanism". Remaining with plain ASCII would be better than either of
the latter.
The suggestion of the HTML escape would ensure readability. As only
ASCII would be used, there would be no issues related to searching. It
would allow an alternative display that remains compatible with an ASCII
limitation as the authoritative version. UTF-8 use would require
additional considerations regarding searching however.
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf