RFC1026 Addendum to RFC 987: (Mapping between X

1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822). S.E.Kille. September 1987. (Format: TXT=7117 bytes) (Obsoleted by RFC2156, RFC1327) (Updates RFC0987) (Updated by RFC1138, RFC1148) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group                                          S.E. Kille
Request for Comments 1026                       University College London
                                                           September 1987

                         Addendum to RFC 987

                 (Mapping between X.400 and RFC-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 to
   RFC-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

   -    In section 4.6.4, replace ".." with ".".

   -    In section 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.

   -    In section 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 1987


There 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 an RFC-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 in Appendix 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 of RFC-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 of RFC-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 of Appendix 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        = 
           dmn-pair        = "."

   Appendix F - Format of address mapping tables

   A new Appendix 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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Raspberry Piで使えるmicroSDカードの容量(最小容量 最大容量)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る