home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-discovery-03.txt < prev    next >
Text File  |  1996-11-19  |  23KB  |  660 lines
  1.  
  2.  
  3.  
  4.  
  5. Internet-Draft                                                Ryan Moats
  6. draft-ietf-ids-discovery-03.txt                                     AT&T
  7. Expires in six months                                    Martin Hamilton
  8.                                                  Loughborough University
  9.                                                            November 1996
  10.  
  11.  
  12.                              Finding Stuff
  13.           (Providing information to support service discovery)
  14.                Filename: draft-ietf-ids-discovery-03.txt
  15.  
  16.  
  17. Status of This Memo
  18.  
  19.       This document is an Internet-Draft.  Internet-Drafts are working
  20.       documents of the Internet Engineering Task Force (IETF), its
  21.       areas, and its working groups.  Note that other groups may also
  22.       distribute working documents as Internet-Drafts.
  23.  
  24.       Internet-Drafts are draft documents valid for a maximum of six
  25.       months and may be updated, replaced, or obsoleted by other
  26.       documents at any time.  It is inappropriate to use Internet-
  27.       Drafts as reference material or to cite them other than as ``work
  28.       in progress.''
  29.  
  30.       To learn the current status of any Internet-Draft, please check
  31.       the ``1id-abstracts.txt'' listing contained in the Internet-
  32.       Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  33.       (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  34.       Coast), or ftp.isi.edu (US West Coast).
  35.  
  36.  
  37. Abstract
  38.  
  39.    This document proposes a solution to the problem of finding
  40.    information about that services are being offered at a particular
  41.    Internet domain, based on deployment experience with the Netfind
  42.    White Pages directory software.
  43.  
  44.    This approach makes it possible to supply clients with more
  45.    information than the DNS aliases that have been widely deployed in
  46.    this role - notably the port numbers being used by servers.  However,
  47.    it is not without problems, and we have tried to take account of
  48.    these.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Expires 5/19/97                                                 [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.  
  62. INTERNET DRAFT               Finding Stuff                 November 1996
  63.  
  64.  
  65. 1. Rationale
  66.  
  67.    There is no one single way of discovering the network services and
  68.    application protocols supported at a particular Internet domain.  The
  69.    Domain Name System (DNS - [1,2]) provides some basic facilities for
  70.    finding the hosts that offer particular services, such as DNS servers
  71.    themselves (NS records), and mail exchangers (MX records).  It does
  72.    not provide a mechanism for locating arbitrary servers of arbitrary
  73.    protocols, or a search capability.
  74.  
  75.    In addition to the name and IP address(es) of the host offering the
  76.    service, clients also sometimes require further information to make
  77.    effective use of the service - e.g. TCP or UDP port numbers, protocol
  78.    version information, and information about the protocol options
  79.    supported by the server.  Another example would be the organization's
  80.    base within the X.500 [3] Directory Information Tree (DIT), which is
  81.    needed for X.500 browsing and searching.
  82.  
  83.    At the time of writing, it was common practice to "hint" at the
  84.    services and protocols offered at a given domain via DNS aliases. For
  85.    example, the alias "www.internic.net" implies that the HTTP server
  86.    for the domain "internic.net" is running on TCP port 80 of the
  87.    machine (or machines) that answer to the name "www.internic.net."  A
  88.    slight formalization of this approach is proposed by [4].  Other
  89.    schemes have been suggested for explicitly registering services
  90.    either by DNS extensions, as in [5], or by dedicated directory
  91.    services such as X.500.
  92.  
  93.    Several mechanisms have been suggested to address the problem of
  94.    finding this service information, ranging from new DNS record types
  95.    to dedicated directory services.  No single one of these would-be
  96.    solutions has as yet gained the competitive edge. If the lengthy
  97.    gestation period to date is anything to go by, it seems that we can
  98.    expect even more delay before there is any widespread deployment -
  99.    unless there is a "killer application" that forces the issue.
  100.  
  101. 2. Where Netfind has gone before
  102.  
  103.    The Netfind software [6,7] follows what has been proposed in RFC 1588
  104.    [8]:  using URLs [9] for passing directory service information to
  105.    clients. It uses stylized Text (TXT) record encoding within the DNS
  106.    and currently understands the following "White Pages" URLs:
  107.  
  108.      -----------------------------------------------------------
  109.      White Pages URL             Information
  110.      -----------------------------------------------------------
  111.      wp-noop://                  This site should not be visited
  112.      wp-dap://<sb>               X.500 search base for the site
  113.  
  114.  
  115.  
  116. Expires 5/19/97                                                 [Page 2]
  117.  
  118.  
  119.  
  120.  
  121.  
  122. INTERNET DRAFT               Finding Stuff                 November 1996
  123.  
  124.  
  125.           e.g. wp-dap://o=Loughborough%20University,c=GB
  126.      wp-ph://host/port           Indicates CCSO nameserver [10]
  127.      wp-whois://host/port        Indicates WHOIS [11] server
  128.      wp-smtp-expn-finger://host  Use the SMTP [12] EXPN command,
  129.                                    and the finger [13] protocol
  130.      wp-smtp-expn://host/port    Indicates the SMTP EXPN command
  131.      wp-finger://host/port       Indicates the finger protocol
  132.      wp-telnet://host/port       Indicates a text based info
  133.                                    service that should be used
  134.                                    via telnet [14]
  135.      -----------------------------------------------------------
  136.  
  137.    Note that the notation "protocol://host/port" is used, rather than
  138.    the "protocol://host:port" format that is being standardized for
  139.    generic URLs.
  140.  
  141.    Note also that these URL schemes have not all been standardized,
  142.    although wp-ph and wp-whois may be accommodated by translation to the
  143.    widely supported Internet Gopher Protocol [15].
  144.  
  145. 3. A simple interim solution
  146.  
  147.    In this document, we propose that the "service:" URL scheme as
  148.    described in [17] be encoded in DNS TXT records as a solution.  With
  149.    this scheme, software agents would do a DNS lookup on
  150.    <service>.<domain name>.  The TXT record associated with
  151.    <service>.<domain name> would have the following syntax:
  152.  
  153.    <service> IN TXT "service:<srvtag>-<url> [preference] [protocol
  154.    specific information]"
  155.  
  156.    where the preference value and protocol specific information are
  157.    optional and are separated by spaces.  Alternatively, software agents
  158.    could do a lookup on the parent domain, but this could lead to
  159.    overloading the DNS response packet.
  160.  
  161.    We propose that the following values be used for <srvtag>
  162.  
  163.      ---------------------------------------------------------------------
  164.      Prefix   Meaning
  165.      ---------------------------------------------------------------------
  166.      keys     Public key server info
  167.      wp      "White Pages" service info
  168.      yp      "Yellow Pages" service info
  169.      ---------------------------------------------------------------------
  170.  
  171.    This scheme is not compatible with the Netfind "wp-" scheme, but that
  172.    is not viewed as a problem owing to lack of deployment of "wp-" URLs.
  173.  
  174.  
  175.  
  176. Expires 5/19/97                                                 [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. INTERNET DRAFT               Finding Stuff                 November 1996
  183.  
  184.  
  185.    Alternatively, clients may support both "wp-" URLs and "service:"
  186.    URLs.
  187.  
  188.    Thus for general white pages discovery, we propose that software
  189.    agents do a DNS lookup on wp.<domain name>.  Here, the TXT records
  190.    would contain URLs of the "wp-" service type.  For example, the TXT
  191.    records for wp.lut.ac.uk could be written as
  192.  
  193.      service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of%20
  194.        Technology,c=GB
  195.      service:wp-http://www.lut.ac.uk/cgi-bin/local
  196.  
  197.    Whilst not an optimal solution, for reasons we will discuss below,
  198.    this approach does provide an additional level of flexibility and
  199.    only requires a trivial amount of work to deploy - typically adding a
  200.    single line to the site's DNS configuration file for each service
  201.    being advertised.
  202.  
  203. 4. Further details and usage scenarios
  204.  
  205. 4.1. Finding "White Pages" information
  206.  
  207.    This is the case that is already catered for by the Netfind "wp-"
  208.    prefix.  To advertise their White Pages services explicitly, a site
  209.    would create one or more TXT records under both wp and the service
  210.    being advertised, e.g.
  211.  
  212.      wp IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University
  213.        %20of%20Technology,c=GB"
  214.      wp IN TXT "service:wp-whois://whois.lut.ac.uk/"
  215.      wp IN TXT "service:wp-gopher://cso.lut.ac.uk/2"
  216.  
  217.      ldap IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University
  218.        %20of%20Technology,c=GB"
  219.  
  220.      whois IN TXT "service:wp-whois://whois.lut.ac.uk/"
  221.  
  222.      ph IN TXT "service:wp-gopher://cso.lut.ac.uk/2"
  223.  
  224.    Another example showing the possibility of multiple protocols for
  225.    accessing a service would be (the domain for this example is
  226.    aecom.yu.edu):
  227.  
  228.     ns IN TXT "service:wp-gopher://gopher.aecom.yu.edu/2"
  229.     ns IN TXT "service:wp-http://www.middlebury.edu/cgi-bin/
  230.                WebPh?other_ph_servers"
  231.     ns IN TXT "service:wp-http://faker.ncsa.uiuc.edu:8080/cgi-bin/phfd"
  232.  
  233.  
  234.  
  235.  
  236. Expires 5/19/97                                                 [Page 4]
  237.  
  238.  
  239.  
  240.  
  241.  
  242. INTERNET DRAFT               Finding Stuff                 November 1996
  243.  
  244.  
  245.    It is envisaged that this information could be used in some
  246.    scenarios.  Assuming their Internet domain is aleady known, mail user
  247.    agents with integrated support could offer to do directory service
  248.    lookups to determine a correspondent's address from their name, to
  249.    verify the contents of address books, and to determine alternative
  250.    email addresses should delivery fail.  This last technique might also
  251.    be applied by lower level mail delivery software.
  252.  
  253. 4.3. Public key lookup
  254.  
  255.    Attempts to build a scalable infrastructure for the distribution of
  256.    public key information, in particular for the public keys of
  257.    individuals, have been hampered by the lack of a convention that
  258.    could be used to suggest the public key servers for a site or
  259.    organization.
  260.  
  261.    The "keys-" prefix gives us a flexible means by which this may be
  262.    done, e.g.
  263.  
  264.      keys IN TXT "service:keys-finger://mrrl.lut.ac.uk 5"
  265.  
  266.      lut.ac.uk IN TXT "service:keys-finger://mrrl.lut.ac.uk 5"
  267.  
  268.    It does not, however, address the issue of public key (certificate)
  269.    format.  It is expected that this would be taken care of by format
  270.    negotiation in the protocol or protocols being used to do the lookup.
  271.  
  272.    Public key lookup would be of immediate use in software that has
  273.    integrated support for public key authentication, signing and
  274.    encryption - e.g. mail and news user agents.
  275.  
  276. 4.4. Finding "Yellow Pages" information
  277.  
  278.    By "Yellow Pages" we mean a catch-all category: information about
  279.    services offered that do not fall into any of the above categories.
  280.  
  281.    For example, consider the case of a machine that is running a HTTP
  282.    server - but not on the IANA registered default port (80)
  283.  
  284.      www IN A 204.179.186.65
  285.          IN A 198.49.45.10
  286.          IN A 192.20.239.132
  287.          IN TXT "service:yp-http://www.ds.internic.net:8888/"
  288.  
  289.      yp  IN A 204.179.186.65
  290.          IN A 198.49.45.10
  291.          IN A 192.20.239.132
  292.          IN TXT "service:yp-http://www.ds.internic.net:8888/"
  293.  
  294.  
  295.  
  296. Expires 5/19/97                                                 [Page 5]
  297.  
  298.  
  299.  
  300.  
  301.  
  302. INTERNET DRAFT               Finding Stuff                 November 1996
  303.  
  304.  
  305.    This "Yellow Pages" mechanism provides a means for DNS maintainers to
  306.    effectively register the existence of their major network services.
  307.    This can have a variety of uses - e.g. the service information is
  308.    available to any "web crawler" type applications that might choose to
  309.    index it, and to interactive applications such as World-Wide Web
  310.    browsers, that might use it to override their default behavior.
  311.  
  312. 4.5 Finding "Directory Agent" information
  313.  
  314.    [17] also defines a scheme for Directory Agent discovery (Here
  315.    directory is being used in the SVRLOC context, not the IDS context).
  316.    A site may wish to present services to hosts outside its domain may
  317.    elect to set up a Directory Agent (with the remote registration
  318.    features turned off, see [17]) outside its firewall.  A client
  319.    supporting the service location protocol would then make queries for
  320.    individual services inside the domain.  The Directory Agent would be
  321.    found via the following DNS entries:
  322.  
  323.    (Domain entry)
  324.    catch22.com IN TXT "service:directory-agent://slp-resolver.catch22.com"
  325.  
  326.    (host in domain catch22.com)
  327.    directory-agent IN TXT "service:directory-agent://slp-resolver.catch22.com"
  328. 5. Support in DNS clients and servers
  329.  
  330.    This scheme is completely compatible with SRV and NAPTR (see [18])
  331.    DNS records, that are currently being implemented in BIND.
  332.  
  333. 6. Limitations of this approach
  334.  
  335.    Note that older DNS servers may not support the TXT record type, and
  336.    some servers fail to implement it properly - e.g. BIND 4.9.2 misses
  337.    out every other letter in the TXT record.  Further, support for SRV
  338.    has only recently been added to the BIND code base.
  339.  
  340.    Some resolvers are not capable of requesting a TXT record, or not
  341.    capable of generating any DNS lookup requests other than a simple
  342.    address lookup.  TXT records can actually be requested by setting the
  343.    question type in the request to 16 (decimal), regardless of the
  344.    symbolic names defined by the stack's resolver code.  Implementing
  345.    more advanced resolver functionality when the stack only provides
  346.    address lookup requires a little work, but sample code is freely
  347.    available.
  348.  
  349.    The size limitations on DNS packets will have some effect on the
  350.    number of URLs that can be associated with a domain name using TXT
  351.    records.  Response packets are liable to be truncated if they grow to
  352.    over 576 bytes.
  353.  
  354.  
  355.  
  356. Expires 5/19/97                                                 [Page 6]
  357.  
  358.  
  359.  
  360.  
  361.  
  362. INTERNET DRAFT               Finding Stuff                 November 1996
  363.  
  364.  
  365.    Characters that are illegal in URLs must be escaped, for example:
  366.  
  367.      "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of
  368.        %20Technology,c=GB"
  369.  
  370.    Domain name compression is normally used to reduce the size of the
  371.    response packet needed for a given domain name.  Clearly, this will
  372.    not be possible on arbitrary strings embedded within the response
  373.    packet.
  374.  
  375.    Widespread use of TXT records in the role proposed by this document
  376.    would increase the amount of information held in nameserver caches,
  377.    and in particular might cause problems where negative caching is
  378.    concerned.  Consequently we suggest that clients use them as a fall
  379.    back mechanism if more conventional methods, such as DNS aliases,
  380.    prove unproductive.
  381.  
  382. 7. Security Considerations
  383.  
  384.    Since this draft proposes to use DNS for storage of URL information,
  385.    all the normal security considerations for applications that depend
  386.    on the DNS apply.  The DNS is open to many kinds of "spoofing"
  387.    attacks, and it cannot be guaranteed that the result returned by a
  388.    DNS lookup is indeed the genuine information.  Spoofing may take the
  389.    form of denial of service, such as directing of the client to a non-
  390.    existent address, or a passive attack such as an intruder's server
  391.    that masquerades as the legitimate one.
  392.  
  393.    Work is ongoing to remedy this issue insofar as the DNS is concerned
  394.    [16].  In the meantime, note that stronger authentication mechanisms
  395.    such as public key cryptography with large key sizes are a pre-
  396.    requisite if the DNS is being used in any sensitive environment.
  397.    Examples of these would be on-line financial transactions, and any
  398.    scenario where privacy is a concern - such as the querying of medical
  399.    records over the network.  Strong encryption of the network traffic
  400.    may also be advisable, to protect against TCP connection "hijacking"
  401.    and packet sniffing.
  402.  
  403.    There are some additional considerations that are specific to URLs.
  404.    Specifically, client applications should be wary of URLs that direct
  405.    them to alternative Internet domains and/or unusual port numbers.
  406.    They should also be proactive when passing URLs to external programs,
  407.    to ensure that the user's environment is not exposed to malevolent
  408.    meta-characters.  Finally, implementors should take care to avoid
  409.    buffer overruns when processing these DNS response packets.
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416. Expires 5/19/97                                                 [Page 7]
  417.  
  418.  
  419.  
  420.  
  421.  
  422. INTERNET DRAFT               Finding Stuff                 November 1996
  423.  
  424.  
  425. 8. Conclusions
  426.  
  427.    Whilst far from ideal, we believe the approach outlined in this
  428.    document does provide a workable interim solution to the problem of
  429.    locating the network services offered at a particular Internet domain
  430.    - particularly when used in combination with DNS aliases, as outlined
  431.    in [4].  Suitable DNS server software is already widely deployed, and
  432.    client support may be implemented without any great difficulty.
  433.  
  434.    It is debatable whether any of this is strictly necessary.  Certainly
  435.    there is less work involved in adding a few lines to an existing DNS
  436.    server configuration than in setting up a whole new directory
  437.    service, such as X.500.  From this point of view, a new DNS resource
  438.    record type or types would perhaps address the problem more
  439.    effectively, but it may be some time before any new types are widely
  440.    deployed.
  441.  
  442. 9. Acknowledgments
  443.  
  444.    Special thanks to Erik Guttman for his help with the service location
  445.    example, information on the "service:" scheme, as well as much e-mail
  446.    in working out the service schemes proposed here.  Thanks to Tim
  447.    Howes, Sri Sataluri and <<your name here!!>> for their comments on
  448.    earlier drafts of this document.  This work was partially supported
  449.    by the National Science Foundation, the UK Electronic Libraries
  450.    Programme (eLib) grant 12/39/01, and the European Commission's
  451.    Telematics for Research Programme grant RE 1004.
  452.  
  453.    The format used for representing Netfind White Pages URLs within the
  454.    DNS was originally defined by Mike Schwartz, with help from Carl
  455.    Malamud and Marshall Rose.  The Netfind work was supported in part by
  456.    grants from the National Science Foundation, the Advanced Research
  457.    Projects Agency, Sun Microsystems' Collaborative Research Program,
  458.    and AT&T Bell Laboratories.
  459.  
  460.    Some of the points in the security considerations section were drawn
  461.    from [4].
  462.  
  463. 10. References
  464.  
  465.    Request For Comments (RFC) and Internet Draft documents are available
  466.    from <URL:ftp://ftp.internic.net> and numerous mirror sites.
  467.  
  468.          [1]         P. V. Mockapetris. "Domain names - concepts and
  469.                      facilities," RFC 1034.  November 1987.
  470.  
  471.  
  472.          [2]         P. V. Mockapetris. "Domain names - implementation
  473.  
  474.  
  475.  
  476. Expires 5/19/97                                                 [Page 8]
  477.  
  478.  
  479.  
  480.  
  481.  
  482. INTERNET DRAFT               Finding Stuff                 November 1996
  483.  
  484.  
  485.                      and specification," RFC 1035.  November 1987.
  486.  
  487.  
  488.          [3]         C. Weider, J. Reynolds, S. Heker.  "Technical Over-
  489.                      view of Directory Services Using the X.500 Proto-
  490.                      col," RFC 1309.  March 1992.
  491.  
  492.  
  493.          [4]         M. Hamilton, R. Wright.  "Use of DNS Aliases for
  494.                      Network Services," Internet Draft (work in pro-
  495.                      gress). June 1996.
  496.  
  497.  
  498.          [5]         A. Gulbrandsen, P. Vixie. "A DNS RR for specifying
  499.                      the location of services (DNS SRV)," RFC 2052.
  500.                      October 1996.
  501.  
  502.  
  503.          [6]         M. F. Schwartz. "Netfind Support for URL-Based
  504.                      Search Customization," June 28, 1994.
  505.                      <URL:ftp://ftp.cs.colorado.edu/pub/cs/distribs/
  506.                      netfind/Netfind.WP.URLs>
  507.  
  508.  
  509.          [7]         M. F. Schwartz, C. Pu.  "Applying an Information
  510.                      Gathering Architecture to Netfind: A White Pages
  511.                      Tool for a Changing and Growing Internet," Univer-
  512.                      sity of Colorado Technical Report CU-CS-656-93.
  513.                      December 1993, revised July 1994.
  514.                      <URL:ftp://ftp.cs.colorado.edu/pub/cs/techreports/
  515.                      schwartz/Netfind.Gathering.txt.Z>
  516.  
  517.  
  518.          [8]         J. Postel, C. Anderson. "White Pages Meeting
  519.                      Report," RFC 1588.  February 1994.
  520.  
  521.  
  522.          [9]         T. Berners-Lee, L. Masinter & M. McCahill.  "Uni-
  523.                      form Resource Locators (URL)," RFC 1738.  December
  524.                      1994.
  525.  
  526.  
  527.          [10]        R. Hedberg, S. Dorner, and P. Pomes. "The CCSO
  528.                      Nameserver (Ph) Architecture," Internet Draft (work
  529.                      in progress), January 1996.
  530.  
  531.  
  532.          [11]        K. Harrenstien, M. K. Stahl, E.J. Feinler.
  533.  
  534.  
  535.  
  536. Expires 5/19/97                                                 [Page 9]
  537.  
  538.  
  539.  
  540.  
  541.  
  542. INTERNET DRAFT               Finding Stuff                 November 1996
  543.  
  544.  
  545.                      "NICNAME/WHOIS," RFC 954.  October 1985.
  546.  
  547.  
  548.          [12]        D. Crocker.  "Standard for the format of ARPA
  549.                      Internet text messages," RFC 822. August 1982.
  550.  
  551.  
  552.          [13]        D. Zimmerman.  "The Finger User Information Proto-
  553.                      col," RFC 1288. December 1992.
  554.  
  555.  
  556.          [14]        J. Postel, J .K. Reynolds.  "Telnet Protocol
  557.                      specification," RFC 855.  May 1983.
  558.  
  559.  
  560.          [15]        F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
  561.                      D. Torrey & B. Albert.  "The Internet Gopher Proto-
  562.                      col (a distributed document search and retrieval
  563.                      protocol)," RFC 1436.  March 1993.
  564.  
  565.  
  566.          [16]        D. E. Eastlake 3rd, C. W. Kaufman.  "Domain Name
  567.                      System Security Extensions," Internet Draft (work
  568.                      in progress).  August 1996.
  569.  
  570.  
  571.          [17]        J. Veizades, E. Guttman, C. Perkins, S. Kaplan.
  572.                      "Service Location Protocol," Internet Draft (work
  573.                      in progress), June 1996.
  574.  
  575.  
  576.          [18]        R. Daniel, M. Mealling. "Resolution of Uniform
  577.                      Resource Identifiers using the Domain Name System,"
  578.                      Internet Draft (work in progress), Oct. 30 1996.
  579.  
  580. 11. Authors' addresses
  581.  
  582.    Ryan Moats
  583.    AT&T
  584.    15621 Drexel Circle
  585.    Omaha, NE 68135-2358
  586.    USA
  587.  
  588.    Phone:  +1 402 894-9456
  589.    EMail:  jayhawk@ds.internic.net
  590.  
  591.  
  592.    Martin Hamilton
  593.  
  594.  
  595.  
  596. Expires 5/19/97                                                [Page 10]
  597.  
  598.  
  599.  
  600.  
  601.  
  602. INTERNET DRAFT               Finding Stuff                 November 1996
  603.  
  604.  
  605.    Department of Computer Studies
  606.    Loughborough University of Technology
  607.    Leics. LE11 3TU, UK
  608.  
  609.    Email:  m.t.hamilton@lut.ac.uk
  610.  
  611.  
  612.                  This Internet Draft expires May 19, 1997.
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656. Expires 5/19/97                                                [Page 11]
  657.  
  658.  
  659.  
  660.