rfc1506.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            - allows writing ADMD and PRMD instead of A and P

    The address in the example above could, in EAN, be represented as:

    G=jo; S=plork; OU=you; OU=owe; O=a bank; PRMD=fhbo; ADMD=ade; C=zz

    This DFN-EAN format is still often referred to as _the_ 'readable
    format'.

  - The RARE Working Group on Mail and Messaging, WG-MSG, has made a
    recommendation that is very similar to the DFN-EAN format, but with
    the hierarchy reversed. Further, ADMD and PRMD are used instead of
    A and P. This results in the address above being represented as:

    C=zz; ADMD=ade; PRMD=fhbo; O=a bank; OU=owe; OU=you; S=plork; G=jo

    This format is recognised by most versions of the EAN software. In
    the R&D community, this is one of the most popular address
    representations for business cards, letter heads, etc. It is also
    the format that will be used for the examples in this tutorial.
    (NB. The syntax used here for describing DDAs is as follows:
    DD.'type'='value', e.g., DD.phone=9571)

  - RFC 1327 defines a slash separated address representation:

    /G=jo/S=plork/OU=you/OU=owe/O=a bank/P=fhbo/A=ade/C=zz/

    Not only is this format used by the PP software, it is also
    widespread for business cards and letter heads in the R&D
    community.

  - RFC 1327 finally defines yet another format for X.400 _domains_
    (not for human users):

    OU$you.OU$owe.O$a bank.P$fhbo.A$ade.C$zz

    The main advantage of this format is that it is better machine-
    parseble than the others, which also immediately implies its main
    disadvantage: it is barely readable for humans. Every attribute
    within the hierarchy should be listed, thus a missing attribute
    must be represented by the '@' sign
    (e.g., $a bank.P$@.A$ade.C$zz).

  - Paul-Andre Pays (INRIA) has proposed a format that combines the
    readability of the JTC format with the parsebility of the RFC 1327
    domain format. Although a number of operational tools within the GO-



RARE Working Group on Mail and Messaging (WG-MSG)              [Page 18]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


    MHS community are already based on (variants of) this proposal, its
    future is still uncertain.

3.2. RFC 822 addresses

   An RFC 822 address is an ASCII string of the following form:

        localpart@domainpart

    "domainpart" is sub-divided into

    domainpart = sdom(n).sdom(n-1)....sdom(2).sdom(1).dom

    "sdom" stands for "subdomain", "dom" stands for "top-level-domain".

    "localpart" ;is normally a login name, and thus typically is a
    surname or an abbreviation for this. It can also designate a local
    distribution list.

    The hierarchy (of addressing authorities) in an RFC 822 address is
    as follows:

        localpart < sdom(n) < sdom(n-1) <...< dom

    Some virtual real-life examples:

        [e-mail]
        [e-mail]
        [e-mail]

    In the above examples, 'nl', 'dk', and 'edu' are valid,
    registered, top level domains. Note that some networks that have
    their own addressing schemes are also reachable by way of 'RFC
    822-like' addressing. Consider the following addresses:

        oops!user          (a UUCP address)
        V13ENZACC@CZKETH5A (a BITNET address)

    These addresses can be expressed in RFC 822 format:

        [e-mail]
        [e-mail]

   Note that the domains '.uucp' and '.bitnet' have no registered
   Internet routing.  Such addresses must always be routed to a gateway
   (how this is done is outside the scope of this tutorial).

   As for mapping such addresses to X.400, there is no direct mapping



RARE Working Group on Mail and Messaging (WG-MSG)              [Page 19]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


   defined between X.400 on the one hand and UUCP and BITNET on the
   other, so they are normally mapped to RFC 822 style first, and then
   to X.400 if needed.

3.3. RFC 1327 address mapping

   Despite the difference in address formats, the address spaces defined
   by RFC 822 and X.400 are quite similar. The most important parallels
   are:

        - both address spaces are hierarchical
        - top level domains and country codes are often the same
        - localparts and surnames are often the same

   This similarity can of course be exploited in address mapping
   algorithms. This is also done in RFC 1327 (NB only in the exception
   mapping algorithm. See chapter 3.3.2).

   Note that the actual mapping algorithm is much more complicated than
   shown below. For details, see RFC 1327, chapter 4.

3.3.1. Default mapping

   The default RFC 1327 address mapping can be visualised as a function
   with input and output parameters:

          address information of the gateway performing the mapping
                                      |
                                      v
                             +-----------------+
        RFC 822 address <--->| address mapping | <---> X.400 address
                             +-----------------+

   I.e., to map an address from X.400 to RFC 822 or vice versa, the only
   extra input needed is the address information of the local gateway.

3.3.1.1. X.400 -> RFC 822

   There are two kinds of default address mapping from X.400 to RFC 822:
   one to map a real X.400 address to RFC 822, and another to decode an
   RFC 822 address that was mapped to X.400 (i.e., to reverse the
   default RFC 822 -> X.400 mapping).

   To map a real X.400 address to RFC 822, the slash separated notation
   of the X.400 address (see chapter 3.1.) is mapped to 'localpart', and
   the local RFC 822 domain of the gateway that performs the mapping is
   used as the domain part. As an example, the gateway 'gw.switch.ch'
   would perform the following mappings:



