rfc1465.txt

RFC 的详细文档！

5. The documents

   The definition is given in BNF-like syntax.  The following
   conventions are used:


    |    means choice

    \    is used for continuation of a definition over several lines



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



    []   means optional

    {}   means repeated one or more times

    ()   is used to group choices

    \"   is used for double quotes in a text string

    <CR> is a Carriage Return and means that the next section starts
         on its own line.

   The definition is complete only to a certain level of detail.  Below
   this level, all expressions are to be replaced with text strings.
   Expressions without more detailed definition are marked with single
   quotes '.  The format and semantics should be clear from the names of
   the expressions and the comments given.

   Wherever the BNF definition requires a single blank, multiple blanks
   may be used to increase the readability.  Please note that for some
   field values the number of spaces is significant.

   Lines exceeding 80 characters should be wrapped at any convenient
   blank except at blanks which are significant.  The line is continued
   with at least one leading blank.

   Comments may be placed anywhere in the document but only on separate
   lines and without splitting wrapped lines.  Such a comment line must
   either start with a '#' sign followed by white space and the comment
   or consist of a single '#' on a single line.

   The documents must follow the case of the strings defined in BNF.
   Note that some values, especially connection parameters like TSEL or
   MTA password are case dependant too.

   The BNF definitions are ordered top-down.  See Appendix B for an
   alphabetically sorted list.

   A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and
   PERSON documents belong together.  The detailed definitions can be
   found in the following chapters.

      <X.400 routing coordination document set> ::= \
                            <COMMUNITY-document> \
                            { <RELAY-MTA-document> } \
                            { <DOMAIN-document> } \
                            { <PERSON-document> }




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


