idnits 2.17.1 draft-kohn-news-article-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 draft header indicates that this document obsoletes RFC1036, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2822, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2822, updated by this document, for RFC5378 checks: 1996-11-27) -- 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 (March 27, 2003) is 7701 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) == Missing Reference: 'CFWS' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2646 (Obsoleted by RFC 3676) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 977 (Obsoleted by RFC 3977) -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kohn 3 Internet-Draft Skymoon Ventures 4 Updates: 2822 (if approved) March 27, 2003 5 Obsoletes: 1036 (if approved) 6 Expires: September 25, 2003 8 News Article Format 9 draft-kohn-news-article-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 25, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document defines the format of network news articles. 41 Network news articles resemble mail messages but are broadcast to 42 potentially large audiences, using a flooding algorithm that 43 propagates one copy to each interested host (or group thereof), 44 typically stores only one copy per host, and does not require any 45 central administration or systematic registration of interested 46 users. Network news originated as the medium of communication for 47 Usenet, circa 1980. Since then Usenet has grown explosively, and many 48 Internet sites participate in it. In addition, the news technology is 49 now in widespread use for other purposes, on the Internet and 50 elsewhere. 52 This document defines the format of network news articles in the 53 context of the Internet Message Format, and adds Multipurpose 54 Internet Mail Extensions (MIME) support for multimedia and 55 internationalized message bodies. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Requirements Notation . . . . . . . . . . . . . . . . . . 4 62 1.3 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 64 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.6 Structure of This Document . . . . . . . . . . . . . . . . 4 66 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 5 69 2.3 Other MIME Support . . . . . . . . . . . . . . . . . . . . 5 70 3. Headers . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1 New Internet Message Format Headers . . . . . . . . . . . 6 72 3.2 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 6 73 3.3 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.4 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.5 Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.6 News Headers . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.6.1 Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.6.2 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.6.3 Followup-To . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.6.4 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.6.5 Control . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.6.6 Distribution . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.6.8 Approved . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.6.9 Organization . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.6.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.6.11 Supersedes . . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.7 Other Message Headers . . . . . . . . . . . . . . . . . . 11 89 4. Internationalization Considerations . . . . . . . . . . . 12 90 5. Security Considerations . . . . . . . . . . . . . . . . . 13 91 Normative References . . . . . . . . . . . . . . . . . . . 14 92 Informative References . . . . . . . . . . . . . . . . . . 15 93 Author's Address . . . . . . . . . . . . . . . . . . . . . 16 94 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 95 Intellectual Property and Copyright Statements . . . . . . 18 97 1. Introduction 99 1.1 Scope 101 "Netnews" is a set of protocols for generating, storing and 102 retrieving news "articles" (which use the Internet Message Format) 103 and for exchanging them among a readership which is potentially 104 widely distributed. It is organized around "newsgroups", with the 105 expectation that each reader will be able to see all articles posted 106 to each newsgroup in which she participates. These protocols most 107 commonly use a flooding algorithm which propagates copies throughout 108 a network of participating servers. Typically, only one copy is 109 stored per server, and each server makes it available on demand to 110 readers able to access that server. 112 This is the first of four documents that obsolete RFC 1036. This 113 document focuses on the syntax and semantics of network news 114 articles. [useprot] is also a standards-track document, and 115 describes the protocol issues of network news articles, independent 116 of transmission protocols such as NNTP [RFC0977] and IMAP [RFC3501]. 117 An informational document, [useimpl], describes implementation 118 recommendations to improve interoperability and usability. The 119 fourth document, [useint], an experimental standard, specifies 120 internationalization of message headers. 122 The predecessor to this document [RFC1036] said that: "In any 123 situation where this standard conflicts with the Internet [email 124 standard, the latter] should be considered correct and this standard 125 in error." The basic philosophy of this document follows that 126 previous convention, so as to standardize news article syntax firmly 127 in the context of Internet Message Format syntax. In the context of 128 the Internet messaging architecture, different protocols (such as 129 IMAP, POP3 [RFC1939], NNTP and SMTP [RFC2821]) are seen as 130 alternative ways of moving around the same content. That content is 131 the Internet Message Format as specified by [RFC2822], including 132 optional enhancements such as MIME [RFC2049]. A user should be able 133 to ingest an article via NNTP, read it via IMAP, forward it off to 134 someone else via SMTP and have them read it via POP3 all without 135 having to alter the content. 137 This document uses a cite by reference methodology, rather than 138 trying to repeat the contents of other standards, which could 139 otherwise result in subtle differences and interoperability 140 challenges. Although this document is as a result rather short, it 141 requires complete understanding and implementation of the normative 142 references to be compliant. 144 1.2 Requirements Notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 1.3 Errata 152 The RFC Editor makes available errata for RFCs at [errata]. 153 Implementers should review that page for normative references, noting 154 in particular that errata currently exist for [RFC2046]. 156 1.4 Syntax Notation 158 Headers defined in this specification use the Augmented Backus-Naur 159 Form (ABNF) notation (including the Core Rules) specified in 160 [RFC2234] and many constructs (specifically , 161 , , and ) defined in [RFC2822]. 162 Section 3.5 updates the [RFC2822] definition of . 164 1.5 Definitions 166 Add definitions here for at least article, user agent, injector, 167 moderator, server, and gateway. Agent refers generically to all 168 roles. 170 1.6 Structure of This Document 172 Section 2 defines the format of news articles. Section 3 defines some 173 additional headers necessary for the netnews environment. 175 2. Format 177 2.1 Base 179 News articles MUST conform to the "legal to generate syntax" 180 specified in Section 3 of [RFC2822]. News agents SHOULD also support 181 the obsolete syntax specified in Section 4 of [RFC2822], particularly 182 to support old news messages and gatewayed obsolete mail messages, 183 but they MUST NOT generate such syntax. 185 2.2 MIME Conformance 187 User agents MUST meet the definition of MIME-conformance in 188 [RFC2049]. This level of MIME Conformance provides support for 189 internationalization and multimedia in message bodies, and for 190 receipt (but not generation) of internationalized headers. 191 Generation of internationalized message headers is specified by 192 [useint]. 194 2.3 Other MIME Support 196 User agents conformant with this document SHOULD support receipt (and 197 automatic reassembly) of message/partial MIME messages, as specified 198 in Section 5.2.2 of [RFC2046] and MAY support generation of message/ 199 partial articles for excessively large articles. 201 User agents SHOULD send regular paragraph text as "text/plain; 202 format=flowed" as specified in [RFC2646] and SHOULD preserve flowed 203 text (including quoting) when replying or forwarding, as described in 204 that specification. 206 User agents SHOULD support on receipt and MAY generate MIME extension 207 header fields, including but not limited to Content-Disposition 208 [RFC2183] and Content-Language [RFC3282]. 210 3. Headers 212 3.1 New Internet Message Format Headers 214 The following header fields extend the fields defined in section 3.6 215 of [RFC2822] as follows: 217 fields =/ *( newsgroups / 218 path / 219 followup-to / 220 expires / 221 control / 222 distribution / 223 summary / 224 approved / 225 organization / 226 xref / 227 supersedes ) 229 Each of these headers may occur at most once in a news article. 231 3.2 Mandatory Headers 233 Each news article conformant with this specification MUST have 234 exactly one of each of the following headers: From, Subject, 235 Message-ID, Date, Newsgroups, and Path. 237 From is exactly as specified in Section 3.6.2 of [RFC2822]. Date and 238 Subject are fully conformant with [RFC2822], though with extra detail 239 in Section 3.3 and Section 3.4, respectively. 241 In Section 3.5, this document updates the construct from 242 [RFC2822] so as to ensure that Internet Message Format Message-IDs 243 are usable in widely deployed news software. 245 Following [RFC2822] syntax, the headers defined in this document do 246 not require a space between the ":" and the field's contents. (E.g., 247 "Subject:Hello World" is acceptable, as opposed to requiring 248 "Subject: Hello World".) To be compliant with this specification, 249 news agents MUST support 0 or more spaces between the colon and the 250 field's contents. However, to maximize compatibility with the 251 installed base of news agents, implementers SHOULD use exactly one 252 space. 254 3.3 Date 256 The Date header is the same as that specified in Sections 3.3 and 257 3.6.1 of [RFC2822]. However, the use of "GMT" as a time zone, which 258 is part of , is widespread in news articles today. 259 Therefore, agents MUST accept, but MUST NOT generate, 260 constructs where ="GMT". (As stated in Section 2.1, support 261 for would otherwise have been SHOULD accept, MUST NOT 262 generate.) Note that these requirements apply wherever is 263 used, including Expires in Section 3.6.4. 265 3.4 Subject 267 The Subject header contains a short string identifying the topic of 268 the message. Section 3.6.5 of [RFC2822] says: 270 When used in a reply, the field body MAY start with the string 271 "Re: " (from the Latin "res", in the matter of) followed by the 272 contents of the "Subject:" field body of the original message. If 273 this is done, only one instance of the literal string "Re: " ought 274 to be used since use of other strings or more than one instance 275 can lead to undesirable consequences. 277 Because of the importance of threading in news, that MAY is amplified 278 to a SHOULD: Follow-ups to an article SHOULD begin with the subject 279 "Re: " followed by the original subject of the referenced article 280 (with that original subject stripped of any starting "Re: "). 282 User agents MAY remove strings that are known to be used erroneously 283 as back-reference (such as "Re(2): ", "Re:", "RE: ", or "Sv: ") from 284 the beginning of the Subject field body when composing the subject of 285 a followup, and add a correct back-reference in front of the result. 287 User agents replying to a message MUST NOT use any other string 288 except "Re: " as a back reference. Specifically, a translation of 289 "Re: " into a local language or usage MUST NOT be used. 291 User agents MAY present to the user a translation of "Re: ", but this 292 MUST only be an artifact of the user interface and MUST NOT be part 293 of the actual news article. 295 3.5 Message-ID 297 The "Message-ID:" field contains a single unique message identifier. 298 This is the only header field definition that updates [RFC2822]. The 299 ABNF should be used as below, but the requirements and descriptive 300 text from Section 3.6.4 of [RFC2822] still apply. 302 message-id = "Message-ID:" msg-id CRLF 304 msg-id = [CFWS] msg-id-core [CFWS] 306 msg-id-core = "<" id-left "@" id-right ">" 307 ; maximum length is 250 octets 309 id-left = dot-atom-text / no-fold-quote / obs-id-left 311 id-right = dot-atom-text / no-fold-literal / obs-id-right 313 no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE 315 no-fold-literal = "[" *( htext / no-space-qp ) "]" 317 no-space-qp = ( "\" ptext ) / obs-qp 319 ptext = %d33-61 / ; Printable characters excluding ">" 320 %d63-126 / 321 obs-text 323 htext = HEXDIG / ; hexadecimal digits, case-insensitive 324 "." / ; IPv4 separator 325 ":" ; IPv6 separator 327 Although compliant agents MUST support [CFWS] between the 328 "Message-ID:" and the , implementers SHOULD generate 329 exactly one space there, to maximize compatibility with the installed 330 base. 332 Note that this updated ABNF applies wherever is used, 333 including the In-Reply-To and References headers mentioned in Section 334 3.7. 336 3.6 News Headers 338 3.6.1 Newsgroups 340 The Newsgroups header specifies to which newsgroup(s) the article is 341 posted. 343 newsgroups = "Newsgroups:" newsgroup-list CRLF 345 newsgroup-list = [FWS] newsgroup-name 346 *( "," [FWS] newsgroup-name ) [FWS] 348 newsgroup-name = component *( "." component ) ; 71 character max 350 component = plain-component 352 plain-component = component-start *29component-rest 354 component-start = ALPHA / DIGIT 356 component-rest = ALPHA / DIGIT / "+" / "-" / "_" 358 A newsgroup name consists of one or more components separated by 359 periods, with no more than 71 characters total. Each component 360 consists of less than 30 or less letters and digits. 362 3.6.2 Path 364 The Path header's content indicates which relayers the article has 365 already visited, so that unnecessary redundant transmission can be 366 avoided. 368 path = "Path:" [FWS] 369 *( path-host [FWS] path-delimiter [FWS] ) 370 path-host [FWS] CRLF 372 path-host = ( ALPHA / DIGIT ) 373 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 375 path-delimiter = "!" 377 3.6.3 Followup-To 379 The Followup-To header specifies to which newsgroup(s) followups 380 should be posted. 382 followup-to = "Followup-To:" ( newsgroup-list / poster-text ) 383 CRLF 385 poster-text = [FWS] %d112.111.115.116.101.114 [FWS] 386 ; "poster" in lower-case 388 The syntax is the same as that of the Newsgroups content, with the 389 exception that the magic word "poster" (which is always lowercase) 390 means that followups should be mailed to the article's reply address 391 rather than posted. 393 3.6.4 Expires 395 The Expires header specifies a date and time when the article is 396 deemed to be no longer useful and could usefully be removed 397 ("expired"). 399 expires = "Expires:" date-time CRLF 401 3.6.5 Control 403 The Control header marks the article as a control message, and 404 specifies the desired actions (additional to the usual ones of 405 storing and/or relaying the article). The verb indicates what action 406 should be taken, and the argument(s) (if any) supply details. In some 407 cases, the body of the article may also contain details. Control 408 messages are further specified in the companion document, [useprot]. 410 control = "Control:" verb *( FWS argument ) CRLF 412 An article with a Control header MUST NOT have a Supersedes header. 414 3.6.6 Distribution 416 The Distribution header specifies geographic or organizational limits 417 on an article's propagation. 419 distribution = "Distribution:" dist-name *( "," dist-name ) CRLF 421 dist-name = [FWS] ALPHA / DIGIT 422 *( ALPHA / DIGIT / "+" / "-" / "_" ) [FWS] 424 "All" MUST NOT be used as a distribution-name. Distribution-names 425 SHOULD contain at least three characters, except when they are 426 two-letter country names as in [ISO.3166.1988]. Distribution-names 427 are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify the 428 same distribution). 430 3.6.7 Summary 432 The Summary header is a short phrase summarizing the article's 433 content. 435 summary = "Summary:" unstructured CRLF 437 3.6.8 Approved 439 The Approved header indicates the mailing addresses (and possibly the 440 full names) of the persons or entities approving the article for 441 posting. 443 approved = "Approved:" mailbox-list CRLF 445 3.6.9 Organization 447 The Organization header is a short phrase identifying the poster's 448 organization. 450 organization = "Organization:" unstructured CRLF 452 There is no "s" in Organization. 454 3.6.10 Xref 456 The Xref header indicates where an article was filed by the last 457 relayer to process it. 459 xref = "Xref:" [CFWS] path-host 460 1*( CFWS location ) [CFWS] 462 location = newsgroup-name ":" 1*16DIGIT 464 3.6.11 Supersedes 466 The Supersedes header specifies articles to be cancelled. 468 supersedes = "Supersedes:" 1*( [FWS] msg-id-core ) CRLF 470 There is no "c" in Supersedes. 472 3.7 Other Message Headers 474 The headers Reply-To, Sender, Comments, and Keywords are often used 475 in news articles and have the identical meaning as that specified in 476 [RFC2822]. References and In-Reply-To are also regularly used in 477 news articles and have same the same meaning as that specified in 478 [RFC2822], except that they use the updated construct 479 defined in Section 3.5. 481 4. Internationalization Considerations 483 Internationalization of news article bodies is provided using MIME 484 mechanisms in Section 2.2. Generation of internationalized message 485 headers is not specified in this document, and is instead specified 486 in the experimental standard, [useint]. 488 5. Security Considerations 490 The news article format specified in this document does not provide 491 any security services, such as confidentiality, authentication of 492 sender, or non-forgery. Instead, such services need to be layered 493 above, using such protocols as S/MIME [RFC2633] or PGP/MIME 494 [RFC3156], or below, using secure versions of news transport 495 protocols. Additionally, several currently non-standardized 496 protocols [PGPVERIFY] will hopefully be standardized in the near 497 future. 499 Message-IDs (see Section 3.5) in news are required to be unique; 500 articles are refused (in server-to-server transfer) if the ID has 501 already been seen. So if you can predict the ID of a message, you can 502 preempt it by posting a message (possibly to a quite different group) 503 with the same ID, stopping your target message from propagating. 504 Agents that generate message-ids for news articles SHOULD ensure that 505 they are unpredictable. 507 Normative References 509 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 510 Extensions (MIME) Part Two: Media Types", RFC 2046, 511 November 1996. 513 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 514 Extensions (MIME) Part Five: Conformance Criteria and 515 Examples", RFC 2049, November 1996. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating 521 Presentation Information in Internet Messages: The 522 Content-Disposition Header Field", RFC 2183, August 1997. 524 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 525 Specifications: ABNF", RFC 2234, November 1997. 527 [RFC2646] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, 528 August 1999. 530 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 531 2001. 533 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 534 2002. 536 Informative References 538 [ISO.3166.1988] 539 International Organization for Standardization, "Codes for 540 the representation of names of countries, 3rd edition", 541 ISO Standard 3166, August 1988. 543 [PGPVERIFY] 544 Lawrence, D., "PGPverify ", June 1999. 547 [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer 548 Protocol", RFC 977, February 1986. 550 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 551 USENET messages", RFC 1036, December 1987. 553 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 554 STD 53, RFC 1939, May 1996. 556 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 557 RFC 2633, June 1999. 559 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 560 April 2001. 562 [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, 563 "MIME Security with OpenPGP", RFC 3156, August 2001. 565 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 566 4rev1", RFC 3501, March 2003. 568 [errata] "RFC Editor Errata ". 571 [useimpl] "Usenet Implementation Recommendations (work in 572 progress)". 574 [useint] "Usenet Internationalization (work in progress)". 576 [useprot] "Usenet Protocol (work in progress)". 578 Author's Address 580 Dan Kohn 581 Skymoon Ventures 582 3045 Park Boulevard 583 Palo Alto, California 94306 584 USA 586 Phone: +1-650-327-2600 587 EMail: dan@dankohn.com 588 URI: http://www.dankohn.com/ 590 Appendix A. Acknowledgements 592 Comments and/or text were provided by Mark Crispin, Claus Faerber, 593 Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, 594 Bruce Lilly, Charles Lindsey, Ken Murchison, Pete Resnick, and Henry 595 Spencer. 597 Intellectual Property Statement 599 The IETF takes no position regarding the validity or scope of any 600 intellectual property or other rights that might be claimed to 601 pertain to the implementation or use of the technology described in 602 this document or the extent to which any license under such rights 603 might or might not be available; neither does it represent that it 604 has made any effort to identify any such rights. Information on the 605 IETF's procedures with respect to rights in standards-track and 606 standards-related documentation can be found in BCP-11. Copies of 607 claims of rights made available for publication and any assurances of 608 licenses to be made available, or the result of an attempt made to 609 obtain a general license or permission for the use of such 610 proprietary rights by implementors or users of this specification can 611 be obtained from the IETF Secretariat. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights which may cover technology that may be required to practice 616 this standard. Please address the information to the IETF Executive 617 Director. 619 Full Copyright Statement 621 Copyright (C) The Internet Society (2003). All Rights Reserved. 623 This document and translations of it may be copied and furnished to 624 others, and derivative works that comment on or otherwise explain it 625 or assist in its implementation may be prepared, copied, published 626 and distributed, in whole or in part, without restriction of any 627 kind, provided that the above copyright notice and this paragraph are 628 included on all such copies and derivative works. However, this 629 document itself may not be modified in any way, such as by removing 630 the copyright notice or references to the Internet Society or other 631 Internet organizations, except as needed for the purpose of 632 developing Internet standards in which case the procedures for 633 copyrights defined in the Internet Standards process must be 634 followed, or as required to translate it into languages other than 635 English. 637 The limited permissions granted above are perpetual and will not be 638 revoked by the Internet Society or its successors or assignees. 640 This document and the information contained herein is provided on an 641 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 642 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 643 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 644 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 645 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Acknowledgement 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.