rfc1465.txt

中、英文RFC文档大全打包下载完全版 .

Eppenberger                                                    [Page 12]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                servers offer anonymous access with the account-name
                ANON.  Documenting an FTAM server with a Distinguished
                Name is only allowed if the server is registered in the
                directory.

      <Macro-definition> ::= "Macro: " 'Macro name' " " \
                            'Macro value' <CR>
                Presentation addresses without the usage of macros are
                generally unreadable.  RFC1278 suggests a few macros.
                All macros which are allowed in a community must be
                defined in the COMMUNITY document.  It is recommended
                to use the proposed macros in RFC1278 and add new ones
                if necessary:
                Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
                Macro: Janet-X25(80)      TELEX+00728722+X.25(80)+02+
                Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+

      <Connections> ::= {<mandatory-service>} \
                            {[<optional-service>]}
                Note that at least one mandatory service type is
                needed.

      <mandatory-service> ::= "Mandatory-Service: " \
                            <Service-type> <CR>

      <optional-service> ::= "Optional-Service: " \
                            <Service-type> <CR>

5.3 The RELAY-MTA document

      <RELAY-MTA-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <RELAY-MTA-document-Identifier> \
                            <RELAY-MTA-document-body>
                A RELAY-MTA document contains the full description of a
                single RELAY-MTA.  Only one community is allowed.
                Since some of the information is community dependent,
                it would not be easily possible to have a single
                RELAY-MTA document used in different communities.

      <RELAY-MTA-document-Identifier> ::= \
                            "RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>

      <RELAY-MTA-document-body> ::= <Status> <connection-info> \
                            <contact-info>

      <Status> ::= "Status: " ("primary" | "secondary") <CR>
                This defines if the RELAY-MTA has 'primary' or



Eppenberger                                                    [Page 13]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                'secondary' status.  See section 4.3 and 6 for more
                information.

      <connection-info> ::= <password> <RTS> \
                            {<called-connection><calling-connection>}\
                            [<system>] \
                            [<local-domain>] \
                            [<echo-server>]
                More than one set of connection information may be
                present for RELAY-MTAs supporting several networks and
                protocol stacks.

      <password> ::= "Password: " \
                            ("secret" | "none" | \
                            "value=\"" 'password' "\"") <CR>
                If the keyword none is present, then no password is
                sent with the MTAname when this MTA initiates an RTS
                connection or responds to an incoming connection.
                Password: none

                If the keyword secret is present, then the connection
                needs a password which is not made publicly available.
                (For example, a community might keep a list of the
                passwords at the central coordination point.  The list
                would then be faxed to the RELAY-MTA managers.)
                Password: secret

                A password must be documented using the
                value="password" notation.  The double quotes around
                the password are needed, consider the case of a single
                blank as a password.
                Password: value=" "
                Password: value="nume-n-ine"

      <RTS> ::= <dialog-mode> \
                            [<checkpoint-size> <window-size>]

      <dialog-mode> ::= "RTS-dialog-mode: " \
                            ("TWA" | "MONOLOGUE") <CR>

      <checkpoint-size> ::= "RTS-checkpoint-size: " \
                            'checkpoint size' <CR>

      <window-size> ::= "RTS-window-size: " \
                            'window size' <CR>

      <called-connection> ::= "Called-address: " \
                            <Service-type> "; " \



Eppenberger                                                    [Page 14]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                            <P-address> "; " <MTS> \
                            ["; " <Service-priority>] <CR>

      <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
                MTS-T:     mts-transfer
                MTS-TP:    mts-transfer-protocol
                MTS-TP-84: mts-transfer-protocol-1984
                See ISO 10021-6, Section 3, chapter 11.1 for more
                details on this matter.  X.400(84) systems only support
                mts-transfer-protocol-1984.

      <Service-priority> ::= 'Integer 0..99'
                The lowest Integer corresponds to the highest priority
                as in DNS.  It is possible to set different priorities
                for each service type.  This may be chosen, for
                example, to distribute the load amongst different
                networks according to their available bandwidth.

      <calling-connection> ::= "Calling-address: " \
                            <Service-type> "; " \
                            <P-address> <CR>
                Since called and calling network addresses may differ
                in certain configurations and some X.400 systems do
                validation on calling network addresses, it is
                important to have this information in the RELAY-MTA
                document.  (Note: a calling X.121 address might change
                if the X.25 switch is reconfigured.  This will stop a
                RELAY-MTA from connecting to other RELAY-MTAs using
                address validation without having changed anything at
                the higher layers!)

      <system> ::= "System: HW=" 'computer type' "; " \
                            "OS=" 'operating system' "; " \
                            "SW=" 'MHS  software' <CR>
                It is optional to provide HW/SW information.
                Experience, however, has shown that a number of
                communication problems were more easily identified and
                solved with this information present and up-to-date.

      <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
                This is a useful but optional extension to the
                documentation.
                The <MHS-subtree> is local to the RELAY-MTA.  The <MHS-
                subtree> attributes might be used together with
                S=nosuchuser; to do connectivity and availability
                tests.





