This is an old revision of the document!
Some discussion of requirements, goals, and desires around non-ASCII characters are on the formatreq page. The table below summarizes a taxonomy of cases where (non-ASCII) UTF-8 might or might not be allowed, along with some thoughts. The intent is that each row represents a separate policy decision.
We expect that any case we mark “Yes” for Consensus will also require providing an ASCII-only transliteration unless we explicitly note otherwise.
Case | Section | Use | Consensus | Comments | |
---|---|---|---|---|---|
1a | (title page) | Author name | Yes? | Answer should match (6a) | |
1b | (title page) | Author affiliation | Answer should match (6b) | ||
1c | (title page) | Document title | |||
2 | Abstract | ||||
3a | Body or Appendix | Example string | E.g. fictional person name, IRI, EAI, domain name, etc. Currently there's no XML markup to denote example strings, so hard to distinguish from (3c) | ||
3b | Body or Appendix | Code snippet | |||
3c | Body or Appendix | Literal protocol element | Transliteration should use U+xxxx syntax | ||
3d | Body or Appendix | Document title of a cited document | Answer should match (4c) | ||
3e | Body or Appendix | Prose | No? | e.g. use of “naïve” in http://tools.ietf.org/html/rfc4690#section-1.5.5 | |
4a | References | Author name | Yes? | Answer should match (1a) | |
4b | References | Author affiliation | Answer should match (1b) | ||
4c | References | Document title | Not necessarily an RFC that's being referenced | ||
4d | References | Document IRI | No? | ||
5a | Acknowledgements | Person name | Yes? | ||
5b | Acknowledgements | Organization name | |||
6a | Authors Addresses | Author name | Yes? | ||
6b | Authors Addresses | Author affiliation | |||
6c | Authors Addresses | Author email address (EAI) | |||
6c | Authors Addresses | Author IRI | No? | ||