Difference between revisions of "RFC1137"

From RFC-Wiki
imported>Admin
(Created page with " Network Working Group S. Kille Request for Comments: 1137 University College London Updates: [[RFC976|RFC ...")
 
Line 7: Line 7:
 
Network Working Group                                          S. Kille
 
Network Working Group                                          S. Kille
 
Request for Comments:  1137                    University College London
 
Request for Comments:  1137                    University College London
Updates:  [[RFC976|RFC 976]]                                         December 1989
+
Updates:  RFC 976                                          December 1989
  
  
          Mapping Between Full [[RFC822|RFC 822]] and [[RFC822|RFC 822]] with
+
            Mapping Between Full RFC 822 and RFC 822 with
                      Restricted Encoding
+
                          Restricted Encoding
  
 
Status of this Memo
 
Status of this Memo
  
This RFC suggests an electronic mail protocol mapping for the
+
  This RFC suggests an electronic mail protocol mapping for the
Internet community and UK Academic Community, and requests discussion
+
  Internet community and UK Academic Community, and requests discussion
and suggestions for improvements.  This memo does not specify an
+
  and suggestions for improvements.  This memo does not specify an
Internet standard.  Distribution of this memo is unlimited.
+
  Internet standard.  Distribution of this memo is unlimited.
  
This document describes a set of address mappings which will enable
+
  This document describes a set of address mappings which will enable
interworking between systems operating [[RFC822|RFC 822]] protocols in a general
+
  interworking between systems operating RFC 822 protocols in a general
manner, and those environments where transfer of [[RFC822|RFC 822]] messages
+
  manner, and those environments where transfer of RFC 822 messages
restricts the character set which can be used in addresses.  UUCP
+
  restricts the character set which can be used in addresses.  UUCP
transfer of [[RFC822|RFC 822]] messages is an important case of this
+
  transfer of RFC 822 messages is an important case of this
[Crocker82a, Horton86a].
+
  [Crocker82a, Horton86a].
  
 
Specification
 
Specification
  
This document specifies a mapping between two protocols.  This
+
  This document specifies a mapping between two protocols.  This
specification should be used when this mapping is performed on the
+
  specification should be used when this mapping is performed on the
Internet or in the UK Academic Community. This specification may be
+
  Internet or in the UK Academic Community. This specification may be
modified in the light of implementation experience, but no
+
  modified in the light of implementation experience, but no
substantial changes are expected.
+
  substantial changes are expected.
  
== Introduction ==
+
1.  Introduction
  
Some mail networks which use [[RFC822|RFC 822]] cannot support the full
+
  Some mail networks which use RFC 822 cannot support the full
character set required by all aspects of [[RFC822|RFC 822]].  This document
+
  character set required by all aspects of RFC 822.  This document
describes a symmetrical mapping between full [[RFC822|RFC 822]] addressing, and
+
  describes a symmetrical mapping between full RFC 822 addressing, and
a form for use on these networks.  Any addresses within the networks
+
  a form for use on these networks.  Any addresses within the networks
will not use the full [[RFC822|RFC 822]] addressing, and so any addresses
+
  will not use the full RFC 822 addressing, and so any addresses
encoded according to this standard will always represent remote
+
  encoded according to this standard will always represent remote
addresses.  This document derives from a mapping originally specified
+
  addresses.  This document derives from a mapping originally specified
in [[RFC987|RFC 987]] [Kille86a], where the domain of application was more
+
  in RFC 987 [Kille86a], where the domain of application was more
restricted.  Two terms are now defined:
+
  restricted.  Two terms are now defined:
  
Full [[RFC822|RFC 822]]
+
  Full RFC 822
  
  This implies full support for transfer to and from any legal RFC
+
      This implies full support for transfer to and from any legal RFC
  822 address.  In particular, the quoted-string form of local-part
+
      822 address.  In particular, the quoted-string form of local-part
  must be supported (e.g., <"Joe Soap"@foo.bar>).
+
      must be supported (e.g., <"Joe Soap"@foo.bar>).
  
  
  
  
 +
Kille                                                          [Page 1]
  
 +
RFC 1137          E-Mail Address and Quoted Strings      December 1989
  
Restricted [[RFC822|RFC 822]]
 
  
   This implies a subset of [[RFC822|RFC 822]] addressing.  The quoted-string
+
   Restricted RFC 822
  form of local-part need not be supported.  Standard UUCP mail
 
  transfer falls into this category.  Restricted [[RFC822|RFC 822]] is
 
  undesirable, but in practice it exists in many places.
 
  
  When a message is transferred from full [[RFC822|RFC 822]] to restricted RFC
+
      This implies a subset of RFC 822 addressing.  The quoted-string
  822, and address forms used in full [[RFC822|RFC 822]] are involved, message
+
      form of local-part need not be supported.  Standard UUCP mail
  loss may occur (e.g., it may not be possible to return an error
+
      transfer falls into this categoryRestricted RFC 822 is
  message)This RFC describes a quoting mechanism which may be
+
      undesirable, but in practice it exists in many places.
  used to map between full [[RFC822|RFC 822]] and restricted [[RFC822|RFC 822]], in order
 
  to alleviate this problem.
 
  