Eppenberger                                                    [Page 15]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      <echo-server> ::= "EchoServer: " <X.400 address> <CR>
                Some of the RELAY-MTAs might offer an echo server
                functionality.  It does make sense to document this in
                the RELAY-MTA document for test purpose.  This field is
                optional.

      <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
                The contact details for the RELAY-MTA administrator can
                be found in the appropriate PERSON document.  It is
                possible to document a whole team using a distribution
                list if this is desired.  It is generally better to
                document one or more 'real' persons.

5.4 The DOMAIN document

      <DOMAIN-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <DOMAIN-document-body>

      <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
                            {<Relay>}

      <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
                Note that it is not allowed to have equal <Domain-
                entry> lines in different DOMAIN documents belonging to
                the same MHS community.  A Domain-entry line can only
                appear in one DOMAIN document.

      <OR-matching> ::=  ( "* " | "= " )
                This qualifier defines how the following OR address
                attributes should be handled for the routing algorithm.
                If a '*' is present, a destination address of a message
                is matched by the "Domain:" entry if at least the OR
                address attributes in the "Domain:" entry are equal to
                the destination address.
                If a "=" is present, a destination address of a message
                is matched by the "Domain:" entry if there are exactly
                the same OR attributes in the destination address as in
                the "Domain:" entry.  (This restriction works for OU4,
                OU3, OU2, OU1, O, P, A and C only.)
                Example:
                a) Domain: * P=switch; A=arcom; C=ch;
                b) Domain: = P=switch; A=arcom; C=ch;
                The address S=eppenberger; P=switch; A=arcom; C=ch;
                matches both cases, a) and b).
                The address S=eppenberger; O=unibe; P=switch; A=arcom;
                C=ch; matches only case a).




Eppenberger                                                    [Page 16]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
                This is the person responsible for the listed domains.
                His task is to get the agreement of the relaying
                RELAY-MTAs and keep the DOMAIN document up-to-date.
                This person is the only one authorized to make changes
                to this document.  Note that multiple administrators
                may be listed.

      <Relay> ::=         "Relay: " \
                            ( 'UniqueRELAY-MTAkey' | \
                            "Internet-SMTP" ) "; " \
                            <RELAY-MTA-Priority> <CR>
                The priority is used to define the sequence in which
                different RELAY-MTAs may be tried in case of failure.
                A lower integer corresponds to a higher priority as in
                DNS.  Priorities 0..49 are used to indicate backup
                RELAY-MTAs.  Priorities 50..99 are used for RELAY-MTAs
                not acting as backup but as relay service provider for
                a network service type not supported by the main
                RELAY-MTA.
                The keyword "Internet-SMTP" is a placeholder for an
                RFC1327 gateway connected to Internet. The RELAY-MTA
                manager selects a gateway of his choice.

      <RELAY-MTA-Priority> ::= <Integer 0..99>

5.5 The PERSON document

      <PERSON-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <PERSON-document-identifier> \
                            <PERSON-document-body>

      <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>

      <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
                            <Phone> <Fax> <Mail> <Operation>

      <Name>  ::= "Name: " 'name of person' <CR>
                The name of the person is given.  The issue of the
                character set problem is not addressed in this
                document.  Especially international communities should
                restrict themselves to IA5 or ASCII.

      <RFC822> ::= "RFC822: " <RFC-822-address> <CR>
                This is the RFC-822 address of the person.  It is often
                a big help to know the RFC822 address of someone, for
                example if the X.400 system is not reachable.  This is



Eppenberger                                                    [Page 17]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                also the reason why it is possible to provide multiple
                OR and RFC822 addresses.  The first one is considered
                the primary one.

6. Routing rules

   All the users within the MHS community have the right to send
   messages to each other.  The general agreement is that the RELAY-MTA
   infrastructure is used according to the following routing rules.
   More direct connections based on bilateral agreements are fully
   accepted.

   A primary or secondary RELAY-MTA must allow incoming connections from
   all other primary and secondary RELAY-MTAs with a common stack.
   Primary RELAY-MTAs must be able to connect to all other primary
   RELAY-MTAs which share a common stack.  A secondary RELAY-MTA must
   connect to at least one primary RELAY-MTA.

   A message arriving at a RELAY-MTA must either be sent to the next
   RELAY-MTA based on the DOMAIN documents of the MHS community or it is
   sent to an MTA closer to the destination based on local routing
   decisions.  The following algorithm must be used when forwarding a
   message to the next RELAY-MTA:

      1) Select the relevant DOMAIN document by searching for a match of
      the Recipient address in the message with the entries in the
      document.

      If your own RELAY-MTA appears in this list, this indicates one of
      the following:

      - You offered relay services for another RELAY-MTA with higher
        priority.  Continue with step 2 to decide on the next RELAY-MTA.

      - Your RELAY-MTA is the final destination according the DOMAIN
        document of your community.  You need to forward the message to
        the final destination according local routing information.

      2) From the list of RELAY-MTAs select those that have at least one
      common network service type with your own RELAY-MTA.

      3) Now delete all secondary RELAY-MTAs from the list where no
      direct connection is desired.  For remaining RELAY-MTAs in the
      list no difference is made anymore between primary and secondary
      status.

      4) Select from this reduced set of RELAY-MTAs the one with the