rfc1506.txt

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

          service elements exist only in one of the two worlds (e.g.,
          interpersonal notifications).

        - Partially supported: When similar service elements exist in
          both worlds, but with slightly different interpretations,
          some tricks may be needed to provide the service over the
          gateway border.

   Apart from mapping between the service elements, a gateway must also
   map the types and values assigned to these service elements.  Again,
   this may in certain cases be very simple, e.g., 'IA5 -> ASCII'. The
   most complicated example is mapping address spaces. The problem is
   that address spaces are not something static that can be defined
   within RFC 1327. Address spaces change continuously, and they are
   defined by certain addressing authorities, which are not always
   parallel in the RFC 822 and the X.400 world. A valid mapping between
   two addresses assumes however that there is 'administrative
   equivalence' between the two domains in which the addresses exist
   (see also [13]).

   The following basic mappings are defined in RFC 1327. When going from
   RFC 822 to X.400, an RFC 822 message and the associated 822- MTS
   information is always mapped into an IPM (MTA, MTS, and IPMS
   Services). Going from X.400 to RFC 822, an RFC 822 message and the
   associated 822-MTS information may be derived from:

        - A Report (MTA, and MTS Services)

        - An InterPersonal Notification (IPN) (MTA, MTS, and IPMS
          services)



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



        - An InterPersonal Message (IPM) (MTA, MTS, and IPMS services)

   Probes (MTA Service) have no equivalent in STD 10, RFC 821 or STD 11,
   RFC 822 and are thus handled by the gateway. The gateway's Probe
   confirmation should be interpreted as if the gateway were the final
   MTA to which the Probe was sent. Optionally, if the gateway uses RFC
   821 as an 822-MTS, it may use the results of the 'VRFY' command to
   test whether it would be able to deliver (or forward) mail to the
   mailbox under probe.

   MTS Messages containing Content Types other than those defined by the
   IPMS are not mapped by the gateway, and should be rejected at the
   gateway.

   Some basic examples of mappings between service elements are listed
   below.

    Service elements:

         RFC 822         X.400
         ------------------------------------------------
         Reply-To:       IPMS.Heading.reply-recipients
         Subject:        IPMS.Heading.subject
         In-Reply-To:    IPMS.Heading.replied-to-ipm
         References:     IPMS.Heading.related-IPMs
         To:             IPMS.Heading.primary-recipients
         Cc:             IPMS.Heading.copy-recipients

    Service element types:

         RFC 822         X.400
         ------------------------------------------------
         ASCII           PrintableString
         Boolean         Boolean

    Service element values:

         RFC 822         X.400
         ------------------------------------------------
         oh_dear         oh(u)dear
         False           00000000

   There are some mappings between service elements that are rather
   tricky and important enough to mention in this tutorial. These are
   the mappings of origination-related headers and some envelope fields:





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


    RFC 822 -> X.400:

        - If Sender: is present, Sender: is mapped to
          IPMS.Heading.originator, and From: is mapped to
          IPMS.Heading.authorizing-users. If not, From: is mapped to
          IPMS.Heading.originator.

    X.400 -> RFC 822

        - If IPMS.Heading.authorizing-users is present,
          IPMS.Heading.originator is mapped to Sender:, and
          IPMS.Heading.authorizing-users is mapped to From: . If not,
          IPMS.Heading.originator is mapped to From:.

    Envelope attributes

        - RFC 1327 doesn't define how to map the MTS.OriginatorName and
          the MTS.RecipientName (often referred to as the P1.originator
          and P1.recipient), since this depends on which underlying 822-
          MTS is used. In the very common case that RFC 821 (SMTP) is
          used for this purpose, the mapping is normally as follows:

            MTS.Originator-name <->   MAIL FROM:
            MTS.Recipient-name  <->   RCPT TO:

   For more details, refer to RFC 1327, chapters 2.2 and 2.3.

3. Address mapping

   As address mapping is often considered the most complicated part of
   mapping between service element values, this subject is given a
   separate chapter in this tutorial.

   Both RFC 822 and X.400 have their own specific address formats. RFC
   822 addresses are text strings (e.g., "[e-mail]"), whereas X.400
   addresses are binary encoded sets of attributes with values. Such
   binary addresses can be made readable for a human user by a number of
   notations; for instance:

        C=zz
        ADMD=ade
        PRMD=fhbo
        O=a bank
        S=plork
        G=mary

   The rest of this chapter deals with addressing issues and mappings
   between the two address forms in more detail.



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


3.1. X.400 addresses

   As already stated above, an X.400 address is modelled as a set of
   attributes. Some of these attributes are mandatory, others are
   optional. Each attribute has a type and a value, e.g., the Surname
   attribute has type IA5text, and an instance of this attribute could
   have the value 'Kille'. Attributes are divided into Standard
   Attributes (SAs) and Domain Defined Attributes (DDAs).

   X.400 defines four basic forms of addresses ([17], 18.5), of which
   the 'Mnemonic O/R Address' is the form that is most used, and is the
   only form that is dealt with in this tutorial. This is roughly the
   same address format as what in the 84 version was known as 'O/R
   names: form 1, variant 1' ([16] 3.3.2).

