John, it seems to me that you're really over-stating the risk of UTF-8.
I understand & agree that there may be systems out there which have trouble displaying UTF-8.
However (!): I would think that it is sufficient that we can reasonably assume that any *person* who needs to read an RFC does have access to a Web browser less than 5 years old (picking a somewhat arbitrary number), which *will* display UTF-8 just fine -- availability of fonts aside (or is that your point?).
As a matter of fact, the IETF is telling protocol designers that they *have* to support Unicode -- why can we require it for protocols, but not for the documents we produce ourselves?
Regarding the other point about transmitting quotes from RFCs: of course it's wise to phrase the normative parts of RFCs so that they don't require transmission of non-ASCII characters. And yes, that needs to be stated, if it isn't already.
On the other hand, it would be extremely useful to have examples that *do* contain non-ASCII characters; if only to make implementers aware of the fact they they can *not* rely on ASCII and things are going to work (I've seen authors not doing I18N examples because they didn't know how to publish them as RFC...).
BR, Julian _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
