Movatterモバイル変換

Network Working Group                                          S.E. KilleRequest for Comments 1026                       University College London                                                           September 1987Addendum toRFC 987                 (Mapping between X.400 andRFC-822)Status of this Memo   This RFC suggest a proposed protocol for the Internet community, and   requests discussion and suggestions for improvements.  Distribution   of this memo is unlimited.   This document specifies a number of additions and corrections toRFC-987, aka Mailgroup Note 19.   The addendum carries equal weight to the original specification,   which must be used when this mapping is performed on the Internet or   in the UK Academic Community.  This mapping may also be used within   the RARE community in Europe.  This specification may be modified in   the light of implementation experience, but no substantial changes   are expected.1.  Errata   -    Insection 4.6.4, replace ".." with ".".   -    Insection 4.2.4, replace three references to 4.3.1 by        4.2.1, and one reference to 4.2.2 by 4.1.2.   -    Insection 5.2, replace "1  mailbox" with "1#mailbox",        "1 msg-id" with "1#msg-id" and "1 encoded-type" with        "1#encoded-type".2.  Component Ordering   In most cases, ordering of O/R name components is not significant for   the mappings specified by this document.  However, Organisational   Units and Domain Defined Attributes are specified as SEQUENCE, in   P1.ORName, and so their order may be significant.  This specification   needs to take account of this in two ways:   1)   To allow consistent mapping into the domain hierarchy   2)   To ensure preservation of order over multiple mappings.Kille                                                           [Page 1]

RFC 1026                                                  September 1987There are three places where an order must be specified:   1)   On the text encoding (std-orname) of P1.ORName as used in the        local-part of anRFC-822 address, the most significant component        must be on the RHS.  This applies only to those components which        may have multiple values (Organisational Unit, and Domain        Defined Attributes).  Other attributes may be presented in any        order. Note that in dmn-orname specified inAppendix F, this        ordering is already implied by the current ordering        requirements.   2)   For the Organisational Units (OU) in P1.ORName, the first OU in        the SEQUENCE is the most signicicant.  This follows the        "natural" hierarchy of the specification of P1.ORName, where the        most significant components are defined first.   3)   For the Domain Defined Attributes in P1.ORName, the First Domain        Defined Attribute in the SEQUENCE is the most significant.   Note that although the ordering defined in 2) and 3) is mandatory for   this mapping, there are NO implications on ordering significance   within X.400.   3.  Extensions To Deal with Omitted Components   Implementation ofRFC-987 has proved to be a little inflexible for   some naming strategies.  In particular, there are some difficulties   where Organisation or PRMD is omitted:   The following sentence ofRFC-987 should be removed: 4.2.1 (Page 27):   "If one of the hierarchical components is omitted ....  tuple).".   The strategy proposed is to introduce the concept of explicit missing   components to the symmetrical mapping described in 4.2.1.   Essentially, a domain may be associated with an omitted attribute in   conjuction with several present ones.  When performing the   algorithmic insertion of components lower in the hierarchy, the   omitted value should be skipped.  For example, if "GMD.DFN" is   associated with "C=DE", "ADMD=DBP", "PRMD=GMD", and omitted   organisation, then "ZI.GMD.DFN" is mapped with "C=DE", "ADMD=DBP",   "PRMD=GMD", "OU=ZI".  It should be noted that attributes may have   null values, and that this is treated separately from omitted   attributes (whilst it would be bad practice to treat these two cases   differently, they must be allowed for in practice).Kille                                                           [Page 2]

RFC 1026                                                  September 1987   To allow the mapping of null organisations to be represented in the   specification ofAppendix F, the dmn-orname syntax is extended, so   that values may be given the symbol "@" (not a printable string   character). This corresponds to an omitted attribute. The new   definition is:           dmn-orname      = dmn-part *( "." dmn-part )           dmn-part        = attribute "$" value           attribute       = standard-type                           / "~" dmn-printablestring           value           = dmn-printablestring                           / "@"           dmn-printablestring                           = *( dmn-char / dmn-pair )           dmn-char        = <ps-delim, and any ps-char except ".">           dmn-pair        = "."Appendix F - Format of address mapping tables   A newAppendix F is defined as follows:   There is a need to specify the association between the domain and   X.400 namespaces described in 4.2.1.  This is defined as a table   syntax, but the syntax is defined in a manner which makes it suitable   for use with domain nameservices (such as the Internet Domain   nameservers or the UK NRS).  The mapping is not symmetric, and so a   separate table is specified for each direction.  If multiple matches   are possible, the longest possible match should be used.   Various restrictions are placed on the usage of dmn-orname:   1)   Only C, ADMD, PRMD, O, and OU may be used.   2)   There must be a strict ordering of all components, with the most        significant components on the RHS.   3)   No components may be omitted from the hierarchy, although the        hierarchy may terminate at any level.  If the mapping is to an        omitted component, the "@" syntax is used.   For domain -> X.400:           domain-syntax "#" dmn-orname "#"   Note that the trailing "#" is used for clarity, as the dmn-orname   syntax can lead to values with trailing blanks.           For example:           AC.UK#PRMD$DES.ADMD$BT.C$UK#           XEROX.COM#O$Xerox.ADMD$ATT.C$US#Kille                                                           [Page 3]

RFC 1026                                                  September 1987           HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#   For X.400 -> domain:           dmn-orname "#" domain-syntax "#"Kille                                                           [Page 4]