idnits 2.17.1 draft-hoffman-news-nntp-uri-04.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 207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 197. ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...d the MUST be in a canonica...' 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 7041 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) == Unused Reference: 'RFC1036' is defined on line 148, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- 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) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- No information found for draft-fielding-uri-rfc2396bis-nn - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 news and nntp URI Schemes 7 draft-hoffman-news-nntp-uri-04.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 news and nntp Uniform Resource Identifier 43 (URI) schemes that were originally specified in RFC 1738. The 44 purpose of this document is to allow RFC 1738 to be made obsolete 45 while keeping 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 news and nntp URI schemes from it to allow that 56 material to remain on standards track. 58 Note: the definitions for the news and nntp URI schemes given here 59 are significant updates from RFC 1738 based on modern usage of these 60 schemes. 62 Note: it is likely that the specification in this document will 63 change based on input from the Usenet protocol community before this 64 document is finalized. 66 2. Scheme Definition 68 The news and nntp URL schemes are used to refer to either news groups 69 or individual articles of USENET news, as specified in RFC 1036. 71 The news URL takes the form: 73 newsURL = "news" ":" [ news-server ] 74 ( newsgroup-name | '*' | message-id ) 75 news-server = "//" server "/" 76 message-id = id-left "@" id-right 78 is defined in [2396bis]. Note that there is widespread use 79 of the username-password authentication in news servers, so news 80 clients should implement this part of the syntax. 82 2.1 The newsURL has a 84 The is a period-delimited hierarchical name, such as 85 "comp.lang.perl.modules". and are defined in 86 Section 3.6.4 of RFC 2822 [RFC2822]. 88 The resource retrieved by this URL is some means to gain access to 89 the articles in the given that are available on the 90 given (usually by invoking a suitable news reading agent 91 initialized to access that group). If no is specified, the 92 groups are to be retrieved from whatever server has been configured 93 for local use. 95 2.2 The newsURL has a * 97 If the last part of the newsURL is "*" (as in ), it is 98 used to refer to "all available news groups". The resource retrieved 99 by this URL is some means to gain access to all the newsgroups that 100 are available on the given (usually by invoking a suitable 101 news reading agent). If no is specified, the access is to 102 be to whatever server has been configured for local use. 104 2.3 The newsURL has a 106 The resource retrieved by this URL is the Netnews article with the 107 given . In a properly working Netnews system, the same 108 article will be obtained whatever server is accessed for the purpose 109 (assuming the server in question carried that article in the first 110 place and that it has not expired). If no is specified, the 111 article is to be retrieved from whatever server has been configured 112 for local use. 114 The and the MUST be in a canonical form in which 115 no or is used in a context where the 116 same semantic meaning could have been rendered without such quoting; 117 moreover, no whitespace may be included, whether %-encoded or not 118 and/or quoted or not. 120 For example, neither 122 news:"abcd"@example.com 124 nor 126 "ab\cd"@example.com 128 is in canonical form, because the form 130 abcd@example.com 132 is available. 134 2.4 The nntp URL scheme 136 The nntp URL defined in RFC 1738 is deprectated. This section is 137 likely to be replaced in a future version of this draft. 139 3. Security Considerations 141 There are many security considerations for URI schemes discussed in 142 [2396bis]. The news protocol uses passwords in the clear for 143 authentication, and offers no privacy, both of which are considered 144 extremely unsafe in current practice. 146 4 Informative References 148 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 149 USENET messages", RFC 1036, December 1987. 151 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 152 Resource Locators (URL)", RFC 1738, December 1994. 154 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 155 Resource Identifiers (URI): Generic Syntax", RFC 2396, 156 August 1998. 158 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 159 2001. 161 [2396bis] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 162 Resource Identifiers (URI): Generic Syntax", work in 163 progress, draft-fielding-uri-rfc2396bis-nn.txt. 165 Author's Address 167 Paul Hoffman 168 VPN Consortium 169 127 Segre Place 170 Santa Cruz, CA 95060 171 US 173 EMail: paul.hoffman@vpnc.org 175 Intellectual Property Statement 177 The IETF takes no position regarding the validity or scope of any 178 Intellectual Property Rights or other rights that might be claimed to 179 pertain to the implementation or use of the technology described in 180 this document or the extent to which any license under such rights 181 might or might not be available; nor does it represent that it has 182 made any independent effort to identify any such rights. Information 183 on the procedures with respect to rights in RFC documents can be 184 found in BCP 78 and BCP 79. 186 Copies of IPR disclosures made to the IETF Secretariat and any 187 assurances of licenses to be made available, or the result of an 188 attempt made to obtain a general license or permission for the use of 189 such proprietary rights by implementers or users of this 190 specification can be obtained from the IETF on-line IPR repository at 191 http://www.ietf.org/ipr. 193 The IETF invites any interested party to bring to its attention any 194 copyrights, patents or patent applications, or other proprietary 195 rights that may cover technology that may be required to implement 196 this standard. Please address the information to the IETF at 197 ietf-ipr@ietf.org. 199 Disclaimer of Validity 201 This document and the information contained herein are provided on an 202 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 203 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 204 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 205 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 206 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 207 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 209 Copyright Statement 211 Copyright (C) The Internet Society (2005). This document is subject 212 to the rights, licenses and restrictions contained in BCP 78, and 213 except as set forth therein, the authors retain all their rights. 215 Acknowledgment 217 Funding for the RFC Editor function is currently provided by the 218 Internet Society.