RFC 1137: Mapping between full RFC 822 and RFC 822 with restricted encoding

  • S. Kille
Historic
Network Working Group                                           S. Kille
Request for Comments:  1137                    University College London
Updates:  RFC                                           December 1989


             Mapping Between Full  and  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  protocols in a general
   manner, and those environments where transfer of  messages
   restricts the character set which can be used in addresses.  UUCP
   transfer of  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  cannot support the full
   character set required by all aspects of .  This document
   describes a symmetrical mapping between full  addressing, and
   a form for use on these networks.  Any addresses within the networks
   will not use the full  addressing, and so any addresses
   encoded according to this standard will always represent remote
   addresses.  This document derives from a mapping originally specified
   in  [Kille86a], where the domain of application was more
   restricted.  Two terms are now defined:

   Full 

      This implies full support for transfer to and from any legal 
       address.  In particular, the quoted-string form of local-part
      must be supported (e.g., <"Joe Soap"@foo.bar>).




Kille                                                           [Page 1]


           E-Mail Address and Quoted Strings       December 1989


   Restricted 

      This implies a subset of  addressing.  The quoted-string
      form of local-part need not be supported.  Standard UUCP mail
      transfer falls into this category.  Restricted  is
      undesirable, but in practice it exists in many places.

      When a message is transferred from full  to restricted 
      , and address forms used in full  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  and restricted , in order
      to alleviate this problem.

2.  Encoding

   The  EBNF meta notation is used.  Any EBNF definitions taken
   from  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  single quote character.

   This mapping is used to transform between the two forms of 822.word:
   822.quoted-string (restricted ) and 822.atom (restricted RFC



Kille                                                           [Page 2]


           E-Mail Address and Quoted Strings       December 1989


   822).  To encode (full  -> restricted ), 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  -> full ): 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                        Restricted 

      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", , August 1982.

   [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",
   , February 1986.

   [Kille86a]  Kille, S., "Mapping Between X.400 and ",
   UK Academic Community Report (MG.19), , 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





Kille                                                           [Page 3]

RFC 1137: Mapping between full RFC 822 and RFC 822 with restricted encoding

Historic