idnits 2.17.1
draft-ietf-asid-whois-url-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-26) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 1997) is 9843 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Historic RFC: RFC 1835 (ref. '1')
** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC
4248, RFC 4266)
** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821)
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
** Obsolete normative reference: RFC 954 (ref. '7') (Obsoleted by RFC 3912)
** Obsolete normative reference: RFC 1714 (ref. '8') (Obsoleted by RFC 2167)
** Obsolete normative reference: RFC 1866 (ref. '9') (Obsoleted by RFC 2854)
** Obsolete normative reference: RFC 1808 (ref. '10') (Obsoleted by RFC
3986)
** Downref: Normative reference to an Informational RFC: RFC 1945 (ref.
'11')
Summary: 16 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ASID Working Group Martin Hamilton
3 INTERNET-DRAFT Loughborough University
4 May 1997
6 WHOIS++ URL Specification
7 Filename: draft-ietf-asid-whois-url-01.txt
9 Status of This Memo
11 This document is an Internet-Draft. Internet-Drafts are working
12 documents of the Internet Engineering Task Force (IETF), its
13 areas, and its working groups. Note that other groups may also
14 distribute working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six
17 months and may be updated, replaced, or obsoleted by other
18 documents at any time. It is inappropriate to use Internet-Drafts
19 as reference material or to cite them other than as ``work in
20 progress.''
22 To learn the current status of any Internet-Draft, please check
23 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
24 Shadow Directories on ds.internic.net (US East Coast),
25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
26 munnari.oz.au (Pacific Rim).
28 Distribution of this memo is unlimited. Editorial comments should
29 be sent directly to the author. Technical discussion will take
30 place on the IETF ASID mailing list - ietf-asid@umich.edu.
32 This Internet Draft expires November 19th, 1997.
34 Abstract
36 This document defines a new Uniform Resource Locator (URL) scheme
37 "whois++", which provides a convention within the URL framework for
38 referring to WHOIS++ servers and the data held within them.
40 1. Overview of the WHOIS++ protocol
42 RFC 1835 [1] defines a simple Internet directory protocol known as
43 WHOIS++. In order that WHOIS++ may be used within the Uniform
44 Resource Locator (URL) framework defined by RFC 1738 [2], a URL
45 scheme definition for WHOIS++ is necessary. This document specifies
46 a URL scheme "whois++", for use with the WHOIS++ protocol.
48 WHOIS++ is text based protocol after the fashion of many popular
49 Internet application protocols, such as SMTP [3] and FTP [4].
50 Although the protocol is TCP based, WHOIS++ is effectively stateless
51 - no state information is preserved across requests, there is no
52 concept of a session per se since each request/response pair is
53 self-contained, and there is no "login" phase.
55 WHOIS++ transactions normally consist of a single request from the
56 client and response from the server, followed by the TCP connection
57 between the two being torn down. Use of the "hold" constraint in the
58 WHOIS++ request makes it possible for the client to indicate that it
59 would like to keep the TCP connection open for more than one request/
60 response pair, but whether this is actually done is at the discretion
61 of the server.
63 2. WHOIS++ URL specification
65 The following information is necessary for a WHOIS++ client to
66 formulate and deliver a request:
68 o the domain name or IP address of the server to contact
69 o the port number of the server (63 by default)
70 o the request itself - normally a single line of text
72 This is a good match with the generic URL scheme specified in RFC
73 1738, and so a URL following the generic syntax is appropriate.
75 The WHOIS++ URL scheme is defined as:
77 whoisppurl = "whois++://" hostport [ "/" whoisppsrch ]
79 where
81 whoisppsrch = *uchar
83 The definitions for "hostport" and "uchar" are imported from the BNF
84 style grammar for URLs defined in Section 5 of RFC 1738. BNF for the
85 WHOIS++ request format ("whoisppsrch") is defined in Appendix F of
86 RFC 1835.
88 3. Examples
90 The whois++ URL scheme defined above makes it possible to write URLs
91 for any of the following:
93 (a) a reference particular WHOIS++ server, without implying
94 that a search should be done
95 (b) a "canned" search of a particular server
96 (c) individual objects within a server
98 Case (a) simply requires that the host and optionally the port number
99 be specified, e.g.
101 whois++://acm.org/
103 or
105 whois++://acm.org:63/
107 When given a WHOIS++ URL of this format, implementations may choose
108 to present the user with a search form or dialogue, contact the
109 server for information about which WHOIS++ options it supports, and
110 so on. The WHOIS++ default port 63 should be used if the port number
111 is not specified.
113 Case (b) requires a search specification to be present, e.g.
115 whois++://acm.org/name=phil%20and%20name=zimmerman
117 This may be sent verbatim to the server, once hex escaped chars in
118 the URL have been converted back to normal, e.g.
120 name=phil and name=zimmerman
122 Case, (c) is effectively an instance of (b). This may be implemented
123 as a search where the request consists of the WHOIS++ "handle" of the
124 requested object, e.g.
126 whois++://acm.org/handle=number6
128 Although there are no global constraints specified in these last two
129 URLs, the WHOIS++ client may choose to add global constraints of its
130 own, e.g. use of the "hold" constraint to request that the
131 connection be held open for a further request.
133 If in addition, global constraints are part of the URL, this can
134 easily be recognised by the presence of a colon ":" immediately after
135 the slash "/" which separates the host and port information from the
136 search specifier, e.g.
138 whois++://acm.org/:authenticate=password;name=foo;password=bar
140 At the implementor's discretion, the client may choose to pass these
141 global constraints on in any queries which are passed to this server,
142 e.g. if this URL was used in a search for "zimmerman", the request
143 passed to the server might be either of
144 zimmerman
146 or
148 zimmerman:authenticate=password;name=foo;password=bar
150 or "zimmerman", followed by some combination of the global
151 constraints specified in the URL and other global constraints
152 introduced by the WHOIS++ client.
154 4. Issues
156 4.1 Relationship with WHOIS and RWhois
158 The three protocols in the WHOIS family, NICNAME/WHOIS [5], WHOIS++,
159 and RWhois [6], are not particularly similar. WHOIS++ and RWhois use
160 different request and response formats, and have different well-known
161 port numbers. WHOIS responses are assumed to be plain text and human
162 readable. Consequently, this document has not attempted to define a
163 single URL scheme for use with all three protocols.
165 4.2 Localisation
167 WHOIS++ requests may contain "difficult characters" such as space,
168 and characters drawn from non-ASCII character sets such as the UTF-8
169 variant of Unicode [7,8]. Hence, the usual rules about hex-escaping
170 illegal and reserved characters should apply - and the definiton of
171 the WHOIS++ request as "uchar". Note that the default WHOIS++ port
172 of 63 should be used if the port number component of the "hostport"
173 construction is left out.
175 4.3 Use of global constraints
177 Since global constraints such as authentication information, language
178 and character set preferences may be expressed as part of the WHOIS++
179 request, it is not thought necessary to specify them separately in a
180 mechanism such as the "user@host" construction defined for the FTP
181 URL.
183 4.4 Encoding multi-line WHOIS++ requests
185 Most WHOIS++ requests can be expected to consist of a single line of
186 text, followed by carriage return and line feed characters. It
187 should, however, be noted that it may be necessary to encode multi-
188 line requests within WHOIS++ URLs. Software which implements WHOIS++
189 URLs should either be capable of handling this, or fail gracefully.
191 4.5 Integration with HTML/HTTP
192 WHOIS++ URLs may be used as hyperlinks in HTML [9] documents, though
193 it should be noted that the relative URL syntax defined in RFC 1808
194 [10] is not appropriate for use in these links. This is because
195 WHOIS++ requests do not map conveniently onto the generic resource
196 locator syntax used for relative URLs - the syntactic conventions
197 used in writing a WHOIS++ request are very different from those of
198 the generic resource locator.
200 The WHOIS++ protocol and the WHOIS++ URL lend themselves to
201 implementation via a proxy HTTP [11] gateway, since the information
202 necessary to contact the server and deliver the request is embedded
203 within the URL itself. A simple proof-of-concept proxy gateway has
204 been implemented which takes an HTTP "GET" request containing a
205 WHOIS++ URL, carries out a WHOIS++ transaction and returns the
206 results formatted as HTML. This may be found at:
208
210 It is not appropriate to use any HTTP methods other than "GET" with
211 WHOIS++ URLs.
213 The appearance of the "+" character in the protocol scheme component
214 of a URL is legal, according to RFC 1738. The author has lingering
215 doubts about the ability of all software which processes URLs, for
216 example in parsing HTML documents, to cope with this character. No
217 evidence has been found to back these doubts up, however.
219 5. Security Considerations
221 Client software should check both the contents of the WHOIS++ URL and
222 the results returned from WHOIS++ search requests for any unsafe
223 characters and character strings.
225 It is possible to embed requests for other protocols within this URL
226 format. This is an approach which may be used to defeat security
227 schemes, spoof protocols, and so on. Implementors should consider
228 requiring user confirmation when requests are directed to reserved
229 ports (i.e. those less than 1024) other than 63 and 43, or well-
230 known ports in the unreserved range.
232 Implementations should take care not to cache authentication
233 information. In some cases, as with the simple "password"
234 authentication shceme defined in RFC 1835, authentication information
235 may take the form of clear text user names and passwords. This is a
236 WHOIS++ protocol issue and beyond the scope of this URL
237 specification.
239 6. Acknowledgements
241 Thanks to Jeff Allen, Lorcan Dempsey, Patrik Faltstrom, Jon Knight,
242 William F. Maton, Larry Masinter, and Scott Williamson for their
243 comments on draft versions of this document.
245 This work was supported by grant 12/39/01 from the UK Electronic
246 Libraries Programme (eLib) and grant RE 1004 from the European
247 Commission's Telematics for Research Programme.
249 7. References
251 Request For Comments (RFC) and Internet Draft documents are available
252 from and numerous mirror sites.
254 [1] P. Deutsch, R. Schoultz, P. Faltstrom and C.
255 Weider. "Architecture of the WHOIS++ service", RFC
256 1835. August 1995.
258 [2] T. Berners-Lee, L. Masinter and M. McCahill (eds).
259 "Uniform Resource Locators (URL)", RFC 1738.
260 December 1994.
262 [3] J. Postel. "Simple Mail Transfer Protocol", RFC
263 821. August 1982.
265 [4] J. Postel, J. K. Reynolds. "File Transfer Proto-
266 col", RFC 959. October 1985.
268 [5] The Unicode Standard, Worldwide Character Encoding,
269 Version 1.0, Volume 1, Addison-Wesley, 1990. ISBN
270 0-201-56788-1.
272 [6] The Unicode Standard, Worldwide Character Encoding,
273 Version 1.0, Volume 2, Addison-Wesley, 1992. ISBN
274 0-201-60845-6.
276 [7] K. Harrenstien, M.K. Stahl, E.J. Feinler.
277 "NICNAME/WHOIS", RFC 954. October 1985.
279 [8] S. Williamson & M. Kosters. "Referral Whois
280 Protocol (RWhois)", RFC 1714. November 1994.
282 [9] T. Berners-Lee, D. Connolly. "Hypertext Markup
283 Language - 2.0", RFC 1866. November 1995.
285 [10] R. Fielding. "Relative Uniform Resource Locators",
286 RFC 1808. June 1995.
288 [11] T. Berners-Lee, R. Fielding, H. Frystyk. "Hyper-
289 text Transfer Protocol -- HTTP/1.0", RFC 1945. May
290 1996.
292 8. Author's address
294 Martin Hamilton
295 Department of Computer Studies
296 Loughborough University of Technology
297 Leics. LE11 3TU, UK
299 Email: m.t.hamilton@lut.ac.uk
301 This Internet Draft expires November 19th, 1997.