== Encoding ==
+
      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.
  
The [[RFC822|RFC 822]] EBNF meta notation is usedAny EBNF definitions taken
+
2Encoding
from [[RFC822|RFC 822]] are prefixed by the string "822.".
 
  
The following EBNF is specified.
+
  The RFC 822 EBNF meta notation is used.  Any EBNF definitions taken
 +
  from RFC 822 are prefixed by the string "822.".
  
   atom-encoded    = *( a-char / a-encoded-char )
+
   The following EBNF is specified.
  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
+
      atom-encoded    = *( a-char / a-encoded-char )
interpreted in decimal as the corresponding ASCII character. The
+
      a-char          = <any CHAR except specials (other than "@"
choice of special abbreviations (as opposed to decimal encoding)
+
                              and "."), SPACE,
provided is based on the manner in which this mapping is most
+
                              CTL, "_", and "#">
frequently used.  There are special encodings for each of the
+
      a-encoded-char = "_"                  ; (space)
PrintableString characters not in EBNF.a-char, except ".".  Space is
+
                      / "#u#"                ; (_)
given a single character encoding, due to its (expected) frequency of
+
                      / "#l#"                ; <(>
use, and backslash as the [[RFC822|RFC 822]] single quote character.
+
                      / "#r#"                ; <)>
 +
                      / "#m#"                ; (,)
 +
                      / "#c#"                ; (:)
 +
                      / "#b#"                ; (\)
 +
                      / "#h#"                ; (#)
 +
                      / "#e#"                 ; (=)
 +
                      / "#s#"                ; (/)
 +
                      / "#" 3DIGIT "#"
  
This mapping is used to transform between the two forms of 822.word:
+
  The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127, and is
822.quoted-string (restricted [[RFC822|RFC 822]]) and 822.atom (restricted RFC
+
  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
  
  
  
 +
Kille                                                          [Page 2]
  
822).  To encode (full [[RFC822|RFC 822]] -> restricted [[RFC822|RFC 822]]), first remove
+
RFC 1137          E-Mail Address and Quoted Strings      December 1989
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 [[RFC822|RFC 822]] -> full [[RFC822|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.
 
  
== Application ==
+
  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.
  
This mapping should be used for all addresses, at the MTS or Header
+
  To decode (restricted RFC 822 -> full RFC 822): if the address can be
level.  It is applied to the 822.local-part of the addressesFor
+
  parsed as EBNF.encoded-atom reverse the previous mappingIf it
example:
+
  cannot be so parsed, map the characters directly.
  
  Full [[RFC822|RFC 822]]                      Restricted [[RFC822|RFC 822]]
+
3.  Application
  
+
   This mapping should be used for all addresses, at the MTS or Header
  "Steve Kille"@cs.ucl.ac.uk  <->  [email protected]
+
  level.  It is applied to the 822.local-part of the addresses.  For
  "argle#~"@blargle            <->  argle#h##126#@blargle
+
  example:
 +
 
 +
      Full RFC 822                      Restricted RFC 822
 +
 
 +
 +
      "Steve Kille"@cs.ucl.ac.uk  <->  [email protected]
 +
      "argle#~"@blargle            <->  argle#h##126#@blargle
  
 
References
 
References
  
[Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet
+
  [Crocker82a]  Crocker, D., "Standard of the Format of ARPA Internet
Text Messages", [[RFC822|RFC 822]], August 1982.
+
  Text Messages", RFC 822, August 1982.
  
[Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",
+
  [Horton86a]  Horton, M., "UUCP Mail Interchange Format Standard",
[[RFC976|RFC 976]], February 1986.
+
  RFC 976, February 1986.
  
[Kille86a]  Kille, S., "Mapping Between X.400 and [[RFC822|RFC 822]]",
+
  [Kille86a]  Kille, S., "Mapping Between X.400 and RFC 822",
UK Academic Community Report (MG.19), [[RFC987|RFC 987]], June 1986.
+
  UK Academic Community Report (MG.19), RFC 987, June 1986.
  
 
Security Considerations
 
Security Considerations
  
Security issues are not discussed in this memo.
+
  Security issues are not discussed in this memo.
  
 
Author's Address
 
Author's Address
  
Steve Kille
+
  Steve Kille
University College London
+
  University College London
Gower Street
+
  Gower Street
WC1E 6BT
+
  WC1E 6BT
England
+
  England
 +
 
 +
  Phone: +44-1-380-7294
 +
 
 +
 +
 
 +
 
 +
 
  
Phone: +44-1-380-7294
 
  
EMail: S.Kille@Cs.Ucl.AC.UK
+
Kille                                                           [Page 3]

Revision as of 22:53, 22 September 2020




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>).



Kille [Page 1]

RFC 1137 E-Mail Address and Quoted Strings December 1989


  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


Kille [Page 2]

RFC 1137 E-Mail Address and Quoted Strings December 1989


  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
     [email protected]     <->   [email protected]
     "Steve Kille"@cs.ucl.ac.uk   <->   [email protected]
     "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: [email protected]



Kille [Page 3]