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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf