home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1137.txt < prev    next >
Text File  |  1992-09-09  |  6KB  |  171 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Kille
  8. Request for Comments:  1137                    University College London
  9. Updates:  RFC 976                                          December 1989
  10.  
  11.  
  12.              Mapping Between Full RFC 822 and RFC 822 with
  13.                           Restricted Encoding
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC suggests an electronic mail protocol mapping for the
  18.    Internet community and UK Academic Community, and requests discussion
  19.    and suggestions for improvements.  This memo does not specify an
  20.    Internet standard.  Distribution of this memo is unlimited.
  21.  
  22.    This document describes a set of address mappings which will enable
  23.    interworking between systems operating RFC 822 protocols in a general
  24.    manner, and those environments where transfer of RFC 822 messages
  25.    restricts the character set which can be used in addresses.  UUCP
  26.    transfer of RFC 822 messages is an important case of this
  27.    [Crocker82a, Horton86a].
  28.  
  29. Specification
  30.  
  31.    This document specifies a mapping between two protocols.  This
  32.    specification should be used when this mapping is performed on the
  33.    Internet or in the UK Academic Community. This specification may be
  34.    modified in the light of implementation experience, but no
  35.    substantial changes are expected.
  36.  
  37. 1.  Introduction
  38.  
  39.    Some mail networks which use RFC 822 cannot support the full
  40.    character set required by all aspects of RFC 822.  This document
  41.    describes a symmetrical mapping between full RFC 822 addressing, and
  42.    a form for use on these networks.  Any addresses within the networks
  43.    will not use the full RFC 822 addressing, and so any addresses
  44.    encoded according to this standard will always represent remote
  45.    addresses.  This document derives from a mapping originally specified
  46.    in RFC 987 [Kille86a], where the domain of application was more
  47.    restricted.  Two terms are now defined:
  48.  
  49.    Full RFC 822
  50.  
  51.       This implies full support for transfer to and from any legal RFC
  52.       822 address.  In particular, the quoted-string form of local-part
  53.       must be supported (e.g., <"Joe Soap"@foo.bar>).
  54.  
  55.  
  56.  
  57.  
  58. Kille                                                           [Page 1]
  59.  
  60. RFC 1137           E-Mail Address and Quoted Strings       December 1989
  61.  
  62.  
  63.    Restricted RFC 822
  64.  
  65.       This implies a subset of RFC 822 addressing.  The quoted-string
  66.       form of local-part need not be supported.  Standard UUCP mail
  67.       transfer falls into this category.  Restricted RFC 822 is
  68.       undesirable, but in practice it exists in many places.
  69.  
  70.       When a message is transferred from full RFC 822 to restricted RFC
  71.       822, and address forms used in full RFC 822 are involved, message
  72.       loss may occur (e.g., it may not be possible to return an error
  73.       message).  This RFC describes a quoting mechanism which may be
  74.       used to map between full RFC 822 and restricted RFC 822, in order
  75.       to alleviate this problem.
  76.  
  77. 2.  Encoding
  78.  
  79.    The RFC 822 EBNF meta notation is used.  Any EBNF definitions taken
  80.    from RFC 822 are prefixed by the string "822.".
  81.  
  82.    The following EBNF is specified.
  83.  
  84.       atom-encoded    = *( a-char / a-encoded-char )
  85.       a-char          = <any CHAR except specials (other than "@"
  86.                               and "."), SPACE,
  87.                               CTL, "_", and "#">
  88.       a-encoded-char  = "_"                   ; (space)
  89.                       / "#u#"                 ; (_)
  90.                       / "#l#"                 ; <(>
  91.                       / "#r#"                 ; <)>
  92.                       / "#m#"                 ; (,)
  93.                       / "#c#"                 ; (:)
  94.                       / "#b#"                 ; (\)
  95.                       / "#h#"                 ; (#)
  96.                       / "#e#"                 ; (=)
  97.                       / "#s#"                 ; (/)
  98.                       / "#" 3DIGIT "#"
  99.  
  100.    The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is
  101.    interpreted in decimal as the corresponding ASCII character.  The
  102.    choice of special abbreviations (as opposed to decimal encoding)
  103.    provided is based on the manner in which this mapping is most
  104.    frequently used.  There are special encodings for each of the
  105.    PrintableString characters not in EBNF.a-char, except ".".  Space is
  106.    given a single character encoding, due to its (expected) frequency of
  107.    use, and backslash as the RFC 822 single quote character.
  108.  
  109.    This mapping is used to transform between the two forms of 822.word:
  110.    822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC
  111.  
  112.  
  113.  
  114. Kille                                                           [Page 2]
  115.  
  116. RFC 1137           E-Mail Address and Quoted Strings       December 1989
  117.  
  118.  
  119.    822).  To encode (full RFC 822 -> restricted RFC 822), first remove
  120.    any quoting from any 822.quoted-string.  Then, all EBNF.a-char are
  121.    used directly and all other CHAR are encoded as EBNF.a-encoded-char.
  122.  
  123.    To decode (restricted RFC 822 -> full RFC 822): if the address can be
  124.    parsed as EBNF.encoded-atom reverse the previous mapping.  If it
  125.    cannot be so parsed, map the characters directly.
  126.  
  127. 3.  Application
  128.  
  129.    This mapping should be used for all addresses, at the MTS or Header
  130.    level.  It is applied to the 822.local-part of the addresses.  For
  131.    example:
  132.  
  133.       Full RFC 822                       Restricted RFC 822
  134.  
  135.       Steve.Kille@cs.ucl.ac.uk     <->   Steve.Kille@cs.ucl.ac.uk
  136.       "Steve Kille"@cs.ucl.ac.uk   <->   Steve_Kille@cs.ucl.ac.uk
  137.       "argle#~"@blargle            <->   argle#h##126#@blargle
  138.  
  139. References
  140.  
  141.    [Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet
  142.    Text Messages", RFC 822, August 1982.
  143.  
  144.    [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",
  145.    RFC 976, February 1986.
  146.  
  147.    [Kille86a]  Kille, S., "Mapping Between X.400 and RFC 822",
  148.    UK Academic Community Report (MG.19), RFC 987, June 1986.
  149.  
  150. Security Considerations
  151.  
  152.    Security issues are not discussed in this memo.
  153.  
  154. Author's Address
  155.  
  156.    Steve Kille
  157.    University College London
  158.    Gower Street
  159.    WC1E 6BT
  160.    England
  161.  
  162.    Phone: +44-1-380-7294
  163.  
  164.    EMail: S.Kille@Cs.Ucl.AC.UK
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kille                                                           [Page 3]
  171.