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