home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-whois-url-00.txt < prev    next >
Text File  |  1996-07-22  |  15KB  |  392 lines
  1.  
  2. ASID Working Group                                       Martin Hamilton
  3. INTERNET-DRAFT                                   Loughborough University
  4.                                                                July 1996
  5.  
  6.  
  7.                        WHOIS++ URL Specification
  8.                Filename: draft-ietf-asid-whois-url-00.txt
  9.  
  10.  
  11. Status of This Memo
  12.  
  13.       This document is an Internet-Draft.  Internet-Drafts are working
  14.       documents of the Internet Engineering Task Force (IETF), its
  15.       areas, and its working groups.  Note that other groups may also
  16.       distribute working documents as Internet-Drafts.
  17.  
  18.       Internet-Drafts are draft documents valid for a maximum of six
  19.       months and may be updated, replaced, or obsoleted by other
  20.       documents at any time.  It is inappropriate to use Internet-Drafts
  21.       as reference material or to cite them other than as ``work in
  22.       progress.''
  23.  
  24.       To learn the current status of any Internet-Draft, please check
  25.       the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  26.       Shadow Directories on ds.internic.net (US East Coast),
  27.       nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  28.       munnari.oz.au (Pacific Rim).
  29.  
  30.       Distribution of this memo is unlimited.  Editorial comments should
  31.       be sent directly to the author.  Technical discussion will take
  32.       place on the IETF ASID mailing list - ietf-asid@umich.edu.
  33.  
  34.       This Internet Draft expires January 25th, 1997.
  35.  
  36. Abstract
  37.  
  38.    This document defines a new Uniform Resource Locator (URL) scheme
  39.    "whois++", which provides a convention within the URL framework for
  40.    referring to WHOIS++ servers and the data held within them.  It does
  41.    not specify a standard.
  42.  
  43. 1. Overview of the WHOIS++ protocol
  44.  
  45.    RFC 1835 [1] defines a simple Internet directory protocol known as
  46.    WHOIS++.  In order that WHOIS++ may be used within the Uniform
  47.    Resource Locator (URL) framework defined by RFC 1738 [2], a URL
  48.    scheme definition for WHOIS++ is necessary.  This document specifies
  49.    a URL scheme "whois++", for use with the WHOIS++ protocol.
  50.  
  51.  
  52.  
  53.                                                                 [Page 1]
  54.  
  55. INTERNET-DRAFT                                                 July 1996
  56.  
  57.  
  58.    WHOIS++ is text based protocol after the fashion of many popular
  59.    Internet application protocols, such as SMTP [3] and FTP [4].
  60.    Although the protocol is TCP based, WHOIS++ is effectively stateless
  61.    - no state information is preserved across requests, there is no
  62.    concept of a session per se since each request/response pair is
  63.    self-contained, and there is no "login" phase.
  64.  
  65.    WHOIS++ transactions normally consist of a single request from the
  66.    client and response from the server, followed by the TCP connection
  67.    between the two being torn down.  Use of the "hold" constraint in the
  68.    WHOIS++ request makes it possible for the client to indicate that it
  69.    would like to keep the TCP connection open for more than one request/
  70.    response pair, but whether this is actually done is at the discretion
  71.    of the server.
  72.  
  73. 2. WHOIS++ URL specification
  74.  
  75.    The following information is necessary for a WHOIS++ client to
  76.    formulate and deliver a request:
  77.  
  78.      o the domain name or IP address of the server to contact
  79.      o the port number of the server (63 by default)
  80.      o the request itself - normally a single line of text
  81.  
  82.    This is a good match with the generic Uniform Resource Locator (URL)
  83.    scheme specified in RFC 1738.  So, a URL of the following form would
  84.    seem to be appropriate:
  85.  
  86.      whois++://host[:port][/<request-specification>]
  87.  
  88.    Using the BNF grammar defined in RFC 1738, this could be written as:
  89.  
  90.      whoisppurl   = "whois++://" hostport [ "/" whoisppsrch ]
  91.  
  92.    where
  93.  
  94.      whoisppsrch  = *uchar
  95.  
  96.    The definitions for hostport and uchar are imported from RFC 1738:
  97.  
  98.      hostport     = host [ ":" port ]
  99.      uchar        = unreserved | escape
  100.  
  101.    These in turn depend upon the following:
  102.  
  103.      unreserved   = alpha | digit | safe | extra
  104.      alpha        = lowalpha | hialpha
  105.      digit        = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
  106.  
  107.  
  108.  
  109.                                                                 [Page 2]
  110.  
  111. INTERNET-DRAFT                                                 July 1996
  112.  
  113.  
  114.                     "8" | "9"
  115.      safe         = "$" | "-" | "_" | "." | "+"
  116.      extra        = "!" | "*" | "'" | "(" | ")" | ","
  117.      lowalpha     = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
  118.                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
  119.                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
  120.                     "y" | "z"
  121.      hialpha      = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
  122.                     "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
  123.                     "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
  124.  
  125.      escape       = "%" hex hex
  126.      hex          = digit | "A" | "B" | "C" | "D" | "E" | "F" |
  127.                     "a" | "b" | "c" | "d" | "e" | "f"
  128.  
  129.    BNF for the WHOIS++ request format is defined in Appendix F of RFC
  130.    1835.  This can contain characters which may confuse software which
  131.    deals with whois++ URLs, notably spaces and characters drawn from
  132.    non-ASCII character sets such as the UTF-8 variant of Unicode [5,6].
  133.    Hence, the usual rules about hex-escaping illegal and reserved
  134.    characters should apply - and the definiton of the WHOIS++ request as
  135.    "uchar".  Note that the default WHOIS++ port of 63 should be used if
  136.    the port number component of the "hostport" construction is left out.
  137.  
  138.    Global constraints such as authentication information, language and
  139.    character set preferences may be expressed as part of the WHOIS++
  140.    request.  Consequently it is not thought necessary to specify them
  141.    separately in a mechanism such as the "user@host" construction
  142.    defined for the FTP URL.
  143.  
  144.    Most WHOIS++ requests can be expected to consist of a single line of
  145.    text, followed by carriage return and line feed characters.  It
  146.    should, however, be noted that it may be necessary to encode multi-
  147.    line requests within WHOIS++ URLs.  Software which implements whois++
  148.    URLs should either be capable of handling this, or fail gracefully.
  149.  
  150. 3. Examples
  151.  
  152.    The whois++ URL scheme defined above should make it possible to write
  153.    URLs for any of the following:
  154.  
  155.      (a) a reference particular WHOIS++ server, without implying
  156.            that a search should be done
  157.      (b) a "canned" search of a particular server
  158.      (c) individual objects within a server
  159.  
  160.    Case (a) simply requires that the host and optionally the port number
  161.    be specified, e.g.
  162.  
  163.  
  164.  
  165.                                                                 [Page 3]
  166.  
  167. INTERNET-DRAFT                                                 July 1996
  168.  
  169.  
  170.      whois++://acm.org/
  171.  
  172.    or
  173.  
  174.      whois++://acm.org:63/
  175.  
  176.    When given a whois++ URL of this format, implementations may choose
  177.    to present the user with a search form or dialogue, contact the
  178.    server for information about which WHOIS++ options it supports, and
  179.    so on.  The WHOIS++ default port 63 should be used if the port number
  180.    is not specified.
  181.  
  182.    Case (b) requires a search specification to be present, e.g.
  183.  
  184.      whois++://acm.org/name=phil%20and%20name=zimmerman
  185.  
  186.    This may be sent verbatim to the server, once hex escaped chars in
  187.    the URL have been converted back to normal, e.g.
  188.  
  189.      name=phil and name=zimmerman
  190.  
  191.    Case, (c) is effectively an instance of (b).  This may be implemented
  192.    as a search where the request consists of the WHOIS++ "handle" of the
  193.    requested object, e.g.
  194.  
  195.      whois++://acm.org/handle=number6
  196.  
  197. 4. Global constraints
  198.  
  199.    Although there are no global constraints specified in these last two
  200.    URLs, the WHOIS++ client may choose to add global constraints of its
  201.    own, e.g.  use of the "hold" constraint to request that the
  202.    connection be held open for a further request.
  203.  
  204.    If in addition, global constraints are part of the URL, this can
  205.    easily be recognised by the presence of a colon ":" immediately after
  206.    the slash "/" which separates the host and port information from the
  207.    search specifier, e.g.
  208.  
  209.      whois++://acm.org/:authenticate=password;name=foo;password=bar
  210.  
  211.    At the implementor's discretion, the client may choose to pass these
  212.    global constraints on in any queries which are passed to this server,
  213.    e.g. if this URL was used in a search for "zimmerman", the request
  214.    passed to the server might be either of
  215.  
  216.      zimmerman
  217.  
  218.  
  219.  
  220.  
  221.                                                                 [Page 4]
  222.  
  223. INTERNET-DRAFT                                                 July 1996
  224.  
  225.  
  226.    or
  227.  
  228.      zimmerman:authenticate=password;name=foo;password=bar
  229.  
  230.    or "zimmerman", followed by some combination of the global
  231.    constraints specified in the URL and other global constraints
  232.    introduced by the WHOIS++ client.
  233.  
  234. 5. Compatibility with WHOIS and RWhois
  235.  
  236.    The three protocols in the WHOIS family, NICNAME/WHOIS [7], WHOIS++,
  237.    and RWhois [8], are not particularly similar.  WHOIS++ and RWhois use
  238.    different request and response formats, and have different well-known
  239.    port numbers.  WHOIS responses are assumed to be plain text and human
  240.    readable.
  241.  
  242.    Consequently, this document has not attempted to define a single URL
  243.    scheme for use with all three protocols.
  244.  
  245. 6. World-Wide Web integration
  246.  
  247.    These whois++ URLs may be used as hyperlinks in HTML [9] documents,
  248.    though it should be noted that the relative URL syntax defined in RFC
  249.    1808 [10] is not appropriate for use in these links.  This is because
  250.    WHOIS++ requests do not map conveniently onto the generic resource
  251.    locator syntax used for relative URLs - the syntactic conventions
  252.    used in writing a WHOIS++ request are very different from those of
  253.    the generic resource locator.
  254.  
  255.    The WHOIS++ protocol and the whois++ URL lend themselves to
  256.    implementation via a proxy HTTP [11] gateway, since the information
  257.    necessary to contact the server and deliver the request is embedded
  258.    within the URL itself.  A simple proxy gateway has been implemented
  259.    which takes an HTTP "GET" request containing a whois++ URL, carries
  260.    out a WHOIS++ transaction and returns the results formatted as HTML.
  261.    This will probably be the preferred approach to providing WHOIS++
  262.    support by proxy for some time - there is no Internet Media Type
  263.    (aka.  MIME content-type) registered for WHOIS++ responses as yet.
  264.    The proxy server implementation can be found at
  265.  
  266.      <URL:http://www.roads.lut.ac.uk/pickup/>
  267.  
  268.    It does not appear to be appropriate to use any HTTP methods other
  269.    than "GET" with whois++ URLs, and there does not appear to be any
  270.    value in using whois++ URLs in HTML forms.
  271.  
  272.    The appearance of the "+" character in the protocol scheme component
  273.    of a URL is legal, according to RFC 1738.  The author has lingering
  274.  
  275.  
  276.  
  277.                                                                 [Page 5]
  278.  
  279. INTERNET-DRAFT                                                 July 1996
  280.  
  281.  
  282.    doubts about the ability of all software which processes URLs, for
  283.    example in parsing HTML documents, to cope with this character.  No
  284.    evidence has been found to back these doubts up, however.
  285.  
  286. 7. Security Considerations
  287.  
  288.    Client software should check both the contents of the whois++ URL and
  289.    the results returned from WHOIS++ search requests for any unsafe
  290.    characters and character strings.
  291.  
  292.    It is possible to embed requests for other protocols within this URL
  293.    format.  This is an approach which may be used to defeat security
  294.    schemes, spoof protocols, and so on.  Implementors should consider
  295.    requiring user confirmation when requests are directed to reserved
  296.    ports (i.e.  those less than 1024) other than 63 and 43, or well-
  297.    known ports in the unreserved range.
  298.  
  299.    Finally, implementations should take care not to cache authentication
  300.    information.
  301.  
  302. 8. Acknowledgements
  303.  
  304.    Thanks to Jeff Allen, Lorcan Dempsey, Patrik Faltstrom, Jon Knight,
  305.    William F. Maton, Larry Masinter, and Scott Williamson for their
  306.    comments on draft versions of this document.
  307.  
  308.    This work was supported by grants from the UK Electronic Libraries
  309.    Programme (eLib) and the European Commission's Telematics for
  310.    Research Programme.
  311.  
  312. 9. References
  313.  
  314.    Request For Comments (RFC) and Internet Draft documents are available
  315.    from <URL:ftp://ftp.internic.net> and numerous mirror sites.
  316.  
  317.          [1]         P. Deutsch, R. Schoultz, P. Faltstrom and C.
  318.                      Weider.  "Architecture of the WHOIS++ service", RFC
  319.                      1835. August 1995.
  320.  
  321.  
  322.          [2]         T. Berners-Lee, L. Masinter and M. McCahill (eds).
  323.                      "Uniform Resource Locators (URL)", RFC 1738.
  324.                      December 1994.
  325.  
  326.  
  327.          [3]         J. Postel.  "Simple Mail Transfer Protocol", RFC
  328.                      821.  August 1982.
  329.  
  330.  
  331.  
  332.  
  333.                                                                 [Page 6]
  334.  
  335. INTERNET-DRAFT                                                 July 1996
  336.  
  337.  
  338.          [4]         J. Postel, J. K. Reynolds.  "File Transfer Proto-
  339.                      col", RFC 959.  October 1985.
  340.  
  341.  
  342.          [5]         The Unicode Standard, Worldwide Character Encoding,
  343.                      Version 1.0, Volume 1, Addison-Wesley, 1990. ISBN
  344.                      0-201-56788-1.
  345.  
  346.  
  347.          [6]         The Unicode Standard, Worldwide Character Encoding,
  348.                      Version 1.0, Volume 2, Addison-Wesley, 1992. ISBN
  349.                      0-201-60845-6.
  350.  
  351.  
  352.          [7]         K. Harrenstien, M.K. Stahl, E.J. Feinler.
  353.                      "NICNAME/WHOIS", RFC 954. October 1985.
  354.  
  355.  
  356.          [8]         S. Williamson & M. Kosters.  "Referral Whois Proto-
  357.                      col (RWhois)", RFC 1714.  November 1994.
  358.  
  359.  
  360.          [9]         T. Berners-Lee, D. Connolly.  "Hypertext Markup
  361.                      Language - 2.0", RFC 1866.  November 1995.
  362.  
  363.  
  364.          [10]        R. Fielding. "Relative Uniform Resource Locators",
  365.                      RFC 1808.  June 1995.
  366.  
  367.  
  368.          [11]        T. Berners-Lee, R. Fielding, H. Frystyk.  "Hyper-
  369.                      text Transfer Protocol -- HTTP/1.0", RFC 1945.  May
  370.                      1996.
  371.  
  372. 10. Author's address
  373.  
  374.    Martin Hamilton
  375.    Department of Computer Studies
  376.    Loughborough University of Technology
  377.    Leics. LE11 3TU, UK
  378.  
  379.    Email: m.t.hamilton@lut.ac.uk
  380.               This Internet Draft expires January 25th, 1997.
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.                                                                 [Page 7]
  390.  
  391.  
  392.