idnits 2.17.1 draft-hoffman-gopher-uri-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2005) is 7033 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) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- No information found for draft-fielding-uri-rfc2396bis-nn - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Expires: July 2, 2005 January 2005 6 The gopher URI Scheme 7 draft-hoffman-gopher-uri-03.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies the gopher1 Uniform Resource Identifier (URI) 43 scheme that was originally specified in RFC 1738. The purpose of 44 this document is to allow RFC 1738 to be made obsolete while keeping 45 the information about the scheme on standards track. 47 1. Introduction 49 URIs were previously defined in RFC 2396 [RFC2396], which was updated 50 by draft-fielding-uri-rfc2396bis [2396bis]. Those documents also 51 specify how to define schemes for URIs. 53 The first definition for many URI schemes appeared in RFC 1738 54 [RFC1738]. Because that document has been made obsolete, this 55 document copies the gopher URI scheme from it to allow that material 56 to remain on standards track. 58 2. Scheme Definition 60 The gopher URL scheme is used to designate Internet resources 61 accessible using the Gopher protocol. 63 The base Gopher protocol is described in RFC 1436 [RFC1436] and 64 supports items and collections of items (directories). The Gopher+ 65 protocol is a set of upward compatible extensions to the base Gopher 66 protocol and is described in [Gopher+]. Gopher+ supports associating 67 arbitrary sets of attributes and alternate data representations with 68 Gopher items. Gopher URLs accommodate both Gopher and Gopher+ items 69 and item attributes. 71 Historical note: The Gopher protocol was widely implemented in the 72 early 1990s, but few Gopher servers are in use today. 74 2.1 Gopher URL syntax 76 A Gopher URL takes the form: 78 gopher://:/ 80 where is one of: 82 83 %09 84 %09%09 86 If : is omitted, the port defaults to 70. is a 87 single-character field to denote the Gopher type of the resource to 88 which the URL refers. The entire may also be empty, in 89 which case the delimiting "/" is also optional and the 90 defaults to "1". 92 is the Gopher selector string. In the Gopher protocol, 93 Gopher selector strings are a sequence of octets which may contain 94 any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal 95 (US-ASCII character LF), and 0D (US-ASCII character CR). 97 Gopher clients specify which item to retrieve by sending the Gopher 98 selector string to a Gopher server. 100 Within the , no characters are reserved. 102 Note that some Gopher strings begin with a copy of the 103 character, in which case that character will occur twice 104 consecutively. The Gopher selector string may be an empty string; 105 this is how Gopher clients refer to the top-level directory on a 106 Gopher server. 108 2.2 Specifying URLs for Gopher Search Engines 110 If the URL refers to a search to be submitted to a Gopher search 111 engine, the selector is followed by an encoded tab (%09) and the 112 search string. To submit a search to a Gopher search engine, the 113 Gopher client sends the string (after decoding), a tab, 114 and the search string to the Gopher server. 116 2.3 URL syntax for Gopher+ items 118 Historical note: Gopher+ was uncommon even when Gopher was popular. 120 URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+ 121 string. Note that in this case, the %09 string must be 122 supplied, although the element may be the empty string. 124 The is used to represent information required for 125 retrieval of the Gopher+ item. Gopher+ items may have alternate 126 views, arbitrary sets of attributes, and may have electronic forms 127 associated with them. 129 To retrieve the data associated with a Gopher+ URL, a client will 130 connect to the server and send the Gopher selector, followed by a tab 131 and the search string (which may be empty), followed by a tab and the 132 Gopher+ commands. 134 2.4 Default Gopher+ data representation 136 When a Gopher server returns a directory listing to a client, the 137 Gopher+ items are tagged with either a "+" (denoting Gopher+ items) 138 or a "?" (denoting Gopher+ items which have a +ASK form associated 139 with them). A Gopher URL with a Gopher+ string consisting of only a 140 "+" refers to the default view (data representation) of the item 141 while a Gopher+ string containing only a "?" refer to an item with a 142 Gopher electronic form associated with it. 144 2.5 Gopher+ items with electronic forms 146 Gopher+ items which have a +ASK associated with them (i.e. Gopher+ 147 items tagged with a "?") require the client to fetch the item's +ASK 148 attribute to get the form definition, and then ask the user to fill 149 out the form and return the user's responses along with the selector 150 string to retrieve the item. Gopher+ clients know how to do this but 151 depend on the "?" tag in the Gopher+ item description to know when to 152 handle this case. The "?" is used in the Gopher+ string to be 153 consistent with Gopher+ protocol's use of this symbol. 155 2.6 Gopher+ item attribute collections 157 To refer to the Gopher+ attributes of an item, the Gopher URL's 158 Gopher+ string consists of "!" or "$". "!" refers to the all of a 159 Gopher+ item's attributes. "$" refers to all the item attributes for 160 all items in a Gopher directory. 162 2.7 Referring to specific Gopher+ attributes 164 To refer to specific attributes, the URL's gopher+_string is 165 "!" or "$". For example, to refer to 166 the attribute containing the abstract of an item, the gopher+_string 167 would be "!+ABSTRACT". 169 To refer to several attributes, the gopher+_string consists of the 170 attribute names separated by coded spaces. For example, 171 "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes 172 of an item. 174 2.8 URL syntax for Gopher+ alternate views 176 Gopher+ allows for optional alternate data representations (alternate 177 views) of items. To retrieve a Gopher+ alternate view, a Gopher+ 178 client sends the appropriate view and language identifier (found in 179 the item's +VIEW attribute). To refer to a specific Gopher+ 180 alternate view, the URL's Gopher+ string would be in the form: 182 +%20 184 For example, a Gopher+ string of "+application/postscript%20Es_ES" 185 refers to the Spanish language postscript alternate view of a Gopher+ 186 item. 188 2.9 URL syntax for Gopher+ electronic forms 190 The gopher+_string for a URL that refers to an item referenced by a 191 Gopher+ electronic form (an ASK block) filled out with specific 192 values is a coded version of what the client sends to the server. 193 The gopher+_string is of the form: 195 +%091%0D%0A+-1%0D%0A%0D%0A 196 %0D%0A.%0D%0A 198 To retrieve this item, the Gopher client sends the following text to 199 the Gopher server. 201 +1 202 +-1 203 204 205 . 207 3. Security Considerations 209 There are many security considerations for URI schemes discussed in 210 [2396bis]. The gopher protocol uses passwords in the clear for 211 authentication, and offers no privacy, both of which are considered 212 extremely unsafe in current practice. 214 4 Informative References 216 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 217 Resource Locators (URL)", RFC 1738, December 1994. 219 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 220 Resource Identifiers (URI): Generic Syntax", RFC 2396, 221 August 1998. 223 [2396bis] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 224 Resource Identifiers (URI): Generic Syntax", work in 225 progress, draft-fielding-uri-rfc2396bis-nn.txt. 227 [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 228 Torrey, D. and B. Alberti, "The Internet Gopher Protocol 229 (a distributed document search and retrieval protocol)", 230 RFC 1436, March 1993. 232 Author's Address 234 Paul Hoffman 235 VPN Consortium 236 127 Segre Place 237 Santa Cruz, CA 95060 238 US 240 EMail: paul.hoffman@vpnc.org 242 Intellectual Property Statement 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at 264 ietf-ipr@ietf.org. 266 Disclaimer of Validity 268 This document and the information contained herein are provided on an 269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 271 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 272 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 273 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Copyright Statement 278 Copyright (C) The Internet Society (2005). This document is subject 279 to the rights, licenses and restrictions contained in BCP 78, and 280 except as set forth therein, the authors retain all their rights. 282 Acknowledgment 284 Funding for the RFC Editor function is currently provided by the 285 Internet Society.