822 Restricted Mapping: Mapping between full RFC 822 and RFC 822 with restricted encoding
A reversible mapping for RFC 822 addresses crossing systems with restricted character sets.
Kille, S., "Mapping between full RFC 822 and RFC 822 with restricted encoding", RFC 1137, DOI 10.17487/RFC1137, December 1989, <https://www.rfc-editor.org/info/rfc1137>.
@misc{rfc1137,
series = {Request for Comments},
number = 1137,
howpublished = {RFC 1137},
publisher = {RFC Editor},
doi = {10.17487/RFC1137},
url = {https://www.rfc-editor.org/info/rfc1137},
author = {S. Kille},
title = {{Mapping between full RFC 822 and RFC 822 with restricted encoding}},
pagetotal = 3,
year = 1989,
month = dec,
} RFC text
Contents
Network Working Group S. Kille Request for Comments: 1137 University College London Updates: RFC 976 December 1989 Mapping Between Full RFC 822 and RFC 822 with Restricted Encoding Status of this Memo This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. Distribution of this memo is unlimited. This document describes a set of address mappings which will enable interworking between systems operating RFC 822 protocols in a general manner, and those environments where transfer of RFC 822 messages restricts the character set which can be used in addresses. UUCP transfer of RFC 822 messages is an important case of this [Crocker82a, Horton86a]. Specification This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. 1. Introduction Some mail networks which use RFC 822 cannot support the full character set required by all aspects of RFC 822. This document describes a symmetrical mapping between full RFC 822 addressing, and a form for use on these networks. Any addresses within the networks will not use the full RFC 822 addressing, and so any addresses encoded according to this standard will always represent remote addresses. This document derives from a mapping originally specified in RFC 987 [Kille86a], where the domain of application was more restricted. Two terms are now defined: Full RFC 822 This implies full support for transfer to and from any legal RFC 822 address. In particular, the quoted-string form of local-part must be supported (e.g., <"Joe Soap"@foo.bar>). Restricted RFC 822 This implies a subset of RFC 822 addressing. The quoted-string form of local-part need not be supported. Standard UUCP mail transfer falls into this category. Restricted RFC 822 is undesirable, but in practice it exists in many places. When a message is transferred from full RFC 822 to restricted RFC 822, and address forms used in full RFC 822 are involved, message loss may occur (e.g., it may not be possible to return an error message). This RFC describes a quoting mechanism which may be used to map between full RFC 822 and restricted RFC 822, in order to alleviate this problem. 2. Encoding The RFC 822 EBNF meta notation is used. Any EBNF definitions taken from RFC 822 are prefixed by the string "822.". The following EBNF is specified. atom-encoded = *( a-char / a-encoded-char ) a-char = <any CHAR except specials (other than "@" and "."), SPACE, CTL, "_", and "#"> a-encoded-char = "_" ; (space) / "#u#" ; (_) / "#l#" ; <(> / "#r#" ; <)> / "#m#" ; (,) / "#c#" ; (:) / "#b#" ; (\) / "#h#" ; (#) / "#e#" ; (=) / "#s#" ; (/) / "#" 3DIGIT "#" The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is interpreted in decimal as the corresponding ASCII character. The choice of special abbreviations (as opposed to decimal encoding) provided is based on the manner in which this mapping is most frequently used. There are special encodings for each of the PrintableString characters not in EBNF.a-char, except ".". Space is given a single character encoding, due to its (expected) frequency of use, and backslash as the RFC 822 single quote character. This mapping is used to transform between the two forms of 822.word: 822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC 822). To encode (full RFC 822 -> restricted RFC 822), first remove any quoting from any 822.quoted-string. Then, all EBNF.a-char are used directly and all other CHAR are encoded as EBNF.a-encoded-char. To decode (restricted RFC 822 -> full RFC 822): if the address can be parsed as EBNF.encoded-atom reverse the previous mapping. If it cannot be so parsed, map the characters directly. 3. Application This mapping should be used for all addresses, at the MTS or Header level. It is applied to the 822.local-part of the addresses. For example: Full RFC 822 Restricted RFC 822 Steve.Kille@cs.ucl.ac.uk <-> Steve.Kille@cs.ucl.ac.uk "Steve Kille"@cs.ucl.ac.uk <-> Steve_Kille@cs.ucl.ac.uk "argle#~"@blargle <-> argle#h##126#@blargle References [Crocker82a] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, August 1982. [Horton86a] Horton, M., "UUCP Mail Interchange Format Standard", RFC 976, February 1986. [Kille86a] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic Community Report (MG.19), RFC 987, June 1986. Security Considerations Security issues are not discussed in this memo. Author's Address Steve Kille University College London Gower Street WC1E 6BT England Phone: +44-1-380-7294 EMail: S.Kille@Cs.Ucl.AC.UK
ISO Plain Language
On this page
§1Full and Restricted RFC 822
Full RFC 822 supports every legal address, including a quoted-string local part such as "Joe Soap"@foo.bar. Restricted RFC 822 is a subset that need not support quoted-string local parts; the RFC identifies standard UUCP mail transfer as an example.
When a full address crosses into a restricted system, information may be lost, including the ability to return an error. The memo describes a symmetric mapping to reduce this problem.
Some mail systems cannot carry every character in an address. This mapping changes those characters into a form that restricted systems can carry.
§2Encoding and Decoding Characters
Characters allowed by the encoded atom pass through unchanged. A space becomes an underscore. Special codes include #u# for underscore, #l# and #r# for parentheses, and #h# for a hash. Other characters can use a three-digit decimal ASCII code between hash marks, from 0 to 127.
To encode, remove quoting from a quoted string, retain allowed characters, and encode the rest. To decode, reverse the mapping when the address parses as an encoded atom; otherwise, map its characters directly.
Allowed characters stay as they are. Spaces and other restricted characters get short codes that the receiving system can turn back into the original characters.
§3Where the Mapping Applies
The mapping applies to the RFC 822 local part of addresses at the message-transfer or header level. The RFC shows a plain address that remains unchanged, a quoted name with a space that uses an underscore, and an address with a hash and tilde encoded using special and decimal forms.
The document asks for discussion and improvements and says it does not specify an Internet standard. Its metadata marks it Historic and records that it updates RFC 976.
Only the part before the at sign is transformed. Ordinary text can stay the same, while characters the restricted system cannot carry are encoded.