3.1.1. Standard Attributes

   Standard Attributes (SAs) are attributes that all X.400 installations
   are supposed to 'understand' (i.e., use for routing), for example:
   'country name', 'given name' or 'organizational unit'.  The most
   commonly used SAs in X.400(84) are:

        surName (S)
        givenName (G)
        initials (I*) (Zero or more)
        generationQualifier (GQ)
        OrganizationalUnits (OU1 OU2 OU3 OU4)
        OrganizationName (O)
        PrivateDomainName (PRMD)
        AdministrationDomainName (ADMD)
        CountryName (C)

   The combination of S, G, I* and GQ is often referred to as the
   PersonalName (PN).

   Although there is no hierarchy (of addressing authorities) defined by
   the standards, the following hierarchy is considered natural:

        PersonalName < OU4 < OU3 < OU2 < OU1 < O < P < A < C

   In addition to the SAs listed above, X.400(88) defines some extra
   attributes, the most important of which is

        Common Name (CN)

   CN can be used instead of or even together with PN. The problem in
   X.400(84) was that PN (S G I* GQ) was well suited to represent
   persons, but not roles and abstract objects, such as distribution



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


   lists. Even though postmaster clearly is a role, not someone's real
   surname, it is quite usual in X.400(84) to address a postmaster with
   S=postmaster. In X.400(88), the same postmaster would be addressed
   with CN=postmaster .

   The attributes C and ADMD are mandatory (i.e., they must be present),
   and may not be empty. At least one of the attributes PRMD, O, OU, PN
   and CN must be present.

   PRMD and ADMD are often felt to be routing attributes that don't
   really belong in addresses. As an example of how such address
   attributes can be used for the purpose of routing, consider two
   special values for ADMD:

        - ADMD=0; (zero) should be interpreted as 'the PRMD in this
          address is not connected to any ADMD'

        - ADMD= ; (single SPACE) should be interpreted as 'the PRMD in
          this address is reachable via any ADMD in this country'. It
          is expected that ISO will express this 'any' value by means
          of a missing ADMD attribute in future versions of MOTIS.
          This representation can uniquely identify the meaning 'any',
          as a missing or empty ADMD field as such is not allowed.

   Addresses are defined in X.400 using the Abstract Syntax Notation One
   (ASN.1). X.409 defines how definitions in ASN.1 should be encoded
   into binary format. Note that the meaning, and thus the ASN.1
   encoding, of a missing attribute is not the same as that of an empty
   attribute. In addressing, this difference is often represented as
   follows:

        - PRMD=; means that this attribute is present in the address,
          but its value is empty. Since this is not very useful, it's
          hardly ever used. The only examples the author knows of
          were caused by mail managers who should have had this
          tutorial before they started defining their addresses :-)

        - PRMD=@; means that this attribute is not present in the
          address. {NB. This is only necessary if an address notation
          (see 3.1.3) requires that every single attribute in the
          hierarchy is somehow listed. Otherwise, a missing attribute
          can of course be represented by simply not mentioning it.
          This means that this syntax is mostly used in mapping rules,
          not by end users.}

   Addresses that only contain SAs are often referred to as Standard
   Attribute Addresses (SAAs).




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


3.1.2. Domain Defined Attributes

   Domain Defined Attributes (DDAs) can be used in addition to Standard
   Attributes. An instance of a DDA consists of a type and a value. DDAs
   are meant to have a meaning only within a certain context (originally
   this was supposed to be the context of a certain management domain,
   hence the name DDA), such as a company context.

   As an example, a company might want to define a DDA for describing
   internal telephone numbers: DDA type=phone value=9571.

   A bit tricky is the use of DDAs to encode service element types or
   values that are only available on one side of a service gateway.  The
   most important examples of such usage are defined in:

       RFC 1327 (e.g., DDA type=RFC-822 value=u(u)ser(a)isode.com)

       RFC 1328 (e.g., DDA type=CommonName value=mhs-discussion-list)

   Addresses that contain both SAs and DDAs are often referred to as DDA
   addresses.

3.1.3. X.400 address notation

   X.400 only prescribes the binary encoding of addresses, it doesn't
   standardise how such addresses should be written on paper or what
   they should look like in a user interface on a computer screen.
   There exist a number of recommendations for X.400 address
   representation though.

  - JTC proposed an annex to CCITT Rec. F.401 and ISO/IEC 10021-2,
    called 'Representation of O/R addresses for human usage'. According
    to this proposal, an X.400 address would look as follows:

    G=jo; S=plork; O=a bank; OU1=owe; OU2=you; P=fhbo; A=ade; C=zz

      Note that in this format, the order of O and the OUs is exactly
      the opposite of what one would expect intuitively (the attribute
      hierarchy is increasing from left to right, except for the O and
      OUs, where it's right to left. The reasoning behind this is that
      this sequence is following the example of a postal address). This
      proposal has been added (as a recommendation) to the 1992 version
      of the standards.

  - Following what was originally used in the DFN-EAN software, most
    EAN versions today use an address representation similar to the JTC
    proposal, with a few differences:




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


            - natural ordering for O and OUs
            - no numbering of OUs.