home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / osix400 / osix400-minutes-89nov.txt < prev    next >
Text File  |  1993-02-17  |  15KB  |  350 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Robert Hagens/Univeristy of Wisconsin
  5.  
  6. AGENDA
  7.  
  8.    o Announcement of new name
  9.    o Status of the quest for "NREN"
  10.    o Review of Scope
  11.       -  822 <-> X.400 gateway issues (RFC 987 and successors)
  12.       -  X.400 operational issues in a dual protocol internet
  13.    o Review of Issues
  14.       -  822 <-> X.400 Gateways
  15.           * RFC 987 gateway background
  16.           * Table Maintenance
  17.           * Locating a Gateway
  18.           * ORAddress Structure
  19.       -  X.400 Operation
  20.           * Routing to destination or 822 gateway
  21.           * Use of Internet Technology
  22.           * Mixed Stacks
  23.           * MTA names
  24.           * Use of "NREN"
  25.      Presentation of a new, unified address structure
  26.    ooEnumerating and discussion of major tasks
  27.  
  28.  
  29. MINUTES
  30.  
  31. The meeting was convened by chairman Rob Hagens.  An attendance list
  32. will be published with the Proceedings of the IETF. The Domain Name WG
  33. meet jointly with the OSI-X400 WG during the afternoon.
  34.  
  35. WORKING GROUP SCOPE
  36.  
  37. The scope of the WG was presented:
  38.  
  39.  
  40.    o RFC 822 <-> X.400 Gateway Issues
  41.       -  maintenance of RFC 987 mapping tables
  42.       -  routing toward a gateway
  43.    o X.400 Operational Issues
  44.       -  Structure of OR-Addresses in the Internet
  45.       -  X.400 Routing
  46.       -  Nameservers
  47.  
  48.  
  49. The group determined that (with the exception of determining the
  50. structure of OR-Addresses in the Internet), they should not try to solve
  51. "pure-OSI" problems.  These problems fall into the domain of other OSI
  52. groups.  The WG should develop and maintain a close relationship with
  53. such groups:
  54.  
  55.    o NIST X.400 SIG
  56.    o NIST X.500 SIG
  57.    o GOSIP X.400 committee
  58.  
  59.  
  60. PRESENTATION OF ISSUES
  61.  
  62. Rob Hagens presented a list of issues facing the WG. That list is
  63. included here:
  64.  
  65.  
  66.                Issues, Problems, and Proposed Solutions to
  67.                 X.400 and 987 Gatewaying in the Internet
  68.  
  69.  
  70.   1. X.400-RFC 822 Gateway Issues
  71.      (a) Background
  72.  
  73.          This background information serves as a very brief tutorial on
  74.          RFC 987.  The information presented below is far from complete.
  75.          It is strongly recom- mended that anyone interested in the
  76.          issues dis- cussed below should obtain and read RFC 987.
  77.          RFC 987 specifies how messages should be gatewayed between RFC
  78.          822 based systems and X.400 (1984) based systems.  Although the
  79.          RFC describes the translation of various protocol elements from
  80.          one system to the other, the following discussion is limited
  81.          only to the translation of addresses.
  82.          RFC 987 specifies that translation from one address space to
  83.          another may occur in 2 ways.  The normal method of translation
  84.          (table lookup) is used when sub-trees of the different name
  85.          spaces are associ- ated via mapping tables.  The fall back
  86.          method of translation (encoding in the other address space's
  87.          format) is used when table lookup fails.
  88.          Table lookup is accomplished through the use of 2 separate
  89.          tables:  an RFC 822 -> X.400 table, and an X.400 -> RFC 822
  90.          table.  Each entry in the tables is indexed by a key.  The
  91.          address to be mapped is compared against each key in the table.
  92.          The com- parison that matches the most components is selected
  93.          (i.e., the "longest" match).  The value associated with the key
  94.          is a template that is used to construct the translated address.
  95.  
  96.          i. Table Driven Mapping
  97.             For example, the 822 domain "merit.edu" could be associated
  98.             with the OR Address space "C=US, PRMD=NREN, O=MERIT.EDU" in
  99.             a mapping table.  Thus, when translating the 822 address
  100.             "hwb@merit.edu", the domain specification "merit.edu" would
  101.             be compared against the various keys in the table.  Assuming
  102.             that the table con- tains two keys "edu" and "merit.edu",
  103.             the longest match "merit.edu" would be selected.  The
  104.             template associated with the key "C=US, PRMD=NREN,
  105.             O=MERIT.EDU", would be used to produce the address "C=US,
  106.             PRMD=NREN, O=MERIT.EDU, OU=CS, PN=HWB".  In this example,
  107.  
  108.        the translation of the last domain component "cs" is
  109.        performed systemat- ically.  The translation of the
  110.        right-hand side of the 822 address "hwb" is specified by RFC
  111.        987.
  112.        This example shows that a single entry can specify the
  113.        translation for all addresses in the "merit.edu" domain.
  114.        This entry associates the 822 domain "merit.edu" with the
  115.        X.400 namespace under "C=US, PRMD=NREN, O=MERIT.EDU".
  116.        An analogous scheme is used for the opposite direction.
  117.    ii. Mapping Without Tables
  118.        If a mapping table entry is not present, transla- tion may
  119.        still occur.  However, in this case, the translation is less
  120.        sophisticated.  Translation, in this case amounts to
  121.        encoding the address in the other system's format.  RFC 987
  122.        specifies default rules that may be used to perform this
  123.        encoding.  These rules specify the manner in which an RFC
  124.        822 address may be encoded in X.400, and vice versa.  The
  125.        following examples consider each direction separately:
  126.    iii.RFC 822->X.400
  127.        In this direction, the domain-defined attribute "RFC-822"
  128.        may be used to encode an RFC 822 address.  For example, if
  129.        an 822 address "hagens@janeb.cs.wisc.edu" was translated by
  130.        a gateway that had an X.400 address "C=US, PRMD=NREN,
  131.        O=MERIT.EDU", then that gateway (in the absence of a mapping
  132.        table entry) would produce the address 'C=US, PRMD=NREN,
  133.        O=MERIT.EDU, DD.RFC- 822="hagens@janeb.cs.wisc.edu"'.
  134.    iv. X.400->RFC 822
  135.        In this direction, left-hand side encoding may be used to
  136.        encode an X.400 address within 822.  For example, the X.400
  137.        address "C=FR, ADMD=FRENCH-PTT, O=INRIA, PN=HUITEMA", when
  138.        considered by a gateway with the 822 address "merit.edu",
  139.        would be translated to '"C=FR, ADMD=FRENCH-PTT, O=INRIA,
  140.        PN=HUITEMA"@merit.edu'.
  141. (b) Issues
  142.     i. Table Maintenance
  143.        The mapping table entries must be kept consistent among all
  144.        the 987 gateways in the world.  This is very difficult to
  145.        accomplish by hand.  How can the table maintenance task be
  146.        automated?
  147.    ii. Finding the Gateway
  148.        How does a mail router find a 987 gateway?  In the
  149.        X.400->RFC 822 direction, it is the responsi- bility of
  150.        X.400 routing.  Note:  X.400 routing is not defined by any
  151.        standard.  In the RFC 822- >X.400 direction, it is the
  152.        responsibility of 822 routing.  Conventional MX records
  153.        could be util- ized to solve the problem.
  154.    iii.Structure of X.400 addresses
  155.        It is desirable to provide a default X.400 address for hosts
  156.        within the Internet.  This address will be structured so
  157.        that the X.400 address space corresponds with the domain
  158.        namespace.  What is the best structure to use for this
  159.        purpose?
  160.        The choice of format of X.400 addresses, and the
  161.        corresponence of these addresses to 822 domains will
  162.  
  163.             determine the contents of the of 987 mapping table entries.
  164.  
  165.               oProposed Solution
  166.  
  167.                The currently proposed solution is to map the top and
  168.                second level domains to the ORAddress "organization"
  169.                attribute.  Subsequent lower level domains will be
  170.                mapped to a sequence of "organization unit" attributes.
  171.                For example, "venera.isi.edu" would map to "O=isi.edu,
  172.                OU=venera".
  173.               oUse of 'NREN' as a PRMD name
  174.  
  175.                The intended use of "NREN" as a PRMD name is to identify
  176.                a management domain within which every registered
  177.                Internet entity has a default X.400 Address.  This
  178.                address would be based upon the Internet domain name.
  179.                We expect some or all currently registered entities to
  180.                decide for themselves whether they wish to use the
  181.                default or register another name in another way.  This
  182.                default provides a useful and helpful option without
  183.                constraining any individual entity to keep what the
  184.                default provides for them.
  185.                Is it necessary to define a second PRMD name which would
  186.                identify a management domain within the NREN that
  187.                utilizes X.400 addresses that are not based upon
  188.                Internet domain names?  If this is true, is the original
  189.                use of "NREN" incorrect?
  190.                We need to show "ownership" of the name "NREN" so that
  191.                other groups do not have the right to register it.
  192.                Trademarking is the first step.  Other uses of "NREN"
  193.                should be looked into.  Any way that we can show "use"
  194.                of the name will help establish our "ownership".
  195.   2. X.500 Operation Issues
  196.      (a) Issues
  197.          i. Distinguished Names
  198.  
  199.             Who will determine the structure of X.500 dis- tinguished
  200.             names (and the objects they locate) for use within the
  201.             Internet community?
  202.         ii. DNS coexistence
  203.  
  204.             How should the DNS and X.500 coexist?
  205.         iii.Domain Distinguished Names
  206.  
  207.             Is it acceptable, for transition purposes only, to suggest
  208.             that Domain names be used as Dis- tinguished names?
  209.  
  210.  
  211. DISCUSSION OF ISSUES
  212.  
  213. Non-USA Internet Sites
  214.  
  215.  
  216. The default OR Address may not be acceptable for Internet sites that are
  217. not within the USA. 1) The WG cannot mandate the format of addresses
  218. within a foreign country.  2) the NREN is a national object.  Are these
  219. reasons sufficient to prevent the definition of a default name using
  220. NREN? At least, it should be made clear that the default name is valid
  221. for USA-Internet sites only.  This may not be inappropriate if many
  222. foreign countries have already defined the X.400 registration policy
  223. that would affect the foreign Internet sites.
  224.  
  225. "NREN"
  226.  
  227.  
  228. The name "NREN" was originally choosen to be a PRMD name.  The purpose
  229. of this PRMD was to contain OR Addresses based upon Domain Names.  It
  230. was suggested that perhaps "NREN" is not appropriate for this use.  No
  231. other name was decided upon.  Possible candidates are names that convey
  232. some concept of Domain Names, such as "DN".  This change would allow the
  233. name "NREN" to be used by a FRICC-run PRMD.
  234.  
  235. Another option for a PRMD name would be to use the numeric form.
  236.  
  237. The effort to pre-register "NREN" as an ANSI OSI Organization name
  238. failed.  It is not clear that the OSI X.400 WG should attempt to
  239. register the name until its exact use has been determined.
  240.  
  241. It was suggested that the WG should consider producing a specification
  242. for written OR Addresses.
  243.  
  244. PRESENTATION OF A NEW, UNIFIED ADDRESS FORMAT
  245.  
  246. Paul Mockapetris presented his ideas regarding a new style of address.
  247. He would like to see the world move forward with the development of a
  248. unified, simple address structure.  His proposal is a format that has
  249. RFC 822 compatible syntax, whose semantic value is that of an X.500
  250. distinguished name.  These new addresses would be very short and
  251. user-friendly.  The new addresses could be used to look up both X.400
  252. ORAddresses as well as conventional 822 addresses.  The look up
  253. mechanism could utilize the DNS as well as X.500.
  254.  
  255. GATEWAY SCENERIOS
  256.  
  257. A discussion of RFC 822 - X.400 gateway (987) scenarios produced the
  258. following questions:
  259.  
  260.  
  261.    o Will any 987 gateway provide connectivity to every X.400 MTA?
  262.      The answer to this question will determine whether an 822 transfer
  263.      agent must choose a specific 987 gateway based upon the destination
  264.      address, or if the closest, default 987 gateway will always
  265.      suffice.
  266.    o Is there really benefit to table driven mappings or is it
  267.      sufficient to simply use default encodings?
  268.  
  269.  
  270. A scheme that utilizes the DNS to aid a 987 gateway was discussed.  The
  271. scheme requires the following components:
  272.  
  273.  
  274.    o An ASCII (canonical) representation of ORAddresses.
  275.    o A new tree of the DNS that is based upon canonical ORAddresses
  276.      strings (called ORADDR). This tree is populated with MX records
  277.      (that store the SMTP 822 address of 987 gateways), and TO-SMTP RRs.
  278.    o Two new DNS resource records.  TO-SMTP RRs are stored in the ORADDR
  279.      tree.  They contain the information necessary to translate an X.400
  280.      address into an 822 address.  TO-X400 RRs are stored in the
  281.      existing DN tree.  They contain information necessary to translate
  282.      SMTP 822 addresses into X.400 addresses.  A distributed collection
  283.      of TO-SMTP and TO-X400 records correspond to the 987 mapping tables
  284.      X.400 to RFC 822 (mapping 1) and RFC 822 to X.400 (mapping 2),
  285.      respectively.
  286.  
  287.  
  288. A sample scenario would be:
  289.  
  290.  
  291. 822->X.400
  292.  
  293.  
  294. Case A    The destination address is an SMTP address which has been
  295.           previously associated with an ORAddress.  This means that
  296.           there is a TO-X400 RR that describes how to translate the SMTP
  297.           822 address into an ORAddress.  The originating transfer agent
  298.           will look up the destination address and receive an MX record
  299.           and a TO-X400 RR. The MX record identifies a 987 gateway and
  300.           is used to transfer the message to that gateway.  The TO-X400
  301.           record is ignored by the originator.
  302.           When the 987 gateway receives the message, it will lookup the
  303.           destination address and receive an MX and TO-X400 RR. The MX
  304.           record is ignored, but the TO-X400 RR is used to translate the
  305.           destination address into an ORAddress.
  306. Case B    The destination address is an ORAddress.  The originating
  307.           transfer agent will look up the destination ORAddress in the
  308.           ORADDR tree and receive an MX record.  The MX record
  309.           identifies a 987 gateway and is used to transfer the message
  310.           to that gateway.  The destination address sent in the SMTP
  311.           envelope will contain "ORAddress"@gateway.
  312.  
  313.  
  314. X.400->822
  315.  
  316.  
  317. Routing to the 987 gateway is not within the scope of the WG; it is
  318. assumed that the message has already reached the 987 gateway.
  319.  
  320.  
  321. Case A    The destination address is an ORAddress which has been
  322.           previously associated with an SMTP 822 address (sub)tree.
  323.           This means that there is a TO-SMTP RR that describes how to
  324.           translate the ORAddress into an SMTP 822 address.
  325.           When the 987 gateway receives the message, it will lookup the
  326.           destination address in the ORADDR tree and receive a TO-SMTP
  327.           RR. The TO-SMTP RR is used to translate the destination
  328.           address into an SMTP 822 address.
  329. Case B    The destination address is an 822 address which has been
  330.           encoded in an ORAddress.
  331.           When the 987 gateway receives the message, it will translate
  332.           the destination address into an 822 address using the default
  333.           encoding rules.
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.