idnits 2.17.1 draft-ietf-lemonade-submit-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction section. ** 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 173: '... The client MUST set an appropriate...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 360 has weird spacing: '...> retry for...' -- 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 (October 2003) is 7489 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: 'KEYWORDS' is mentioned on line 92, but not defined -- No information found for draft-newman-lemonade-compose-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BURL' ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- No information found for draft-crispin-imap-urlauth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'URLAUTH' -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: IMAP Submit Without Download R. Gellens, Editor 3 Document: draft-ietf-lemonade-submit-01.txt Qualcomm 4 Expires: April 2004 October 2003 6 IMAP Submit Without Download 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 IMAP clients, especially those operating over low-bandwidth or 36 high-latency links (such as cellular telephones) need to be able to 37 submit mail messages containing all or part of previously-received 38 IMAP messages. Clients need to be able to do this without sloshing 39 the bits both ways, that is, without being forced to download IMAP 40 messages solely to be able to upload the content in a submitted 41 message. 43 Gellens [Page 1] Expires April 2004 44 This document currently identifies two main approaches to doing this 45 (called "IMAP push" and "IMAP pull"), one which adds submission to 46 IMAP, and another which adds the expansion of IMAP references to 47 message submission. This version of the document attempts to lay 48 out the protocol mechanisms along with associated trade-offs and 49 security considerations of each. Once a decision has been made to 50 go with a particular technique, this document will describe the 51 specifics of that choice as a standards-track proposal. 53 Gellens [Page 2] Expires April 2004 54 Table of Contents 56 1. Conventions Used in this Document . . . . . . . . . . . . . 3 57 2. Fundamental Requirement . . . . . . . . . . . . . . . . . . 3 58 3. Additional Requirements, Goals, Etc: . . . . . . . . . . . . 4 59 4. "IMAP Push" Versus "IMAP Pull" . . . . . . . . . . . . . . 4 60 4.1. "IMAP Push" . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . 4 62 4.1.2. "IMAP Push" Using an External Agent . . . . . . . . 4 63 4.1.3. "IMAP Push" Using APPEND . . . . . . . . . . . . . 5 64 4.1.4. "IMAP Push" Using Proxy Model . . . . . . . . . . . 6 65 4.1.5. "IMAP Push" Using COMPOSE . . . . . . . . . . . . . 7 66 4.1.6. Unresolved Issues . . . . . . . . . . . . . . . . . 7 67 4.1.7. Security Considerations . . . . . . . . . . . . . . 7 68 4.1.8. Advantages . . . . . . . . . . . . . . . . . . . . . 8 69 4.1.9. Disadvantages . . . . . . . . . . . . . . . . . . . 8 70 4.2. "IMAP Pull" . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . 8 72 4.2.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.3. IMAP Access Authorization . . . . . . . . . . . . . 10 74 4.2.4. Security Considerations . . . . . . . . . . . . . . 11 75 4.2.5. Advantages . . . . . . . . . . . . . . . . . . . . 11 76 4.2.6. Disadvantages . . . . . . . . . . . . . . . . . . . 12 77 5. Security Considerations . . . . . . . . . . . . . . . . . . 12 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 81 9. Informative References . . . . . . . . . . . . . . . . . . 13 82 10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property Statement . . . . . . . . . . . . . . . 13 84 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 86 1. Conventions Used in this Document 88 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 89 NOT", and "MAY" in this document are to be interpreted as described 90 in "Key words for use in RFCs to Indicate Requirement Levels" 91 [KEYWORDS]. 93 In protocol examples, "C:" designates lines sent by the client, 94 while "S:" show lines sent by the server. In such examples, line 95 breaks are for editorial clarity only. 97 Gellens [Page 3] Expires April 2004 98 2. Fundamental Requirement 100 The fundamental requirement is to allow [IMAP] clients (especially 101 those on low-bandwidth or high-latency links) to submit messages 102 containing all or part of received messages without having to slosh 103 all the bits both ways (that is, without needing to download the 104 content of received messages or parts thereof just to be able to 105 upload it within a submitted message). 107 3. Additional Requirements, Goals, Etc: 109 Being able to store the sent message on the IMAP server is a goal. 111 4. "IMAP Push" Versus "IMAP Pull" 113 Two main approaches have been proposed. We can call these "IMAP 114 push" and "IMAP pull", since in one case the content is "pushed" 115 from the IMAP server to the [message submission] server, while in 116 the other case the content is "pulled" from the IMAP server by the 117 submit server. 119 4.1. "IMAP Push" 121 4.1.1. Overview 123 In the "IMAP push" model, the client uses IMAP to submit new 124 messages. When the new message contains (or consists of) all or 125 part of another message, the IMAP server copies the data into the 126 new message. It is the IMAP server that performs the initial 127 message submission. 129 4.1.2. "IMAP Push" Using an External Agent 131 In this approach, the client creates a message, APPENDs it to a 132 mailbox, and when desired adds a "queued" flag and a [message 133 submission] envelope using [annotate]. An external agent notices 134 the "queued" annotation and submits the message. 136 Gellens [Page 4] Expires April 2004 137 Because the actual submission is done by an external agent, no 138 changes to IMAP are needed apart from [annotations] (and 139 specification of the "queued" flag name). 141 4.1.3. "IMAP Push" Using APPEND 143 In the APPEND variant of "IMAP push", the client creates a skeleton 144 for a message it desires to submit. This can include references to 145 previously-received IMAP messages or portions thereof. All other 146 aspects of the message (such as headers, new content and in-line 147 quoted text) appear in the skeleton as they are to appear in the 148 message that is actually sent. The client APPENDs this message in a 149 mailbox on the IMAP server, marking it as a draft or skeleton in 150 some manner (perhaps a flag or using [annotate]). 152 When desired, the client instructs the IMAP server to submit the 153 message. At or subsequent to this point, the IMAP server connects 154 to the submit server, sends the appropriate commands, and then 155 (because it is indicated as a skeleton) sends the message skeleton 156 one body part at a time. If it encounters a part which has any 157 content-type other than message/external-body, it sends it 158 (including its headers) as-is. If the IMAP server finds a body part 159 with a content-type of message/external-body with an access-type of 160 URL which points to a message body on the IMAP server, it sends the 161 encapsulated headers of the message/external-body (not including 162 those headers specific to the content-type) followed by the contents 163 of the IMAP message body indicated by the external-body (which may 164 be part of an IMAP message). 166 The IMAP server does not need to examine the contents of the body 167 parts it is retrieving from elsewhere in the IMAP store; it fetches 168 them normally, redirecting the output to the submit server rather 169 than to the requesting client. The IMAP server does not recurse 170 through the referenced body parts looking for more external-body 171 parts. 173 The client MUST set an appropriate content-transfer-encoding for 174 each embedded part. 176 This method requires the IMAP server to maintain a mail queue, have 177 the ability to add and delete messages in this queue, monitor for 178 failures, etc. In general mail queues are rather complex, although 179 in this case less so than for a full SMTP server. However, the 180 operations for a single mail queue are essentially the same as for a 181 bunch of queues. 183 Gellens [Page 5] Expires April 2004 184 The IMAP server would also need the ability to generate proper DSNs. 186 Note that one likely implementation strategy may be to bolt sendmail 187 onto an IMAP server. 189 4.1.4. "IMAP Push" Using Proxy Model 191 In a proxy model, the IMAP server opens a connection to the submit 192 server in real-time and assembles the data as it sends the message. 193 It does not return OK to the client until it gets the 250 response 194 from the submit server. The IMAP submission command may thus take 195 the 20 minutes SMTP permits for the MAIL FROM, RCPT TO, and DATA 196 commands plus the data itself. Of course, the new IMAP command 197 could impose a shorter timeout. 199 Client can close the connection before it gets an OK, in which case 200 the command continues. The client would then need to examine the 201 message in the mailbox to learn if the submission failed, or look 202 for DSNs in the mailbox. 204 The IMAP server can mark the message as to success or failure, and 205 if failure include specific error text from the submit server, 206 perhaps in an [annotation]. 208 Another IMAP command could be added to get the EHLO response from 209 the submit server. It would be possible to require support for a 210 base set of extensions. The IMAP client can issue this new command 211 if it needs to use an extension not required to be supported; it may 212 also issue this command on occasion (once per session, per day, per 213 week) to cache the supported extensions. 215 A new IMAP command would be defined to submit mail. The desired 216 SMTP envelope can be sent as a literal or added using [annotate]. 217 The message contents can be sent as a literal or as a reference. 218 The name of an IMAP folder into which the message will be deposited 219 could be permitted. A flag could be included to fail the entire 220 message if any recipients fail. IMAP sends as unsolicited response 221 each response code. 223 Proxy authentication can be solved by having the IMAP server 224 authenticate to the submit server as an administrative user (perhaps 225 with TLS client certificates), or if the client permits, by the IMAP 226 server sending the client's credentials to the submit server. The 227 submit server can be required to support SASL authorization IDs as 228 well as MAIL FROM ... AUTH=... Support for an authorization ID 229 allows the IMAP server to send messages from itself (administrative 230 messages) and to send messages on behalf of a user, and for these 231 cases to be distinguished. 233 Gellens [Page 6] Expires April 2004 234 Can use SASL external if the submit server trusts the IMAP server. 236 4.1.5. "IMAP Push" Using COMPOSE 238 In the COMPOSE variant of "IMAP push", the client uses a new COMPOSE 239 command. This IMAP command would be similar to APPEND (with the 240 mailbox in which to append, an optional flag list and optional 241 date/time string), except that instead of a message literal, it 242 would take as parameters any number of literals and "message part 243 identifiers". All of the literals and the message parts would be 244 appended together in the destination mailbox as one message. The 245 client would be responsible for providing the appropriate MIME 246 boundaries in the literals. 248 4.1.6. Unresolved Issues 250 Deletion of referenced data before expansion is a concern, 251 especially with the APPEND variant, although one that could be 252 ignored, as it would be a result of client action (a timing hole 253 exists with any solution, although it is larger or smaller in some 254 models). 256 A number of variances are possible. These include how the envelope 257 information (including return-path, recipients and extensions) is 258 indicated; the precise mechanism for references to IMAP messages or 259 portions, including how such mechanism interacts with [mailbox 260 referrals], and if the mechanism requires that all referenced data 261 exist on the same IMAP server doing the submission; if the final 262 submission completes synchronously or synchronously or if this is an 263 option; how errors during the submission process are to be handled. 265 One approach to the envelope issue would be for the client to store 266 the complete desired submission envelope in a message annotation per 267 the [annotate] extension. Another is to simply include this in the 268 IMAP command which submits the message. In either case, the desired 269 envelope can be sent by the client as a literal, or can be 270 integrated into IMAP. The former has the advantage of tying IMAP 271 submission directly to [message submission], thus guaranteeing that 272 all current and future [message submission] extensions are valid 273 within the IMAP submit mechanism. This avoids potentially creating 274 two parallel but separate Internet mail submission mechanisms, one 275 for IMAP clients and one for all other clients (including POP and 276 submit-only). The latter has the advantage of providing a clear way 277 to inform the client of the submission extensions supported by the 278 server. 280 Gellens [Page 7] Expires April 2004 281 4.1.7. Security Considerations 283 This approach requires that the submit server trust the IMAP server 284 to submit messages on behalf of the end user. In addition, since 285 new functionality is being added to IMAP, including expansion of 286 referenced data, implementation errors have the potential to create 287 vulnerabilities that could compromise the IMAP server, giving access 288 to all of the user's IMAP data, all IMAP data for all users, or root 289 access to the system. 291 4.1.8. Advantages 293 * Avoids requiring Submit server to understand MIME. 294 * The IMAP server already stores the messages which are referenced, 295 and hence can get at them conveniently. 296 * The IMAP server can easily store the sent message in the user's 297 Outbox or Sent Mail folder, where they are immediately available 298 (there is the potential for delay in the "IMAP pull" model). 299 * Messages can remain in a "sendable but not queued" state, where 300 they are complete but not eligible to be submitted, for any desired 301 period of time, where they can be edited or deleted. 303 4.1.9. Disadvantages 305 * Only external-body references to messages on the IMAP server can 306 be expanded. 307 * Adds message submission to IMAP, with the potential for two 308 separate Internet mail submission mechanisms 309 * Adds complexity to IMAP for a limited case 310 * Administrative complexity in setting up the trust relationship 311 between the servers 312 * Knowing what happened to a message that was not fully successful 313 or which the client doesn't know (connection closed) requires a sent 314 mail folder with annotated message 315 * The APPEND variant has a number of disadvantages discussed in its 316 section. 318 4.2. "IMAP Pull" 320 4.2.1. Overview 322 Gellens [Page 8] Expires April 2004 323 In the "IMAP pull" model, the client connects to a [message 324 submission] server and submits a message. This message may contain 325 references which the client requests the server to expand. During 326 or subsequent to the session, the server dereferences these URLs and 327 creates the complete message. This allows arbitrary content to be 328 incorporated into messages without first downloading by the client. 330 4.2.2. Mechanisms 332 One possible solution for storing copies of sent mail in the IMAP 333 server would be to standardize an IMAP mailbox annotation using 334 [annotate] which contains an email address that posts directly to 335 the mailbox. (This would be a desirable feature for shared mailboxes 336 as well as message submission.) Another approach would be for the 337 client to use the proposed COMPOSE command (as described in section 338 4.1.5 above) to create the final message in the desired IMAP 339 mailbox, then instruct the submit server to send that message. 341 Several techniques are possible for the client to indicate to the 342 submit server that the message contains references to be expanded. 343 One approach, as described in [BURL], creates a new [message 344 submission] verb that includes a URL reference which the server 345 expands. This new BURL command directs the server to fetch the data 346 object to which the URL refers, perform any necessary content 347 transfer encoding conversions on that object and include it in the 348 message. 350 BURL can be combined with the CHUNKING extension to SMTP added by 351 [binary SMTP]. The CHUNKING extension allows submission of a series 352 of byte-counted message fragments using the BDAT command. One or 353 more BURL commands could be interleaved with the BDAT commands. 354 This allows the message to be composed without any sort of hokey 355 post-processing. 357 For example, a message could be submitted as follows: 359 BDAT .... headers and first part 360 BURL 8bit retry forwarded 8bit content from IMAP 361 BDAT .... MIME delimiters or whatever 362 BURL base64 get IMAP content; base64 encode 363 BDAT .... final data 365 BURL can include a flag indicating how errors are to be handled; the 366 example above uses 'retry', meaning that the submit server should 367 retry instead of failing the command (and any subsequent BURL or 368 BDAT commands). 370 Gellens [Page 9] Expires April 2004 371 Potentially, this could be pipeline-able into one round-trip. 373 The BURL command can also include a flag, similar to that used with 374 BDAT, to indicate that this is the last such command. This would 375 allow a client to compose a message using BURL to fetch the end of 376 the message, or to submit a message which consists of one other 377 message, using a single BURL command and no BDAT commands. For 378 example: 380 BURL 8bit last failnow 382 The BURL extension should advertise what types of URLs it supports 383 (the initial focus should of course be for IMAP; additional URL 384 types could be considered later if they are desirable) and which 385 hosts trust it. For example: 387 250-BURL imap://trusted-host.example.com/ 389 4.2.3. IMAP Access Authorization 391 The significant issue with "IMAP pull" is how to give the [message 392 submission] server access to the referenced IMAP data. In many 393 cases the servers will have a trust relationship, but it is 394 desirable for the solution to not require this. 396 One approach is to include authorization within the reference. The 397 IMAP URL used to indicate which messages or message parts are to be 398 included in the submitted message can include authorization 399 credentials. This is separate from any authentication mechanism or 400 credentials. 402 The "pawn token" mechanism proposed in [URLAUTH] provides 403 authorization for the posseser of the token to access one specific 404 piece of data. The submit server could use the SASL ANONYMOUS 405 mechanism (or equivalent), or authenticate as a role (that is, as a 406 submit server) and then use one or more tokens to authorize access 407 to one or more messages or message parts. 409 The limited-use "pawn token" URL can be generated by the client as 410 described in [URLAUTH]. The URL can expire at a specific time and 411 date, and/or can be limited to use by a specified user or role (such 412 as the submit server). 414 Gellens [Page 10] Expires April 2004 415 As described in [URLAUTH], the submit server would resolve the 416 URL(s) by the new URLFETCH command. This command returns a literal 417 of the relevant message/body part(s) if the authorization token is 418 valid. 420 4.2.4. Security Considerations 422 This method requires either that the IMAP server trusts the submit 423 server or that the "pawn ticket" mechanism be used which authorizes 424 access to specific limited content (this URL could expire after some 425 amount of time and/or be usable only by the submit server). 427 If the IMAP server trusts the submit server, the IMAP server can 428 include in its CAPABILITIES response a list of such trusted 429 submission servers. Or, the submit server can indicate which IMAP 430 servers trust it. 432 Note that the primary target for forward-without-download is email 433 on cell phones, where the carrier will operate both the IMAP and 434 submit servers and there is thus a pre-existing trust relationship 435 between these servers. 437 Also note that plain text passwords (with or without TLS) are in 438 widespread use (indeed are dominant) for authentication. 439 Authenticating to the submit server may thus disclose authentication 440 credentials sufficient to grant the submit server access to the 441 user's IMAP account. 443 The URI-based token mechanism poses a risk for channels which are 444 not secure (secure channels are not required by [message submission] 445 or [SMTP]). Given a compromise there, an attacker could anticipate 446 the download of a body part by dereferencing the URI before the 447 submit server (by taking a second or third BURL-reference, for 448 example, to win the race condition). This compromises the body 449 part. However, since this vulnerability requires a clear-text 450 channel, this is no worse a problem that submitting a new message 451 over an unprotected channel in the first place. That is, if the 452 channel between the client and the submit server is not protected, 453 then all messages submitted over that channel are vulnerable to 454 eavesdropping anyway. 456 4.2.5. Advantages 458 Gellens [Page 11] Expires April 2004 459 * Keeps message submission within [message submission]. 460 * Avoids adding significant new functionality to [IMAP] 461 * Can potentially be expanded to include other types or URIs and 462 additional associated services 464 In conjunction with the COMPOSE mechanism described in 4.1.5 above: 466 * The IMAP server can easily store the sent message in the user's 467 Outbox or Sent Mail folder, where they are immediately available 468 (there is the potential for delay in the "IMAP pull" model). 469 * Messages can remain in a "sendable but not queued" state, where 470 they are complete but not eligible to be submitted, for any desired 471 period of time, where they can be edited or deleted. 473 4.2.6. Disadvantages 475 * Adds significant new functionality to [message submission] servers 476 * Requires submit server to have access to (at least specific pieces 477 of) IMAP data 479 5. Security Considerations 481 Security considerations are currently discussed within each of the 482 two main alternatives above. 484 6. IANA Considerations 486 None identified yet. Stay tuned. 488 7. Acknowledgements 490 The editor is grateful for and would like to acknowledge the 491 significant contributions made to this document by several members 492 of the lemonade group, including Mark Crispin, Cyrus Daboo, Larry 493 Greenfield, Ted Hardie, Chris Newman, and Pete Resnick. 495 8. Normative References 497 [binary SMTP] "SMTP Service Extensions for Transmission of Large and 498 Binary MIME Messages", G. Vaudreuil, December 2000, RFC 3030. 500 Gellens [Page 12] Expires April 2004 502 [BURL] Newman, C., "Message Composition", 503 draft-newman-lemonade-compose-xx (work in progress). 505 [IMAP] "INTERNET MESSAGE ACCESS PROTOCOL -- VERSION 4rev1", M. 506 Crispin, March 2003, RFC 3501. 508 [message submission] "Message Submission", R. Gellens, J. Klensin, 509 December 1998, RFC 2476. 511 [URL access-type] "Definition of the URL MIME External-Body 512 Access-Type", N. Freed, K. Moore, A. Cargille, October 1996, RFC 513 2017. 515 [URLAUTH] Crispin, Newman, "Internet Message Access Protocol (IMAP) 516 - URLAUTH Extension", draft-crispin-imap-urlauth-xx (work in 517 progress). 519 9. Informative References 521 [annotate] Gellens, Daboo, "IMAP ANNOTATE Extension" (work in 522 progress). 524 [mailbox referrals] "IMAP4 Mailbox Referrals", M. Gahrns, September 525 1997, RFC 2193. 527 [SMTP] "Simple Mail Transfer Protocol", J. Klensin, Ed., April 2001, 528 RFC 2821. 530 10. Editor's Address 532 Randall Gellens 533 QUALCOMM Incorporated 534 5775 Morehouse Drive 535 San Diego, CA 92121 536 USA 537 randy@qualcomm.com 539 Intellectual Property Statement 541 The IETF takes no position regarding the validity or scope of any 542 intellectual property or other rights that might be claimed to 543 pertain to the implementation or use of the technology described in 544 this document or the extent to which any license under such rights 545 might or might not be available; neither does it represent that it 546 has made any effort to identify any such rights. Information on the 547 IETF's procedures with respect to rights in standards-track and 549 Gellens [Page 13] Expires April 2004 550 standards-related documentation can be found in BCP-11. Copies of 551 claims of rights made available for publication and any assurances 552 of licenses to be made available, or the result of an attempt made 553 to obtain a general license or permission for the use of such 554 proprietary rights by implementors or users of this specification 555 can be obtained from the IETF Secretariat. 557 The IETF invites any interested party to bring to its attention any 558 copyrights, patents or patent applications, or other proprietary 559 rights which may cover technology that may be required to practice 560 this standard. Please address the information to the IETF Executive 561 Director. 563 Full Copyright Statement 565 Copyright (C) The Internet Society 2003. All Rights Reserved. 567 This document and translations of it may be copied and furnished to 568 others, and derivative works that comment on or otherwise explain it 569 or assist in its implementation may be prepared, copied, published 570 and distributed, in whole or in part, without restriction of any 571 kind, provided that the above copyright notice and this paragraph 572 are included on all such copies and derivative works. However, this 573 document itself may not be modified in any way, such as by removing 574 the copyright notice or references to the Internet Society or other 575 Internet organizations, except as needed for the purpose of 576 developing Internet standards in which case the procedures for 577 copyrights defined in the Internet Standards process must be 578 followed, or as required to translate it into languages other than 579 English. 581 The limited permissions granted above are perpetual and will not be 582 revoked by the Internet Society or its successors or assigns. 584 This document and the information contained herein is provided on an 585 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 586 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 587 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 588 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 589 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 Gellens [Page 14] Expires April 2004