idnits 2.17.1 draft-ellermann-news-nntp-uri-11.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 906. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 912. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-usefor-usefor]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC1738, but the abstract doesn't seem to directly say this. It does mention RFC1738 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2, 2008) is 5840 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.hoffman-news-nntp-uri-04' is mentioned on line 860, but not defined -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Unexpected draft version: The latest known version of draft-gilman-news-url is -01, but you're referring to -02. -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4952 (Obsoleted by RFC 6530) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Ellermann 3 Internet-Draft xyzzy 4 Obsoletes: 1738 (if approved) April 2, 2008 5 Intended status: Standards Track 6 Expires: October 4, 2008 8 The 'news' and 'nntp' URI Schemes 9 draft-ellermann-news-nntp-uri-11 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 October 4, 2008. 36 Abstract 38 This memo specifies the 'news' and 'nntp' Uniform Resource Identifier 39 (URI) schemes that were originally defined in RFC 1738. The purpose 40 of this document is to allow RFC 1738 to be made obsolete while 41 keeping the information about these schemes on standards track. 43 Editorial note 45 In the collected ABNF (Appendix A) the NEWS in RFC NEWS should be 46 replaced by the RFC number for [I-D.ietf-usefor-usefor]. In 47 Section 8 RFCXXXX is a placeholder for this memo. This note and the 48 document history (Appendix C) should be removed before publication. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. 'nntp' URIs . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. 'news' URIs . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Query parts, fragments, and normalization . . . . . . . . 5 57 3. Syntax of 'nntp' URIs . . . . . . . . . . . . . . . . . . . . 5 58 4. Syntax of 'news' URIs . . . . . . . . . . . . . . . . . . . . 6 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Internationalization Considerations . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 8.1. 'snews' URIs . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.2. 'news-message-ID' access type . . . . . . . . . . . . . . 11 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13 69 Appendix B. Detailed example . . . . . . . . . . . . . . . . . . 15 70 Appendix C. Document History . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 Intellectual Property and Copyright Statements . . . . . . . . . . 21 74 1. Introduction 76 The first definition for many URI schemes appeared in [RFC1738]. 77 This memo extracts the 'news' and 'nntp' URI schemes from it to allow 78 that material to remain on standards track if [RFC1738] is moved to 79 "historic" status. It belongs to a series of similar documents like 80 [RFC4156], [RFC4157], [RFC4248], and [RFC4266] discussed on the 81 list. 83 The definitions for the 'news' and 'nntp' URI schemes given here are 84 updates from [RFC1738] based on modern usage of these schemes. This 85 memo intentionally limits its description of the 'news' URI scheme to 86 essential features supposed to work with "any browser" and NNTP 87 server. 89 [RFC3986] specifies how to define schemes for URIs, it also explains 90 the term "Uniform Resource Locator" (URL). The Network News Transfer 91 Protocol (NNTP) is specified in [RFC3977]. The Netnews Article 92 Format is defined in [I-D.ietf-usefor-usefor]. 94 The key word "MUST" in this memo is to be interpreted as described in 95 [RFC2119]. UTF-8 is specified in [RFC3629]. The syntax uses the 96 ABNF defined in [RFC5234]. 98 2. Background 100 The 'news' and 'nntp' URI schemes identify resources on an NNTP 101 server, individual articles, individual newsgroups, or sets of 102 newsgroups. 104 User agents like Web browsers supporting these schemes use the NNTP 105 protocol to access the corresponding resources. The details of how 106 they do this, e.g., employing a separate or integrated newsreader, 107 depend on the implementation. The default associated with 108 NNTP in [RFC3977] is 119. 110 2.1. 'nntp' URIs 112 The 'nntp' URI scheme identifies articles in a newsgroup on a 113 specific NNTP server. In [RFC3986] terminology this means that 114 'nntp' URIs have a non-empty component, there is no 115 default as for the 'file' or 'news' URI schemes. 117 Netnews is typically distributed among several news servers, using 118 the same newsgroup names, but local article numbers. An article 119 available as number 10 in group "example" on server 120 "news.example.com" has most likely a different number on any other 121 server where the same article is still available. Users allowed to 122 read and post articles on "their" server may not be allowed to access 123 articles on an "arbitrary" server specified in an 'nntp' URI. 125 For these reasons the use of the 'nntp' URI scheme is limited, and it 126 is less widely supported by user agents than the similar 'news' URI 127 scheme. 129 2.2. 'news' URIs 131 The 'news' URI scheme identifies articles by their worldwide unique 132 "Message-ID", independent of the server and the newsgroup. 133 Newsreaders support access to articles by their "Message-ID", without 134 the overhead of an URI scheme. In simple cases they do this directly 135 as NNTP client of a default or currently used server as configured by 136 the user. More general user agents use the 'news' URI scheme to 137 distinguish "Message-IDs" from similar constructs such as other URI 138 schemes in contexts such as a plain text message body. 140 The 'news' URI scheme also allows the identification of newsgroups or 141 sets of newsgroups independent of a specific server. For Netnews a 142 group "example" has the same name on any server carrying this group, 143 exotic cases involving gateways not withstanding. To distinguish 144 "Message-IDs" and newsgroup names the 'news' URI scheme relies on the 145 "@" between local part (left hand side) and domain part (right hand 146 side) of "Message-IDs". 148 [RFC1738] offered only one wildcard for sets of newsgroups in 'news' 149 URIs, a "*" used to refer to "all available newsgroups". In common 150 practice this was extended to varying degrees by different user 151 agents, an NNTP extension known as specified in [RFC2980] 152 and now part of the base NNTP specification allows pattern matching 153 in the style of the [POSIX] "find" command. For the purpose of this 154 memo this means that some additional special characters have to be 155 allowed in 'news' URIs, some of them percent-encoded as required by 156 the overall [RFC3986] URI syntax. User agents and NNTP servers not 157 yet compliant with [RFC3977] do not implement all parts of this new 158 feature. 160 Another commonly supported addition to the [RFC1738] syntax is the 161 optional specification of a server at the beginning of 'news' URIs. 162 This optional component follows the overall [RFC3986] 163 syntax preceded by a double slash "//" and terminated by the next 164 slash "/", question mark "?", number sign "#", or the end of the URI. 166 2.3. Query parts, fragments, and normalization 168 Fragments introduced by a number sign "#" are specified in [RFC3986], 169 the semantics is independent of the URI scheme, the resolution 170 depends on the media type. 172 This memo doesn't specify a query part introduced by a question mark 173 "?" for the 'news' and 'nntp' URI schemes, but some implementations 174 are known to use query parts instead of fragments internally to 175 address parts of a composite media type [RFC2046] in Multipurpose 176 Internet Mail Extensions (MIME). 178 There are no special "." or ".." path segments in 'news' and 'nntp' 179 URLs. Please note that "." and ".." are not valid s. 181 URI producers have to percent-encode some characters as specified 182 below (Section 4), otherwise they MUST treat a "Message-ID" without 183 angle brackets for 'news' URLs as is, i.e. case-sensitive, preserving 184 quoted pairs and quoted strings. 186 3. Syntax of 'nntp' URIs 188 An 'nntp' URI identifies an article by its number in a given 189 newsgroup on a specified server, or it identifies the newsgroup 190 without article number. 192 nntpURL = "nntp:" server "/" group [ "/" article-number ] 193 server = "//" authority ; see RFC 3986 194 group = 1*( group-char / pct-encoded ) 195 article-number = 1*16DIGIT ; see RFC 3977 196 group-char = ALPHA / DIGIT / "-" / "+" / "_" / "." 198 In the form with an the URL corresponds roughly to 199 the content of an header field as specified in 200 [I-D.ietf-usefor-usefor], replacing its more general 201 by the used with NNTP. 203 A as specified in [I-D.ietf-usefor-usefor] consists 204 of dot-separated components. Each component contains one or more 205 letters, digits, "-" (hyphen-minus), "+", or "_" (underscore). These 206 characters can be directly used in a segment of a path in a [RFC3986] 207 URI, no percent-encoding is necessary. Example: 209 nntp://news.server.example/example.group.this/12345 211 A newsgroup name as specified in [RFC3977] allows (in 212 theory) any , see Section 6, and most printable 213 US-ASCII characters excluding "!", "*", ",", "?", "[", "\", and "]". 214 However, [I-D.ietf-usefor-usefor] does not (yet) permit characters 215 outside of and so, to keep the syntax simple, the 216 additional characters are here covered by as defined in 217 [RFC3986], since most of them have to be percent-encoded anyway (with 218 a few exceptions such as ":", ";", and "~"). For example: 220 nntp://wild.server.example/example.group.n%2Fa/12345 222 In the form without the URL identifies a single 223 group on the specified server. This is also possible with an 224 equivalent 'news' URL, and the latter is better supported by user 225 agents, example: 227 nntp://news.server.example/example.group.this 228 news://news.server.example/example.group.this 230 4. Syntax of 'news' URIs 232 A 'news' URI identifies an article by its unique "Message-ID", or it 233 identifies a set of newsgroups. Additionally it can specify a 234 server, without it a configured default server for Netnews access is 235 used. 237 The syntax shown below explains how to transform a syntactically 238 valid or as specified in 239 [I-D.ietf-usefor-usefor] into the corresponding or 240
part of a 'news' URI. The transformation from a formally 241 valid 'news' URI back to a or is not 242 guaranteed to be syntactically valid. 244 newsURL = "news:" [ server "/" ] ( article / newsgroups ) 245 article = mid-left "@" mid-right 246 newsgroups = *( group-char / pct-encoded / "*" ) 248 mid-left = 1*( mid-atext / "." ) / ; 249 ( "%22" mid-quote "%22" ) ; 250 mid-quote = 1*( mid-atext / "." / ; incl. 251 mid-special / ; '\"' / "[" / "]" 252 "%5C%22" / "%5B" / "%5D" ) 254 mid-right = 1*( mid-atext / "." ) / ; 255 ( "%5B" mid-literal "%5D" ) ; 256 mid-literal = 1*( mid-atext / "." / ; incl. 257 mid-special / ; '"' / "\[" / "\]" 258 "%22" / "%5C%5B" / "%5C%5D" ) 260 mid-special = "(" / ")" / "," / ":" / ";" / 261 "%3C" / "%40" / "%5C%5C" ; "<" / "@" / "\\" 263 mid-atext = ALPHA / DIGIT / ; RFC 2822 264 "!" / "$" / "&" / "'" / ; allowed sub-delims 265 "*" / "+" / "=" / ; allowed sub-delims 266 "-" / "_" / "~" / ; allowed unreserved 267 "%23" / "%25" / "%2F" / ; "#" / "%" / "/" 268 "%3F" / "%5E" / "%60" / ; "?" / "^" / "`" 269 "%7B" / "%7C" / "%7D" ; "{" / "|" / "}" 271 The form identifying an
corresponds to the 272 construct in [I-D.ietf-usefor-usefor], it is a "Message-ID" without 273 angle brackets. Characters not directly allowed in this part of an 274 [RFC3986] URI have to be percent-encoded, minimally anything that is 275 not , no ":" (colon), and doesn't belong to the 276 . 278 Several details of a canonical are omitted here, e.g., 279 leading, adjacent, or trailing dots are not allowed in 280 . The syntax mainly shows which characters MUST be 281 percent-encoded in a (local part) or (domain 282 part). 284 Please note that "%20" (space) and "%3E" (">") are not allowed. A 285 "%5C" (backslash "\") can only occur in four combinations as shown 286 above. Examples: 288 news://server.example/ab.cd@example.com 289 news:%22do..ts%22@example.com 290 news:ab.cd@%5B2001:DB8::CD30%5D 292 The form identifying corresponds to the [RFC3977] 293 , a newsgroup name with wildcards "*" and "?". Any 294 "?" has to be percent-encoded as "%3F" in this part of an URI. 295 Examples, the first two are equivalent: 297 news://news.server.example/* 298 news://news.server.example/ 299 news://wild.server.example/example.group.th%3Fse 300 news:example.group.* 301 news:example.group.this 303 Without wildcards this form of the URL identifies a single group if 304 it is not empty, and user agents would typically try to present an 305 overview of the articles available in this group, likely somehow 306 limiting this overview to the newest unread articles up to a 307 configured maximum. 309 With wildcards user agents could try to list matching group names on 310 the specified or default server. Some user agents support only a 311 specific without wildcards, or an optional single "*". 313 As noted above (Section 2.2) the presence of an "@" in a 'news' URI 314 disambiguates
and for URI consumers. The new 315 construct specified in [RFC3977] does not require an 316 "@". Since [RFC0822] the "Message-ID" syntax was closely related to 317 the syntax of mail addresses with an "@" separating left hand side 318 (local part of addresses, unique part of message identifiers) and 319 right hand side (domain part), and this memo sticks to the known 320 [RFC1738] practice. 322 5. Acknowledgments 324 Henry Spencer was the driving force to adopt MIME in Netnews, he 325 registered the MIME 'message/external-body' access type 326 'news-message-ID' discussed below (Section 8.2) in 1993 for 327 [son-of-1036]. 329 The Internet Drafts [I-D.gilman-news-url] by Alfred S. Gilman 330 published 1998 introduced additions to the original [RFC1738] 'news' 331 URI scheme. Some of these ideas are now widely supported and 332 reflected by the revised 'news' URI scheme specified here. 334 Thanks to Alfred Hoenes, Charles Lindsey, Clive Feather, Chris 335 Newman, Ken Murchinson, Kjetil T. Homme, Lars Magne Ingebrigtsen, 336 Martin Duerst, Matt Seitz, Nicolas Krebs, Paul Hoffman, Pasi Eronen, 337 Roy T. Fielding, Russ Allbery, Stephane Bortzmeyer, and Tom Petch for 338 their feedback, contributions, or encouragement. 340 Bill Fenner's _xml2rfc validator_ and _ABNF checker_ were a great 341 help in the creation of (not only) this memo. The same goes for 342 various great _IETF tools_ written by Henrik Levkowetz. 344 6. Internationalization Considerations 346 The URI schemes were updated to support percent-encoded UTF-8 347 characters in NNTP newsgroup names as specified in [RFC3977] and 348 [RFC3987]. 350 The Netnews Article Format in [I-D.ietf-usefor-usefor] does not yet 351 allow UTF-8 in s, therefore well-known Unicode and 352 UTF-8 security considerations are not listed below. For an overview 353 see [UTR36] and [RFC3629]. 355 The work on E-mail Address Internationalization (EAI) started in 356 [RFC4952] is not expected to change the syntax of a "Message-ID". 357 The work on a successor of [RFC2822] hopefully ends up with a 358 simplified syntax for both sides of a "Message-ID". 360 7. Security Considerations 362 There are many security considerations for URI schemes discussed in 363 [RFC3986]. The NNTP protocol may use passwords in the clear for 364 authentication, or offer no privacy, both of which are considered 365 extremely unsafe in current practice. Alternatives and further 366 security considerations with respect to NNTP are discussed in 367 [RFC4642] and [RFC4643]. 369 The syntax for the 'news' and 'nntp' URI schemes contains the general 370 construct with an optional defined in 371 [RFC3986]. As noted in [RFC3986] the "user:password" form of a 372 is deprecated. 374 Articles on NNTP servers typically expire after some time. After 375 that time corresponding 'news' and 'nntp' URLs won't work anymore 376 depending on the server. While a "Message-ID" is supposed to be 377 worldwide unique forever the NNTP protocol does not guarantee this. 378 Under various conditions depending on the servers the same 379 "Message-ID" could be used for different articles, and attackers 380 could try to distribute malicious content for known 'news' or 'nntp' 381 URLs. 383 If an URI does not match the generic syntax in [RFC3986] it is 384 invalid, and broken URIs can cause havoc. Compare [RFC5064] for 385 similar security considerations. 387 8. IANA Considerations 389 The IANA registry of URI schemes should be updated to point to this 390 memo instead of [RFC1738] for the 'news' and 'nntp' URI schemes. 392 8.1. 'snews' URIs 394 This section contains the [RFC4395] template for the registration of 395 the historical 'snews' scheme specified in [I-D.gilman-news-url]. 397 URI scheme name: snews 399 Status: historical 401 URI scheme syntax: Same as for 'news' (Section 4) 403 URI scheme semantics: 404 Syntactically equivalent to 'news', but using NNTP 405 over SSL/TLS (SSL/TLS with security layer is 406 negotiated immediately after establishing the TCP 407 connection) with a default port of 563, registered 408 as "nntps" 410 Encoding considerations: 411 Same as for 'news' (Section 6) 413 Applications/protocols that use this URI scheme name: 414 For some user agents 'snews' URLs trigger the use 415 of "nntps" instead of NNTP for their access on 416 Netnews 418 Interoperability considerations: 419 This URI scheme was not widely deployed, its 420 further use is deprecated in favour of ordinary 421 'news' URLs in conjunction with NNTP servers 422 supporting [RFC4642] 424 Security considerations: 425 See [RFC4642], the use of a dedicated port for 426 secure variants of a protocol was discouraged in 427 [RFC2595] 429 Contact: (URI mailing list) 431 Change controller: IETF 432 References: RFCXXXX, [RFC4642], [I-D.gilman-news-url] 434 8.2. 'news-message-ID' access type 436 The MIME 'news-message-ID' access type was erroneously listed as 437 subtype. IANA should remove 'news-message-ID' from the application 438 subtype registry, and add it to the access type registry defined in 439 [RFC4289]: . 441 [RFC4289] requires an RFC for the access types registry. Because 442 [son-of-1036] was never published as RFC the following paragraph 443 quotes the relevant definition: 445 NOTE: In the specific case where it is desired to essentially make 446 another article PART of the current one, e.g. for annotation of 447 the other article, MIME's "message/external-body" convention can 448 be used to do so without actual inclusion. "news-message-ID" was 449 registered as a standard external-body access method, with a 450 mandatory NAME parameter giving the message ID and an optional 451 SITE parameter suggesting an NNTP site that might have the article 452 available (if it is not available locally), by IANA 22 June 1993. 454 Please note that 'news' URLs offer a very similar and (today) more 455 common way to access articles by their Message-ID, compare [RFC2017]. 457 9. References 459 9.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 465 RFC 3977, October 2006. 467 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 468 Resource Identifier (URI): Generic Syntax", STD 66, 469 RFC 3986, January 2005. 471 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 472 Specifications: ABNF", STD 68, RFC 5234, January 2008. 474 [I-D.ietf-usefor-usefor] 475 Lindsey, C., "Netnews Article Format", 476 draft-ietf-usefor-usefor-12 (work in progress), 477 January 2007. 479 9.2. Informative References 481 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 482 text messages", STD 11, RFC 822, August 1982. 484 [son-of-1036] 485 Spencer, H., "News Article Format and Transmission", 486 June 1994, . 488 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 489 Resource Locators (URL)", RFC 1738, December 1994. 491 [RFC2017] Freed, N. and K. Moore, "Definition of the URL MIME 492 External-Body Access-Type", RFC 2017, October 1996. 494 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 495 Extensions (MIME) Part Two: Media Types", RFC 2046, 496 November 1996. 498 [I-D.gilman-news-url] 499 Gilman, A., "The 'news' URL scheme", 500 Internet draft-gilman-news-url-02, March 1998, 501 . 503 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 504 RFC 2595, June 1999. 506 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 507 April 2001. 509 [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, 510 October 2000. 512 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 513 10646", STD 63, RFC 3629, November 2003. 515 [POSIX] Institute of Electrical and Electronics Engineers, "The 516 Open Group Base Specifications Issue 6", IEEE Standard 517 1003.1, 2004 edition, 518 . 520 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 521 Identifiers (IRIs)", RFC 3987, January 2005. 523 [RFC4156] Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005. 525 [RFC4157] Hoffman, P., "The prospero URI Scheme", RFC 4157, 526 August 2005. 528 [RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, 529 October 2005. 531 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 532 November 2005. 534 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 535 Extensions (MIME) Part Four: Registration Procedures", 536 BCP 13, RFC 4289, December 2005. 538 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 539 Registration Procedures for New URI Schemes", BCP 115, 540 RFC 4395, February 2006. 542 [UTR36] Davis, M. and M. Suignard, "Unicode Security 543 Considerations", Unicode Technical Reports #36, 544 August 2006, . 546 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 547 Transport Layer Security (TLS) with Network News Transfer 548 Protocol (NNTP)", RFC 4642, October 2006. 550 [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer 551 Protocol (NNTP) Extension for Authentication", RFC 4643, 552 October 2006. 554 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 555 Internationalized Email", RFC 4952, July 2007. 557 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 558 RFC 5064, December 2007. 560 Appendix A. Collected ABNF 562 In addition to the syntax given above this appendix also lists the 563 sources of terms used in comments and the prose: 565 nntpURL = "nntp:" server "/" group [ "/" article-number ] 566 server = "//" authority ; see RFC 3986 567 group = 1*( group-char / pct-encoded ) 568 article-number = 1*16DIGIT ; see RFC 3977 569 group-char = ALPHA / DIGIT / "-" / "+" / "_" / "." 571 newsURL = "news:" [ server "/" ] ( article / newsgroups ) 572 article = mid-left "@" mid-right 573 newsgroups = *( group-char / pct-encoded / "*" ) 574 mid-left = 1*( mid-atext / "." ) / ; 575 ( "%22" mid-quote "%22" ) ; 576 mid-quote = 1*( mid-atext / "." / ; incl. 577 mid-special / ; '\"' / "[" / "]" 578 "%5C%22" / "%5B" / "%5D" ) 580 mid-right = 1*( mid-atext / "." ) / ; 581 ( "%5B" mid-literal "%5D" ) ; 582 mid-literal = 1*( mid-atext / "." / ; incl. 583 mid-special / ; '"' / "\[" / "\]" 584 "%22" / "%5C%5B" / "%5C%5D" ) 586 mid-special = "(" / ")" / "," / ":" / ";" / 587 "%3C" / "%40" / "%5C%5C" ; "<" / "@" / "\\" 589 mid-atext = ALPHA / DIGIT / ; RFC 2822 590 "!" / "$" / "&" / "'" / ; allowed sub-delims 591 "*" / "+" / "=" / ; allowed sub-delims 592 "-" / "_" / "~" / ; allowed unreserved 593 "%23" / "%25" / "%2F" / ; "#" / "%" / "/" 594 "%3F" / "%5E" / "%60" / ; "?" / "^" / "`" 595 "%7B" / "%7C" / "%7D" ; "{" / "|" / "}" 597 authority = 598 host = 599 pct-encoded = 600 port = 601 sub-delims = 602 unreserved = 603 userinfo = 605 message-id = 606 UTF8-non-ascii = 607 wildmat = 608 wildmat-exact = 609 wildmat-pattern = 611 ALPHA = 612 DIGIT = 614 atext = 615 dot-atom-text = 617 article-locator = 618 mdtext = 619 mqtext = 620 msg-id-core = 621 newsgroup-name = 622 no-fold-literal = 623 no-fold-quote = 624 xref = 626 Appendix B. Detailed example 628 Here is an example of a mail to the 629 list with "Message-ID" . 631 is one of the various list 632 archives, it converts mails into Netnews articles. The header of 633 this article contains the following fields (among others): 635 Message-ID: 636 Xref: news.gmane.org gmane.ietf.tools:742 637 Archived-At: 639 The "Xref" roughly indicates the 742nd article in newsgroup 640 on this server. An 'nntp' 641 URL might be . For 642 details about the "Archived-At" URL see [RFC5064]. 644 The list software and list subscribers reading the list elsewhere 645 can't predict a server specific article number 742 in this archive. 646 If they know this server they can however guess the corresponding 647 URL. 649 In theory the list software could use the guessed 'news' URL in an 650 "Archived-At" header field, but if a list tries this it would likely 651 use . 653 Using domain literals in a "Message-ID" could cause collisions. A 654 collision might force the mail2news gateway in this example to invent 655 a new "Message-ID", and an attempt to guess the future URL on this 656 server would then fail. 658 Appendix C. Document History 660 Changes in version 11: 662 o Clarified that the semantics of fragments is never defined by an 663 URI scheme, but depends on the media type. Minor tweaks to make 664 the point that using query parts for this purpose is not state of 665 the art. 667 o Replaced the remains of the four letter word introduced in version 668 08 by a proper [POSIX] reference. 670 o Added a forward pointer to Section 6 as explanation why 671 does not exactly mirror the syntax. 673 o Added a disclaimer to Section 4 that the shown 'news' URI syntax 674 is actually a superset of the corresponding and 675 syntax, and in no way intended to redefine the 676 normative source. 678 o After some discussions about adding news.uri.arpa to the 679 nntp.uri.arpa registration for the Dynamic Delegation Discovery 680 System (DDDS) folks preferred to have no DDDS registration for 681 NNTP at all at this time. DDDS registrations for existing URI 682 schemes are possible when applications need them, proactive DDDS 683 registrations are unnecessary. 685 o Thanks to Lars for tolerating Appendix B as real example. 687 Changes in version 10: 689 o Fixed three editorial nits found in the Last Call, especially 690 changed "does not more require" via "does no more require" to 691 "does not require" based on Last Call feedback. Appendix D of 692 [RFC3977] does not mention this point. 694 Changes in version 09: 696 o Several modifications based on feedback from Tom Petch and 697 Stephane Bortzmeyer. Updated the references to [RFC5064] and 698 STD 68 [RFC5234]. 700 o Obfuscated a four letter word introduced in version 08 after a 701 discussion on the IETF IPR WG list. 703 o The note (Section 6) about the successor of [RFC2822] now states 704 that hopefully *both* sides of the "Message-ID" syntax will be 705 simplified. Some details also affecting SMTP (Simple Mail 706 Transfer Protocol) are still under discussion. 708 o Clive Feather reported that [RFC3977] does not require an "@" in 709 its new construct. As this is a major deviation from 710 among others STD 11 [RFC0822], [RFC1738], [son-of-1036], 711 [I-D.gilman-news-url], [RFC2822], [I-D.ietf-usefor-usefor], and 712 what existing URI consumers based on these documents expect it 713 cannot be simply adopted in a memo describing common practice. An 714 additional note (Section 4) corresponding to an older note 715 (Section 2.2) explains this deviation. 717 o Various I-D nits are apparently false positives, but using two 718 different spell-checkers helped. 720 Changes in version 08: 722 o Many editorial and stylistic improvements proposed by Charles 723 Lindsey adopted wholesale. 725 o Added another URI security consideration. Added another note why 726 this memo does not try to cover more NNTP features. Refrained 727 from adding expectations what future NNTP servers will do. The 728 author hopes that Netnews will survive, and that this memo helps. 729 Adding features known to not work everywhere could be 730 counterproductive. 732 o Rejected a proposal to "undocument" 'snews'. In 2006 folks on the 733 URI list preferred "document and deprecate". At this time 'snews' 734 was supported by at least two servers and two user agents. 736 o Sticked to the DDDS registration of 'nntp' in the style of the 737 existing 'ftp', 'http', and 'mailto' DDDS records as a clerical 738 task. 740 o Rejected a proposal to deviate from the syntax in 741 the normative reference [I-D.ietf-usefor-usefor] reflecting a 742 consensus of the IETF USEFOR WG formed after lengthy discussions. 744 Changes in version 07: 746 o Fixed two bugs introduced in version 06, Kjetil T. Homme spotted 747 the worst error, thanks. Rearranged the credits adding Henrik's 748 IETF tools. 750 o I-D nit about a missing reference for 751 [I-D.hoffman-news-nntp-uri-04] ignored, this string will go away 752 together with the document history (Appendix C). 754 o The I-D submission tool added an editorial note following the 755 abstract to the meta data of version 06, manual override attempt 756 for version 07. 758 o Review request sent to register@uri.arpa, this mail didn't make it 759 yet to . 761 Changes in version 06: 763 o Reference to [RFC5064] added. Added a security consideration 764 proposed by Chris Newman for the "Archived-At" header field also 765 here. 767 o Added an appendix with a detailed 'news', 'nntp', "Xref", and 768 "Archived-At" example. 770 o Use a more reliable e-mail address (and thanks for the feedback 771 from somebody who figured the new address out following obscure 772 contact or rev="made" links ;-) 774 o The USEFOR WG did not adopt this draft as work item, they are busy 775 to complete a document blocking the publication of 776 [I-D.ietf-usefor-usefor]. 778 o IANA revived the list mentioned in the 779 DDDS BCP. 781 o Added a note about EAI [RFC4952] and its most likely unmodified 782 "Message-ID" concept. 784 Changes in version 05: 786 o Added an attempt to cleanup the erroneous MIME application subtype 787 'news-message-ID' registration. This was meant to be a MIME 788 'message/external-body' access type as published in 789 . 791 o The 'news-message-ID' review request was posted 2007-02-19. 793 Changes in version 04: 795 o Minor editorial fixes. Just in case waiting for the IESG approval 796 of [I-D.ietf-usefor-usefor]. The 'snews' URI review request was 797 posted 2006-11-10. 799 o Two reviewers of the 'snews' registration template are now 800 apparently satisfied with the 'snews' URI scheme semantics. 802 Changes in version 03: 804 o The 'snews' semantics was improved after discussions with Chris 805 Newman and Ken Murchinson. 807 o Various editorial fixes proposed by Alfred Hoenes. 809 Changes in version 02: 811 o The referenced NNTP specifications got their RFC numbers, NNTP TLS 812 [RFC4642] added for info to the security considerations. 814 o The ABNF for an
was further simplified by extracting the 815 characters used on both sides of the "@", 816 i.e. within a quoted string for the unique part (left 817 hand side) or within a literal in square brackets for the domain 818 part (right hand side). Now it is obvious that the differences 819 between both sides are limited to '"', "[", and "]" as expected. 821 o Removed the dubious _1_ at the begin of the rule 822 based on an observation by Nicolas Krebs. 824 o Created a proper informative reference for the historical 825 [I-D.gilman-news-url]. The IETF archive offers only -01, a copy 826 of -02 covering 'snews' is now available below 827 . 829 o Other minor changes include the addition of a reference to 830 [UTR36], and the collected ABNF (Appendix A). 832 o The IANA registration template for the historical 'snews' URI 833 scheme was added. 835 o The IANA registration template for an "nntp.uri.arpa" NAPTR record 836 was added. If that record is correct the existing "ftp.uri.arpa" 837 and "http.uri.arpa" records could be updated, apparently they 838 don't remove the optional at the moment. 840 Changes in version 01: 842 o References of RFC 977 and RFC 2980 replaced by the now approved 843 NNTP base document [RFC3977]. 845 o Security considerations updated with a reference to the now 846 approved NNTP Auth document [RFC4643]. 848 o References of RFC 1036 and [RFC2822] replaced by the last called 849 [I-D.ietf-usefor-usefor]. 851 o References of RFC 2396 removed, the jumps from [RFC1738] to 852 [RFC3986] and from RFC 1036 to [I-D.ietf-usefor-usefor] are 853 interesting enough without talking about intermediate steps. 855 o [RFC1738] has no for the 'nntp' URI scheme, and this memo 856 isn't the place to invent new tricks for a rarely used scheme. 858 Changes in version 00: 860 o Derived from [I-D.hoffman-news-nntp-uri-04] after discussions on 861 the URI list. At this time what is now known as the Netnews 862 Article Format [I-D.ietf-usefor-usefor] was still far from ready, 863 and RFC977bis [RFC3977] not yet finished. 865 Author's Address 867 Frank Ellermann 868 xyzzy 869 Hamburg, Germany 871 Email: hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com 872 URI: http://purl.net/xyzzy/ 874 Full Copyright Statement 876 Copyright (C) The IETF Trust (2008). 878 This document is subject to the rights, licenses and restrictions 879 contained in BCP 78, and except as set forth therein, the authors 880 retain all their rights. 882 This document and the information contained herein are provided on an 883 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 884 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 885 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 886 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 887 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 888 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 890 Intellectual Property 892 The IETF takes no position regarding the validity or scope of any 893 Intellectual Property Rights or other rights that might be claimed to 894 pertain to the implementation or use of the technology described in 895 this document or the extent to which any license under such rights 896 might or might not be available; nor does it represent that it has 897 made any independent effort to identify any such rights. Information 898 on the procedures with respect to rights in RFC documents can be 899 found in BCP 78 and BCP 79. 901 Copies of IPR disclosures made to the IETF Secretariat and any 902 assurances of licenses to be made available, or the result of an 903 attempt made to obtain a general license or permission for the use of 904 such proprietary rights by implementers or users of this 905 specification can be obtained from the IETF on-line IPR repository at 906 http://www.ietf.org/ipr. 908 The IETF invites any interested party to bring to its attention any 909 copyrights, patents or patent applications, or other proprietary 910 rights that may cover technology that may be required to implement 911 this standard. Please address the information to the IETF at 912 ietf-ipr@ietf.org. 914 Acknowledgment 916 This document was produced using xml2rfc v1.33 (of 917 http://xml.resource.org/) from a source in RFC-2629 XML format.