home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1137.txt < prev    next >
Text File  |  1996-05-07  |  6KB  |  95 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Kille Request for Comments:  1137                    University College London Updates:  RFC 976                                          December 1989 
  8.  
  9.               Mapping Between Full RFC 822 and RFC 822 with                           Restricted Encoding 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15.    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]. 
  16.  
  17. Specification 
  18.  
  19.    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. 
  20.  
  21. 1.  Introduction 
  22.  
  23.    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: 
  24.  
  25.    Full RFC 822 
  26.  
  27.       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>). 
  28.  
  29.  
  30.  
  31.  Kille                                                           [Page 1] 
  32.  RFC 1137           E-Mail Address and Quoted Strings       December 1989 
  33.  
  34.     Restricted RFC 822 
  35.  
  36.       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. 
  37.  
  38.       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. 
  39.  
  40. 2.  Encoding 
  41.  
  42.    The RFC 822 EBNF meta notation is used.  Any EBNF definitions taken    from RFC 822 are prefixed by the string "822.". 
  43.  
  44.    The following EBNF is specified. 
  45.  
  46.       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 "#" 
  47.  
  48.    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. 
  49.  
  50.    This mapping is used to transform between the two forms of 822.word:    822.quoted-string (restricted RFC 822) and 822.atom (restricted RFC 
  51.  
  52.  
  53.  
  54. Kille                                                           [Page 2] 
  55.  RFC 1137           E-Mail Address and Quoted Strings       December 1989 
  56.  
  57.     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. 
  58.  
  59.    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. 
  60.  
  61. 3.  Application 
  62.  
  63.    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: 
  64.  
  65.       Full RFC 822                       Restricted RFC 822 
  66.  
  67.       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 
  68.  
  69. References 
  70.  
  71.    [Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet    Text Messages", RFC 822, August 1982. 
  72.  
  73.    [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",    RFC 976, February 1986. 
  74.  
  75.    [Kille86a]  Kille, S., "Mapping Between X.400 and RFC 822",    UK Academic Community Report (MG.19), RFC 987, June 1986. 
  76.  
  77. Security Considerations 
  78.  
  79.    Security issues are not discussed in this memo. 
  80.  
  81. Author's Address 
  82.  
  83.    Steve Kille    University College London    Gower Street    WC1E 6BT    England 
  84.  
  85.    Phone: +44-1-380-7294 
  86.  
  87.    EMail: S.Kille@Cs.Ucl.AC.UK 
  88.  
  89.  
  90.  
  91.  
  92.  
  93. Kille                                                           [Page 3] 
  94.  
  95.