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