5.1 Common Definitions

      <DirectoryName> ::= 'Distinguished Name'
                The string representation of a Distinguished Name is
                defined in the RFCxxxx.  If a Distinguished Name is
                used as a key in the documents, then the information
                can be fetched from the directory instead of checking
                the appropriate document.  But as long as not all
                managers in the same community have directory access,
                the same information must also be present in a
                document.  Note that Distinguished Names in the context
                of the routing documents are just used as key strings
                to point to other documents.

      <Community-Identifier> ::= "Community: " \
                            ('community name' | <DirectoryName>) <CR>
                The 'community name' is a string identifying the MHS
                community to be used in the first line of all
                documents.

      <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
                            ["A=" 'ADMDname' "; " ] \
                            "C=" <Country-Code> "; " \
                            "MTAname=" 'MTAname')
                            | <DirectoryName> )
                A unique key is needed to identify the RELAY-MTA.  In
                addition to the MTA name itself, it is proposed to use
                OR address attributes of the management domain where
                the RELAY-MTA resides.  ADMD and PRMD fields are both
                optional and may be used to guarantee uniqueness of the
                key.  The values used are irrelevant.  Even non-
                printable characters like @ or ! are acceptable.  The
                result is not an address but a key string.  A
                Distinguished Name may be used instead.

      <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
                A unique key is necessary to make the links from the
                documents where a responsible person or an
                administrator is needed, to the PERSON documents.  It
                is either the OR address of the person or a
                Distinguished Name (if the person is already registered
                in the directory).

      <Country-Code> ::= 'Two Character Country Code ISO-3166'

      <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
                It has been used consequently all over the document.
                This explains also the syntax of the



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


                <UniqueRELAY-MTAkey> and the <MHS-subtree>. Examples:
                S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
                DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
                G=john; I=w; S=doe; P=org; A=rel400; C=aq;

      <EMail> ::= "Address: " <X.400 address> <CR>

      <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]

      <tel-number> ::=  {"+" <int-pref> " " <national number> \
                            [" x" <extension>]}
                This syntax follows the attribute syntax of the X.500
                directory based on CCITT E.123.

      <int-pref> ::= 'international prefix'

      <national number> ::= 'national telephone number'
                A national number may be written with spaces and
                hyphens to group the figures.

      <extension> ::= 'local extension'

      <Phone> ::= "Phone: " <tel-no-list> <CR>
                One or more phone numbers

      <Fax> ::= "Fax: " <tel-no-list> <CR>
                One or more FAX numbers

      <Mail> ::= "Mail: " 'postal address information' <CR>
                The items of the postal address are separated by ' /'
                wherever the next item goes onto the next line for a
                printed address label.  If the document is for an
                international community, the address should include the
                person's country.
                Example:
                Mail: SWITCH Head Office / Urs Eppenberger /
                      Limmatquai 138 / CH-8001 Zurich / Switzerland
                results in the following mailing label:
                SWITCH Head Office
                Urs Eppenberger
                Limmatquai 138
                CH-8001 Zurich
                Switzerland

      <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
                            "; START=" 'yymmdd' \
                            ["; END=" 'yymmdd'] <CR>
                The <Update-info> contains also the format identifier.



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


                The date of the last update of a document is given in
                the form 'yymmdd'.
                A start date must be set.  A document can be published
                this way before the information in it is valid.  (This
                is especially useful in absence of automated tools.
                RELAY-MTA managers get more time to prepare their
                systems.)
                An end date is used to set an expiration date for the
                document.

      <P-address> ::= 'String encoded Presentation Address'
                The format of this string follows RFC1278, A string
                encoding of Presentation Address and RFC1277, Encoding
                Network Addresses to support operation over non-OSI
                layers.  See chapter 5.2 about the usage of macros in a
                Presentation Address.

      <Service-type> ::= <Network-name> "/" \
                            <Network-service> "/" \
                            <Transport-Protocol>
                The service type consists of a string with three parts
                concatenated with a "/": Network-name/Network-
                service/Transport-Protocol.

      <Network-name> ::= 'Name of a network'
                The network-name string identifies a network.  A well
                known key word should be chosen.  (No '/' character is
                allowed.)
                Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
                WIN, Janet,

      <Network-service> ::= 'Name of a network service'
                Examples: X.25, CONS, CLNS, TCP

      <Transport-Protocol> ::= 'Name of a transport protocol'
                Examples: TP0, TP2, TP4, RFC1006

                Since network and stack information forms one string,
                it identifies in an easy way a connection possibility
                between two RELAY-MTAs.  The COMMUNITY document defines
                the strings to be used in the RELAY-MTA and DOMAIN
                documents.  Some examples:
                Internet/TCP/RFC1006
                Public-X.25/X.25/TP0
                RARE-IXI/CONS/TP0
                RARE-CLNS/CLNS/TP4
                (It is probably important to mention here that this
                string has nothing to do with the format of a



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


                presentation address as defined by Steve Hardcastle-
                Kille in RFC1278.  The problem of networks using the
                same address structure (X.121 DTEs, 4 Byte Internet
                addresses) but not being connected is not addressed in
                RFC1278 but solved by using the proposed service
                identifier above in addition to the presentation
                address.  As long as there are network islands, there
                is no other way than the addition of an 'island'-
                identifier.

      <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
                            ["OU1="'OrganizationalUnit'"; "\
                            ["OU2=" 'OrganizationalUnit' "; " \
                            ["OU3=" 'OrganizationalUnit' "; " \
                            ["OU4=" 'OrganizationalUnit' "; "]]]] \
                            ["P=" 'PRMDname' "; "] \
                            "A=" 'ADMDname' "; " \
                            "C=" <Country-Code> ";"

      <Operation> ::= "Reachable: "  {<time> "-" <time> "; "} \
                            <Time-zone> <CR>

      <time> ::= 'hh:mm'

      <Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
                The operation information is needed to know the time
                someone is reachable.  This information is important
                for communities spanning several time zones.
                'hhmm' is a four digit value, the first two digits
                indicate hours, the second two digits indicate minutes.
                Use "UTC+" for time zones east of Greenwich.  A simple
                formula helps to calculate the current time at the
                remote place:
                local-time - local-displacement + remote-displacement =
                remote-time
                18:00 - (UTC + 0100) + (UTC - 0800) = 09:00
                The <Time-zone> entry may be followed by a comment line
                indicating when Daylight Saving Time is in effect.
                This is especially reasonable for MHS communities
                spanning continents on the northern and southern
                hemisphere.

5.2 The COMMUNITY document

      <COMMUNITY-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <COMMUNITY-document-body>
                The first line of the COMMUNITY document specifies the



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


                <Community-Identifier> to be used in the header of all
                other documents belonging to the same community.  It is
                recommended to add a few comment lines to describe the
                members of this MHS community.

      <COMMUNITY-document-body> ::= <Coordination> \
                            [{<Macro-definition>}] \
                            {<Connections>}

      <Coordination> ::= <EMail> <Phone> <FAX> \
                            <Mail> <Operation> <File-server>
                Set of contact information for the coordination point

      <File-server> ::= <email-server> [{<FTP-server>}] \
                            [{<FTAM-server>}]
                All documents must be available at least to the
                managers of the MHS domains and the RELAY-MTAs through
                an email server.  If FTAM and FTP are also  available,
                the generation of automated update tools is much
                easier.
                It is suggested to have a single server.  If there is
                only one, knowing a single X.400 OR address will allow
                you to reach the server.  However for FTP and FTAM more
                system addresses may be possible depending on the
                number of available network connections (or service
                types as they are called in this document).