home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1026 < prev    next >
Text File  |  1991-04-21  |  7KB  |  235 lines
  1.  
  2. Network Working Group                                          S.E. Kille
  3. Request for Comments 1026                       University College London
  4.                                                            September 1987
  5.  
  6.                          Addendum to RFC 987
  7.  
  8.                  (Mapping between X.400 and RFC-822)
  9.  
  10.  
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC suggest a proposed protocol for the Internet community, and
  17.    requests discussion and suggestions for improvements.  Distribution
  18.    of this memo is unlimited.
  19.  
  20.    This document specifies a number of additions and corrections to
  21.    RFC-987, aka Mailgroup Note 19.
  22.  
  23.    The addendum carries equal weight to the original specification,
  24.    which must be used when this mapping is performed on the Internet or
  25.    in the UK Academic Community.  This mapping may also be used within
  26.    the RARE community in Europe.  This specification may be modified in
  27.    the light of implementation experience, but no substantial changes
  28.    are expected.
  29.  
  30. 1.  Errata
  31.  
  32.    -    In section 4.6.4, replace ".." with ".".
  33.  
  34.    -    In section 4.2.4, replace three references to 4.3.1 by
  35.         4.2.1, and one reference to 4.2.2 by 4.1.2.
  36.  
  37.    -    In section 5.2, replace "1  mailbox" with "1#mailbox",
  38.         "1 msg-id" with "1#msg-id" and "1 encoded-type" with
  39.         "1#encoded-type".
  40.  
  41. 2.  Component Ordering
  42.  
  43.    In most cases, ordering of O/R name components is not significant for
  44.    the mappings specified by this document.  However, Organisational
  45.    Units and Domain Defined Attributes are specified as SEQUENCE, in
  46.    P1.ORName, and so their order may be significant.  This specification
  47.    needs to take account of this in two ways:
  48.  
  49.    1)   To allow consistent mapping into the domain hierarchy
  50.  
  51.    2)   To ensure preservation of order over multiple mappings.
  52.  
  53.  
  54.  
  55.  
  56. Kille                                                           [Page 1]
  57.  
  58. RFC 1026                                                  September 1987
  59.  
  60.  
  61. There are three places where an order must be specified:
  62.  
  63.    1)   On the text encoding (std-orname) of P1.ORName as used in the
  64.         local-part of an RFC-822 address, the most significant component
  65.         must be on the RHS.  This applies only to those components which
  66.         may have multiple values (Organisational Unit, and Domain
  67.         Defined Attributes).  Other attributes may be presented in any
  68.         order. Note that in dmn-orname specified in Appendix F, this
  69.         ordering is already implied by the current ordering
  70.         requirements.
  71.  
  72.    2)   For the Organisational Units (OU) in P1.ORName, the first OU in
  73.         the SEQUENCE is the most signicicant.  This follows the
  74.         "natural" hierarchy of the specification of P1.ORName, where the
  75.         most significant components are defined first.
  76.  
  77.    3)   For the Domain Defined Attributes in P1.ORName, the First Domain
  78.         Defined Attribute in the SEQUENCE is the most significant.
  79.  
  80.    Note that although the ordering defined in 2) and 3) is mandatory for
  81.    this mapping, there are NO implications on ordering significance
  82.    within X.400.
  83.  
  84.    3.  Extensions To Deal with Omitted Components
  85.  
  86.    Implementation of RFC-987 has proved to be a little inflexible for
  87.    some naming strategies.  In particular, there are some difficulties
  88.    where Organisation or PRMD is omitted:
  89.  
  90.    The following sentence of RFC-987 should be removed: 4.2.1 (Page 27):
  91.    "If one of the hierarchical components is omitted ....  tuple).".
  92.  
  93.    The strategy proposed is to introduce the concept of explicit missing
  94.    components to the symmetrical mapping described in 4.2.1.
  95.    Essentially, a domain may be associated with an omitted attribute in
  96.    conjuction with several present ones.  When performing the
  97.    algorithmic insertion of components lower in the hierarchy, the
  98.    omitted value should be skipped.  For example, if "GMD.DFN" is
  99.    associated with "C=DE", "ADMD=DBP", "PRMD=GMD", and omitted
  100.    organisation, then "ZI.GMD.DFN" is mapped with "C=DE", "ADMD=DBP",
  101.    "PRMD=GMD", "OU=ZI".  It should be noted that attributes may have
  102.    null values, and that this is treated separately from omitted
  103.    attributes (whilst it would be bad practice to treat these two cases
  104.    differently, they must be allowed for in practice).
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. Kille                                                           [Page 2]
  116.  
  117. RFC 1026                                                  September 1987
  118.  
  119.  
  120.    To allow the mapping of null organisations to be represented in the
  121.    specification of Appendix F, the dmn-orname syntax is extended, so
  122.    that values may be given the symbol "@" (not a printable string
  123.    character). This corresponds to an omitted attribute. The new
  124.    definition is:
  125.  
  126.            dmn-orname      = dmn-part *( "." dmn-part )
  127.            dmn-part        = attribute "$" value
  128.            attribute       = standard-type
  129.                            / "~" dmn-printablestring
  130.            value           = dmn-printablestring
  131.                            / "@"
  132.            dmn-printablestring
  133.                            = *( dmn-char / dmn-pair )
  134.            dmn-char        = <ps-delim, and any ps-char except ".">
  135.            dmn-pair        = "."
  136.  
  137.    Appendix F - Format of address mapping tables
  138.  
  139.    A new Appendix F is defined as follows:
  140.  
  141.    There is a need to specify the association between the domain and
  142.    X.400 namespaces described in 4.2.1.  This is defined as a table
  143.    syntax, but the syntax is defined in a manner which makes it suitable
  144.    for use with domain nameservices (such as the Internet Domain
  145.    nameservers or the UK NRS).  The mapping is not symmetric, and so a
  146.    separate table is specified for each direction.  If multiple matches
  147.    are possible, the longest possible match should be used.
  148.  
  149.    Various restrictions are placed on the usage of dmn-orname:
  150.  
  151.    1)   Only C, ADMD, PRMD, O, and OU may be used.
  152.  
  153.    2)   There must be a strict ordering of all components, with the most
  154.         significant components on the RHS.
  155.  
  156.    3)   No components may be omitted from the hierarchy, although the
  157.         hierarchy may terminate at any level.  If the mapping is to an
  158.         omitted component, the "@" syntax is used.
  159.  
  160.    For domain -> X.400:
  161.  
  162.            domain-syntax "#" dmn-orname "#"
  163.  
  164.    Note that the trailing "#" is used for clarity, as the dmn-orname
  165.    syntax can lead to values with trailing blanks.
  166.  
  167.            For example:
  168.  
  169.            AC.UK#PRMD$DES.ADMD$BT.C$UK#
  170.            XEROX.COM#O$Xerox.ADMD$ATT.C$US#
  171.  
  172.  
  173.  
  174. Kille                                                           [Page 3]
  175.  
  176. RFC 1026                                                  September 1987
  177.  
  178.  
  179.            HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#
  180.  
  181.    For X.400 -> domain:
  182.  
  183.            dmn-orname "#" domain-syntax "#"
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233. Kille                                                           [Page 4]
  234.  
  235.