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