RARE Working Group on Mail and Messaging (WG-MSG)              [Page 20]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


        C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
        /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch

        C=zz; ADMD=ade; PRMD=fhbo; O=a bank; S=plork->
        "/C=zz/ADMD=ade/PRMD=fhbo/O=a bank/S=plork/"@gw.switch.ch

   The quotes in the second example are mandatory if the X.400 address
   contains spaces, otherwise the syntax rules for the RFC 822 localpart
   would be violated.

   This default mapping algorithm is generally referred to as 'left-
   hand-side encoding'.

   To reverse the default RFC 822 -> X.400 mapping (see chapter
   3.3.1.2): if the X.400 address contains a DDA of the type RFC-822,
   the SAs can be discarded, and the value of this DDA is the desired
   RFC 822 address (NB. Some characters in the DDA value must be decoded
   first. See chapter 3.3.1.2.). For example, the gateway

        DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
        ->
        [e-mail]

3.3.1.2. RFC 822 -> X.400

   There are also two kinds of default address mapping from RFC 822 to
   X.400: one to map a real RFC 822 address to X.400, and another to
   decode an X.400 address that was mapped to RFC 822 (i.e., to reverse
   the default X.400 -> RFC 822 mapping).

   To map a real RFC 822 address to X.400, the RFC 822 address is
   encoded in a DDA of type RFC-822 , and the SAs of the local gateway
   performing the mapping are added to form the complete X.400 address.
   This mapping is generally referred to as 'DDA mapping'. As an
   example, the gateway 'C=nl; ADMD=tlec; PRMD=GW' would perform the
   following mapping:

        [e-mail]  ->
        DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW

   As for the encoding/decoding of RFC 822 addresses in DDAs, it is
   noted that RFC 822 addresses may contain characters (@ ! % etc.) that
   cannot directly be represented in a DDA. DDAs are of the restricted
   character set type 'PrintableString', which is a subset of IA5
   (=ASCII). Characters not in this set need a special encoding. Some
   examples (For details, refer to RFC 1327, chapter 3.4.):





RARE Working Group on Mail and Messaging (WG-MSG)              [Page 21]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


        100%name@address   -> DD.RFC-822;=100(p)name(a)address
        u_ser!name@address -> DD.RFC-822;=u(u)ser(b)name(a)address

   To decode an X.400 address that was mapped to RFC 822: if the RFC 822
   address has a slash separated representation of a complete X.400
   mnemonic O/R address in its localpart, that address is the result of
   the mapping. As an example, the gateway 'gw.switch.ch' would perform
   the following mapping:

        /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/G=mary/@gw.switch.ch
        ->
        C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; G=mary

3.3.2. Exception mapping according to mapping tables

   Chapter 3.3.1. showed that it is theoretically possible to use RFC
   1327 with default mapping only. Although this provides a very simple,
   straightforward way to map addresses, there are some very good
   reasons not to use RFC 1327 this way:

        - RFC 822 users are used to writing simple addresses of the
          form 'localpart@domainpart'. They often consider X.400
          addresses, and thus also the left-hand-side encoded
          equivalents, as unnecessarily long and complicated. They
          would rather be able to address an X.400 user as if she had a
          'normal' RFC 822 address. For example, take the mapping

            C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork;     ->
            /C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch

          from chapter 3.3.1.1. RFC 822 users would find it much more
          'natural' if this address could be expressed in RFC 822 as:

            [e-mail]

        - X.400 users are used to using X.400 addresses with SAs only.
          They often consider DDA addresses as complicated, especially
          if they have to encode the special characters, @ % ! etc,
          manually. They would rather be able to address an RFC 822
          user as if he had a 'normal' X.400 address. For example, take
          the mapping

            [e-mail]
            ->
            DD.RFC-822=bush(a)dole.us;
            C=nl; ADMD= ; PRMD=tlec; O=gateway

          from chapter 3.3.1.2. X.400 users would find it much more



RARE Working Group on Mail and Messaging (WG-MSG)              [Page 22]

RFC 1506        X.400-Internet Mail Gatewaying Tutorial      August 1993


          'natural' if this address could be expressed in X.400 as:

            C=us; ADMD=dole; S=bush

        - Many organisations are using both RFC 822 and X.400
          internally, and still want all their users to have a simple,
          unique address in both mail worlds. Note that in the default
          mapping, the mapped form of an address completely depends on
          which gateway  performed the mapping. This also results in a
          complication of a more technical nature:

        - The tricky 'third party problem'. This problem need not
          necessarily be understood to read the rest of this chapter.
          If it looks too complicated, please feel free to skip it
          until you are more familiar with the basics.

          The third party problem is a routing problem caused by
          mapping. As an example for DDA mappings (the example holds
          just as well for left-hand-side encoding), consider the
          following situation (see Fig. 3.1.): RFC 822 user X in
          country A sends a message to two recipients: RFC 822 user Y,
          and X.400 user Z, both in country B:

            From: X@A
            To:   Y@B ,
                  /C=B/.../S=Z/@GW.A

          Since the gateway in country A maps all addresses in the
          message, Z will see both X's and Y's address as DDA-encoded
          RFC 822 addresses, with the SAs of the gateway in country A:

            From: DD.RFC-822=X(a)A; C=A;....;O=GW
            To:   DD.RFC-822=Y(a)B; C=A;....;O=GW ,
                  C=B;...;S=Z