idnits 2.17.1 draft-melnikov-imap-search-res-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 558. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to directly say this. It does mention RFC3501 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 26, 2008) is 5934 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: 'BADCHARSET UTF-8' is mentioned on line 243, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- No information found for draft-ietf-imapext-sort-XX - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Document: draft-melnikov-imap-search-res-07.txt A. Melnikov 3 Intended status: Proposed Standard Isode Ltd. 4 Updates: RFC 3501 (if approved) January 26, 2008 5 Expires: July 2008 6 Internet-Draft 8 IMAP extension for referencing the last SEARCH result 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by 23 other documents at any time. It is inappropriate to use 24 Internet-Drafts as reference material or to cite them other 25 than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent to 36 the IMAPEXT Mailing list . Distribution of this 37 draft is unlimited. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 Many IMAP clients use the result of a SEARCH command as the input to 46 perform another operation, for example fetching the found messages, 47 deleting them or copying them to another mailbox. 49 This can be achieved using standard IMAP operations described in RFC 50 3501, however this would be suboptimal: the server will send the list 51 of found messages to the client, after that the client will have to 52 parse the list, reformat it and send it back to the server. The 53 client can't pipeline the SEARCH command with the subsequent command, 54 and, as a result, the server might not be able to perform some 55 optimizations. 57 This document proposes an IMAP extension that allows a client to tell 58 a server to use the result of a SEARCH (or UID SEARCH) command as an 59 input to any subsequent command. 61 1. Conventions Used in this Document 63 In examples, "C:" indicates lines sent by a client that is connected 64 to a server. "S:" indicates lines sent by the server to the client. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [KEYWORDS]. 70 Explanatory comments in examples are starting with // and are not 71 part of the protocol. 73 <> 75 2. Introduction and Overview 77 Many IMAP clients use the result of a SEARCH command as the input to 78 perform another operation, for example fetching the found messages, 79 deleting them or copying them to another mailbox. 81 This document proposes an IMAP extension that allows a client to tell 82 a server to use the result of a SEARCH (or UID SEARCH) command as an 83 input to any subsequent command. 85 The SEARCH result reference extension defines a new SEARCH result 86 option [IMAPABNF] "SAVE" that tells the server to remember the result 87 of the SEARCH or UID SEARCH command (as well as any command based on 88 SEARCH, e.g. SORT and THREAD [SORT]) and store it in an internal 89 variable that we will reference as the "search result variable". The 90 client can use the "$" marker to reference the content of this 91 internal variable. The "$" marker can be used instead of message 92 sequence or UID sequence in order to indicate that the server should 93 substitute it with the list of messages from the search result 94 variable. Thus the client can use the result of the latest 95 remembered SEARCH command as a parameter to another command. The 96 search result marker has several advantages: 97 * it avoids wasted bandwidth and associated delay; 98 * it allows the client to pipeline a SEARCH [IMAP4] command with a 99 subsequent FETCH/STORE/COPY/SEARCH [IMAP4] or UID EXPUNGE 100 [UIDPLUS] command; 101 * the client doesn't need to spend time reformatting the 102 result of a SEARCH command into a message set used in 103 the subsequent command; 104 * it allows the server to perform optimizations. For example if 105 the server can execute several pipelined commands in parallel 106 (or out of order), presence of the search result marker can 107 allow the server to decide which commands may or may not be 108 executed out of order. 110 In absence of any other SEARCH result option, the SAVE result option 111 also suppresses any SEARCH response that would have been otherwise 112 returned by the SEARCH command. 114 2.1. Normative description of the SEARCHRES extension 116 The SEARCH result reference extension described in this document is 117 present in any IMAP4 server implementation which returns "SEARCHRES" 118 as one of the supported capabilities in the CAPABILITY command 119 response. Any such server MUST also implement the [ESEARCH] 120 extension. 122 Upon successful completion of a SELECT or an EXAMINE command (after 123 the tagged OK response), the current search result variable is reset 124 to the empty sequence. 126 A successful SEARCH command with the SAVE result option sets the 127 value of the search result variable to the list of messages found in 128 the SEARCH command. For example, if no messages were found, the 129 search result variable will contain the empty list. 131 Any of the following SEARCH command MUST NOT change the search result 132 variable: 134 o A SEARCH command that caused the server to return the BAD tagged 135 response, 136 o a SEARCH command with no SAVE result option that caused the server 137 to return NO tagged response, 138 o a successful SEARCH command with no SAVE result option. 140 A SEARCH command with the SAVE result option that caused the server 141 to return the NO tagged response sets the value of the search result 142 variable to the empty sequence. 144 When a message listed in the search result variable is EXPUNGEd, it 145 is automatically removed from the list. Implementors are reminded 146 that if the server stores the list as a list of message numbers, it 147 MUST automatically adjust them when notifying the client about 148 expunged messages, as described in Section 7.4.1 of [IMAP4]. 150 If the server decides to send a new UIDVALIDITY value while mailbox 151 is opened, this causes resetting of the search variable to the empty 152 list. 154 Note that even if the "$" marker contains the empty list of messages, 155 it must be treated by all commands accepting message sets as 156 parameters, as a valid, but non matching list of messages. For 157 example, the "FETCH $" command would return tagged OK response and no 158 FETCH responses. See also the Example # 5 below. 160 Note that even if the "$" marker contains the empty list of messages, 161 it must be treated as a valid but non matching list of messages, by 162 all commands that accept message sets as parameters. 164 Implementation note: server implementers should note that "$" can 165 reference IMAP message sequence or UID sequence, depending on context 166 where it is used. For example, the "$" marker can be set as a result 167 of a SEARCH (SAVE) command and used as a parameter to a UID FETCH 168 command (which accept UID sequence, not message sequence), or the "$" 169 marker can be set as a result of a UID SEARCH (SAVE) command and used 170 as a parameter to a FETCH command (which accept message sequence, not 171 UID sequence). 173 2.2. Examples 175 1) The following example demonstrates how the client can use the 176 result of a SEARCH command to FETCH headers of interesting 177 messages: 179 Example 1: 180 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994 181 NOT FROM "Smith" 182 S: A282 OK SEARCH completed, result saved 183 C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER) 184 S: * 2 FETCH (UID 14 ... 185 S: * 84 FETCH (UID 100 ... 186 S: * 882 FETCH (UID 1115 ... 187 S: A283 OK completed 189 The client can also pipeline the two commands: 191 Example 2: 192 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994 193 NOT FROM "Smith" 194 C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER) 195 S: A282 OK SEARCH completed 196 S: * 2 FETCH (UID 14 ... 197 S: * 84 FETCH (UID 100 ... 198 S: * 882 FETCH (UID 1115 ... 199 S: A283 OK completed 201 2) The following example demonstrates that the result of one SEARCH 202 command can be used as input to another SEARCH command: 204 Example 3: 205 C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004 206 NOT FROM "Smith" 207 S: A300 OK SEARCH completed 208 C: A301 UID SEARCH UID $ SMALLER 4096 209 S: * SEARCH 17 900 901 210 S: A301 OK completed 212 Note that the second command in Example 3 can be replaced with: 213 C: A301 UID SEARCH $ SMALLER 4096 214 and the result of the command would be the same. 216 3) The following example shows that the "$" 217 marker can be combined with other message numbers using the OR 218 SEARCH criterion. 220 Example 4: 221 C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 222 NOT FROM "Smith" 223 S: P282 OK SEARCH completed 224 C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8} 225 C: YYYYYYYY 226 S: * SEARCH 882 1102 3003 3005 3006 227 S: P283 OK completed 229 Note: Since this document format is restricted to 7-bit ASCII 230 text, it is not possible to show actual UTF-8 data. The 231 "YYYYYYYY" is a placeholder for what would be 8 octets of 8-bit 232 data in an actual transaction. 234 4) The following example demonstrates that a failed SEARCH sets 235 the search result variable to the empty list. 237 Example 5: 238 C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 239 NOT FROM "Smith" 240 S: B282 OK SEARCH completed 241 C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4} 242 C: XXXX 243 S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported 244 //After this command the saved result variable contains 245 //no messages. A client that wants to reissue the B283 246 //SEARCH command with another CHARSET would have to reissue 247 //the B282 command as well. One possible workaround for 248 //this is to include the desired CHARSET parameter 249 //in the earliest SEARCH RETURN (SAVE) command in a 250 //sequence of related SEARCH commands. 251 //A better approach might be to always use CHARSET UTF-8 252 //instead. 254 Note: Since this document format is restricted to 7-bit ASCII 255 text, it is not possible to show actual KOI8-R data. The "XXXX" 256 is a placeholder for what would be 4 octets of 8-bit data in an 257 actual transaction. 259 5) The following example demonstrates that it is not an error to 260 use the "$" marker when it contains no messages. 262 Example 6: 263 C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 264 NOT FROM "Eric" 265 C: E283 COPY $ "Other Messages" 266 //The "$" contains no messages 267 S: E282 OK SEARCH completed 268 S: E283 OK COPY completed, nothing copied 270 2.3. Multiple Commands in Progress 272 Use of a SEARCH RETURN (SAVE) command followed by a command 273 using the "$" marker creates direct dependency between the two 274 commands. As directed by Section 5.5 of [IMAP4], a server MUST 275 execute the two commands in the order they were received. (A 276 server capable of out-of-order execution can in some cases 277 execute the two commands in parallel, for example if a SEARCH 278 RETURN (SAVE) is followed by SEARCH $, the search criteria from 279 the first command can be directly substituted into the second 280 command.) 282 A client supporting this extension MAY pipeline a SEARCH RETURN 283 (SAVE) command with one or more command using the "$" marker, as 284 long as this doesn't create an ambiguity described in Section 285 5.5 of [IMAP4]. 287 Example 7: 288 C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk 289 C: F283 COPY $ "Junk" 290 C: F284 STORE $ +FLAGS.Silent (\Deleted) 291 S: F282 OK SEARCH completed 292 S: F283 OK COPY completed 293 S: F284 OK STORE completed 295 Example 8: 296 C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk 297 C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006 298 FROM "Eric" 299 //The server can execute the two SEARCH commands 300 //in any order, as they don't have any dependency. 301 //Note that the second command is making use of 302 //the [ESEARCH] extension. 303 S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103 304 S: G283 OK SEARCH completed 305 S: G282 OK SEARCH completed 307 The following example demonstrates that the result of the second 308 SEARCH always overrides the result of the first. 310 Example 9: 311 C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk 312 C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 313 FROM "Eric" 314 S: H283 OK SEARCH completed 315 S: H282 OK SEARCH completed 317 2.4. Interaction with ESEARCH extension 319 Servers that implement the extension defined in this document 320 are required to implement [ESEARCH] and to conform to additional 321 requirements listed in this section. 323 The SAVE result option doesn't change whether the server would 324 return items corresponding to MIN, MAX, ALL or COUNT [ESEARCH] 325 result options. 327 When the SAVE result option is combined with the MIN or MAX 328 [ESEARCH] result option, and none of the other ESEARCH result 329 options are present, the corresponding MIN/MAX is returned (if 330 the search result is not empty) but the "$" marker would contain 331 a single message as returned in the MIN/MAX return item. 333 If the SAVE result option is combined with both MIN and MAX 334 result options, and none of the other ESEARCH result options are 335 present, the "$" marker would contain one or two messages as 336 returned in the MIN/MAX return items. 338 If the SAVE result option is combined with ALL and/or COUNT 339 result option, the "$" marker would always contain all messages 340 found by the SEARCH or UID SEARCH command. (Note that the last 341 rule might affect ESEARCH implementations that optimize how 342 COUNT result is constructed.) 344 The following table summarizes the additional requirement on 345 ESEARCH server implementations described in this section. 347 +----------------+-------------------+ 348 | Combination of | "$" marker value | 349 | Result option | | 350 +----------------+-------------------+ 351 | SAVE MIN | MIN | 352 +----------------+-------------------+ 353 | SAVE MAX | MAX | 354 +----------------+-------------------+ 355 | SAVE MIN MAX | MIN & MAX | 356 +----------------+-------------------+ 357 | SAVE * [m] | all found messages| 358 +----------------+-------------------+ 360 where '*' means "ALL" and/or "COUNT" 361 '[m]' means optional "MIN" and/or "MAX" 363 The following example demonstrates behavioural difference 364 for different combinations of ESEARCH result options. 365 Explanatory comments are starting with // and are not 366 part of the protocol: 368 Example 10: 369 C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006 370 NOT FROM "Smith" 371 S: * ESEARCH (TAG "C283") ALL 2,10:15,21 372 //$ value hasn't changed 373 S: C282 OK SEARCH completed 375 C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006 376 NOT FROM "Smith" 377 S: * ESEARCH (TAG "C283") ALL 2,10:15,21 378 //$ value is 2,10:15,21 379 S: C283 OK SEARCH completed 380 C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006 381 NOT FROM "Smith" 382 S: * ESEARCH (TAG "C284") MIN 2 383 //$ value is 2 384 S: C284 OK SEARCH completed 386 C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE 387 12-Feb-2006 NOT FROM "Smith" 388 S: * ESEARCH (TAG "C285") MIN 2 MAX 21 389 //$ value is 2,21 390 S: C285 OK SEARCH completed 392 C: C286 SEARCH RETURN (MAX SAVE MIN COUNT) 393 SINCE 12-Feb-2006 NOT FROM "Smith" 394 S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8 395 //$ value is 2,10:15,21 396 S: C286 OK SEARCH completed 398 C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE 399 12-Feb-2006 NOT FROM "Smith" 400 S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21 401 //$ value is 2,10:15,21 402 S: C286 OK SEARCH completed 404 2.5. Refusing to save search results 406 In some cases, the server MAY refuse to save a SEARCH (SAVE) 407 result, for example if an internal limit on the number of saved 408 results is reached. 410 In this case, the server MUST return a tagged NO response 411 containing the NOTSAVED response code, and set the search result 412 variable to the empty sequence, as described in Section 2.1. 414 3. Formal Syntax 416 The following syntax specification uses the Augmented Backus-Naur 417 Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced 418 but not defined below are as defined in [IMAP4] or [IMAPABNF]. 420 Except as noted otherwise, all alphabetic characters are case- 421 insensitive. The use of upper or lower case characters to define 422 token strings is for editorial clarity only. Implementations MUST 423 accept these strings in a case-insensitive fashion. 425 capability =/ "SEARCHRES" 426 ;; capability is defined in [IMAP4] 428 sequence-set =/ seq-last-command 429 ;; extends sequence-set to allow for 430 ;; "result of the last command" indicator. 432 seq-last-command = "$" 434 search-return-opt = "SAVE" 435 ;; conforms to generic search-return-opt 436 ;; syntax defined in [IMAPABNF] 438 resp-text-code =/ "NOTSAVED" 439 ;; from [IMAP4] 441 4. Security Considerations 443 This extension requires the server to keep additional state, that may 444 be used to simplify Deny of Service attacks. In order to minimize 445 damage from such attacks server implementations MAY limit the number 446 of saved searches they allow across all connections at any given time 447 and return the tagged NO response containing the NOTSAVED response 448 code (see Section 2.5) to a SEARCH RETURN (SAVE) command when this 449 limit is exceeded. 451 Apart from that it is believed that this extension doesn't raise any 452 additional security concerns not already discussed in [IMAP4]. 454 5. IANA Considerations 456 This document defines the "SEARCHRES" IMAP capability. IANA is 457 requested to add it to the IMAP4 Capabilities Registry, which is 458 currently located at: 460 http://www.iana.org/assignments/imap4-capabilities 462 6. Acknowledgments 464 The author would like to thank Mark Crispin, Cyrus Daboo and Curtis 465 King for reminding that this document has to be written, as well as 466 for comments and corrections received. 468 The author would also like to thank Dave Cridland, Mark Crispin, 469 Chris Newman, Dan Karp and Spencer Dawkins for comments and 470 corrections received. 472 Valuable comments, both in agreement and in dissent, were received 473 from Arnt Gulbrandsen. 475 7. References 477 7.1. Normative references 479 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 483 Specifications: ABNF", RFC 4234, October 2005. 485 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 486 4rev1", RFC 3501, University of Washington, March 2003. 488 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to IMAP4 489 ABNF", RFC 4466, April 2006. 491 [ESEARCH] Melnikov, A., and D. Cridland, "IMAP4 Extension to SEARCH 492 Command for Controlling What Kind of Information Is Returned", RFC 493 4731, November 2006. 495 7.2. Informative references 497 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 498 UIDPLUS extension", RFC 4315, December 2005. 500 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 501 PROTOCOL - SORT AND THREAD EXTENSIONS", work in progress, draft-ietf- 502 imapext-sort-XX.txt 504 8. Author's Addresses 506 Alexey Melnikov 507 Isode Ltd. 508 5 Castle Business Village, 509 36 Station Road, 510 Hampton, Middlesex, 511 TW12 2BX, United Kingdom 513 Email: Alexey.Melnikov@isode.com 515 9. Full Copyright Statement 517 Copyright (C) The IETF Trust (2008). 519 This document is subject to the rights, licenses and restrictions 520 contained in BCP 78, and except as set forth therein, the authors 521 retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 526 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 527 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 528 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Acknowledgement 533 Funding for the RFC Editor function is provided by the IETF 534 Administrative Support Activity (IASA). 536 10. Intellectual Property 538 The IETF takes no position regarding the validity or scope of any 539 Intellectual Property Rights or other rights that might be claimed to 540 pertain to the implementation or use of the technology described in 541 this document or the extent to which any license under such rights 542 might or might not be available; nor does it represent that it has 543 made any independent effort to identify any such rights. Information 544 on the procedures with respect to rights in RFC documents can be 545 found in BCP 78 and BCP 79. 547 Copies of IPR disclosures made to the IETF Secretariat and any 548 assurances of licenses to be made available, or the result of an 549 attempt made to obtain a general license or permission for the use of 550 such proprietary rights by implementers or users of this 551 specification can be obtained from the IETF on-line IPR repository at 552 http://www.ietf.org/ipr. 554 The IETF invites any interested party to bring to its attention any 555 copyrights, patents or patent applications, or other proprietary 556 rights that may cover technology that may be required to implement 557 this standard. Please address the information to the IETF at 558 ietf-ipr@ietf.org.