imapext-2007

annotate docs/rfc/rfc4978.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Gulbrandsen
yuuji@0 8 Request for Comments: 4978 Oryx Mail Systems GmbH
yuuji@0 9 Category: Standards Track August 2007
yuuji@0 10
yuuji@0 11
yuuji@0 12 The IMAP COMPRESS Extension
yuuji@0 13
yuuji@0 14 Status of this Memo
yuuji@0 15
yuuji@0 16 This document specifies an Internet standards track protocol for the
yuuji@0 17 Internet community, and requests discussion and suggestions for
yuuji@0 18 improvements. Please refer to the current edition of the "Internet
yuuji@0 19 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 20 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 21
yuuji@0 22 Abstract
yuuji@0 23
yuuji@0 24 The COMPRESS extension allows an IMAP connection to be effectively
yuuji@0 25 and efficiently compressed.
yuuji@0 26
yuuji@0 27 Table of Contents
yuuji@0 28
yuuji@0 29 1. Introduction and Overview .......................................2
yuuji@0 30 2. Conventions Used in This Document ...............................2
yuuji@0 31 3. The COMPRESS Command ............................................3
yuuji@0 32 4. Compression Efficiency ..........................................4
yuuji@0 33 5. Formal Syntax ...................................................6
yuuji@0 34 6. Security Considerations .........................................6
yuuji@0 35 7. IANA Considerations .............................................6
yuuji@0 36 8. Acknowledgements ................................................7
yuuji@0 37 9. References ......................................................7
yuuji@0 38 9.1. Normative References .......................................7
yuuji@0 39 9.2. Informative References .....................................7
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Gulbrandsen Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 61
yuuji@0 62
yuuji@0 63 1. Introduction and Overview
yuuji@0 64
yuuji@0 65 A server which supports the COMPRESS extension indicates this with
yuuji@0 66 one or more capability names consisting of "COMPRESS=" followed by a
yuuji@0 67 supported compression algorithm name as described in this document.
yuuji@0 68
yuuji@0 69 The goal of COMPRESS is to reduce the bandwidth usage of IMAP.
yuuji@0 70
yuuji@0 71 Compared to PPP compression (see [RFC1962]) and modem-based
yuuji@0 72 compression (see [MNP] and [V42BIS]), COMPRESS offers much better
yuuji@0 73 compression efficiency. COMPRESS can be used together with Transport
yuuji@0 74 Security Layer (TLS) [RFC4346], Simple Authentication and Security
yuuji@0 75 layer (SASL) encryption, Virtual Private Networks (VPNs), etc.
yuuji@0 76 Compared to TLS compression [RFC3749], COMPRESS has the following
yuuji@0 77 (dis)advantages:
yuuji@0 78
yuuji@0 79 - COMPRESS can be implemented easily both by IMAP servers and
yuuji@0 80 clients.
yuuji@0 81
yuuji@0 82 - IMAP COMPRESS benefits from an intimate knowledge of the IMAP
yuuji@0 83 protocol's state machine, allowing for dynamic and aggressive
yuuji@0 84 optimization of the underlying compression algorithm's parameters.
yuuji@0 85
yuuji@0 86 - When the TLS layer implements compression, any protocol using that
yuuji@0 87 layer can transparently benefit from that compression (e.g., SMTP
yuuji@0 88 and IMAP). COMPRESS is specific to IMAP.
yuuji@0 89
yuuji@0 90 In order to increase interoperation, it is desirable to have as few
yuuji@0 91 different compression algorithms as possible, so this document
yuuji@0 92 specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is
yuuji@0 93 standard, widely available and fairly efficient, so it is the only
yuuji@0 94 algorithm defined by this document.
yuuji@0 95
yuuji@0 96 In order to increase interoperation, IMAP servers that advertise this
yuuji@0 97 extension SHOULD also advertise the TLS DEFLATE compression mechanism
yuuji@0 98 as defined in [RFC3749]. IMAP clients MAY use either COMPRESS or TLS
yuuji@0 99 compression, however, if the client and server support both, it is
yuuji@0 100 RECOMMENDED that the client choose TLS compression.
yuuji@0 101
yuuji@0 102 The extension adds one new command (COMPRESS) and no new responses.
yuuji@0 103
yuuji@0 104 2. Conventions Used in This Document
yuuji@0 105
yuuji@0 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 108 document are to be interpreted as described in [RFC2119].
yuuji@0 109
yuuji@0 110 Formal syntax is defined by [RFC4234] as modified by [RFC3501].
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Gulbrandsen Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 117
yuuji@0 118
yuuji@0 119 In the examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 120 server respectively. "[...]" denotes elision.
yuuji@0 121
yuuji@0 122 3. The COMPRESS Command
yuuji@0 123
yuuji@0 124 Arguments: Name of compression mechanism: "DEFLATE".
yuuji@0 125
yuuji@0 126 Responses: None
yuuji@0 127
yuuji@0 128 Result: OK The server will compress its responses and expects the
yuuji@0 129 client to compress its commands.
yuuji@0 130 NO Compression is already active via another layer.
yuuji@0 131 BAD Command unknown, invalid or unknown argument, or COMPRESS
yuuji@0 132 already active.
yuuji@0 133
yuuji@0 134 The COMPRESS command instructs the server to use the named
yuuji@0 135 compression mechanism ("DEFLATE" is the only one defined) for all
yuuji@0 136 commands and/or responses after COMPRESS.
yuuji@0 137
yuuji@0 138 The client MUST NOT send any further commands until it has seen the
yuuji@0 139 result of COMPRESS. If the response was OK, the client MUST compress
yuuji@0 140 starting with the first command after COMPRESS. If the server
yuuji@0 141 response was BAD or NO, the client MUST NOT turn on compression.
yuuji@0 142
yuuji@0 143 If the server responds NO because it knows that the same mechanism is
yuuji@0 144 active already (e.g., because TLS has negotiated the same mechanism),
yuuji@0 145 it MUST send COMPRESSIONACTIVE as resp-text-code (see [RFC3501],
yuuji@0 146 Section 7.1), and the resp-text SHOULD say which layer compresses.
yuuji@0 147
yuuji@0 148 If the server issues an OK response, the server MUST compress
yuuji@0 149 starting immediately after the CRLF which ends the tagged OK
yuuji@0 150 response. (Responses issued by the server before the OK response
yuuji@0 151 will, of course, still be uncompressed.) If the server issues a BAD
yuuji@0 152 or NO response, the server MUST NOT turn on compression.
yuuji@0 153
yuuji@0 154 For DEFLATE (as for many other compression mechanisms), the
yuuji@0 155 compressor can trade speed against quality. When decompressing there
yuuji@0 156 isn't much of a tradeoff. Consequently, the client and server are
yuuji@0 157 both free to pick the best reasonable rate of compression for the
yuuji@0 158 data they send.
yuuji@0 159
yuuji@0 160 When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see
yuuji@0 161 [RFC4422]) security layers, the sending order of the three extensions
yuuji@0 162 MUST be first COMPRESS, then SASL, and finally TLS. That is, before
yuuji@0 163 data is transmitted it is first compressed. Second, if a SASL
yuuji@0 164 security layer has been negotiated, the compressed data is then
yuuji@0 165 signed and/or encrypted accordingly. Third, if a TLS security layer
yuuji@0 166 has been negotiated, the data from the previous step is signed and/or
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Gulbrandsen Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 173
yuuji@0 174
yuuji@0 175 encrypted accordingly. When receiving data, the processing order
yuuji@0 176 MUST be reversed. This ensures that before sending, data is
yuuji@0 177 compressed before it is encrypted, independent of the order in which
yuuji@0 178 the client issues COMPRESS, AUTHENTICATE, and STARTTLS.
yuuji@0 179
yuuji@0 180 The following example illustrates how commands and responses are
yuuji@0 181 compressed during a simple login sequence:
yuuji@0 182
yuuji@0 183 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
yuuji@0 184 C: a starttls
yuuji@0 185 S: a OK TLS active
yuuji@0 186
yuuji@0 187 From this point on, everything is encrypted.
yuuji@0 188
yuuji@0 189 C: b login arnt tnra
yuuji@0 190 S: b OK Logged in as arnt
yuuji@0 191 C: c compress deflate
yuuji@0 192 S: d OK DEFLATE active
yuuji@0 193
yuuji@0 194 From this point on, everything is compressed before being
yuuji@0 195 encrypted.
yuuji@0 196
yuuji@0 197 The following example demonstrates how a server may refuse to
yuuji@0 198 compress twice:
yuuji@0 199
yuuji@0 200 S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
yuuji@0 201 [...]
yuuji@0 202 C: c compress deflate
yuuji@0 203 S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS
yuuji@0 204
yuuji@0 205 4. Compression Efficiency
yuuji@0 206
yuuji@0 207 This section is informative, not normative.
yuuji@0 208
yuuji@0 209 IMAP poses some unusual problems for a compression layer.
yuuji@0 210
yuuji@0 211 Upstream is fairly simple. Most IMAP clients send the same few
yuuji@0 212 commands again and again, so any compression algorithm that can
yuuji@0 213 exploit repetition works efficiently. The APPEND command is an
yuuji@0 214 exception; clients that send many APPEND commands may want to
yuuji@0 215 surround large literals with flushes in the same way as is
yuuji@0 216 recommended for servers later in this section.
yuuji@0 217
yuuji@0 218 Downstream has the unusual property that several kinds of data are
yuuji@0 219 sent, confusing all dictionary-based compression algorithms.
yuuji@0 220
yuuji@0 221
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Gulbrandsen Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 229
yuuji@0 230
yuuji@0 231 One type is IMAP responses. These are highly compressible; zlib
yuuji@0 232 using its least CPU-intensive setting compresses typical responses to
yuuji@0 233 25-40% of their original size.
yuuji@0 234
yuuji@0 235 Another type is email headers. These are equally compressible, and
yuuji@0 236 benefit from using the same dictionary as the IMAP responses.
yuuji@0 237
yuuji@0 238 A third type is email body text. Text is usually fairly short and
yuuji@0 239 includes much ASCII, so the same compression dictionary will do a
yuuji@0 240 good job here, too. When multiple messages in the same thread are
yuuji@0 241 read at the same time, quoted lines etc. can often be compressed
yuuji@0 242 almost to zero.
yuuji@0 243
yuuji@0 244 Finally, attachments (non-text email bodies) are transmitted, either
yuuji@0 245 in binary form or encoded with base-64.
yuuji@0 246
yuuji@0 247 When attachments are retrieved in binary form, DEFLATE may be able to
yuuji@0 248 compress them, but the format of the attachment is usually not IMAP-
yuuji@0 249 like, so the dictionary built while compressing IMAP does not help.
yuuji@0 250 The compressor has to adapt its dictionary from IMAP to the
yuuji@0 251 attachment's format, and then back. A few file formats aren't
yuuji@0 252 compressible at all using deflate, e.g., .gz, .zip, and .jpg files.
yuuji@0 253
yuuji@0 254 When attachments are retrieved in base-64 form, the same problems
yuuji@0 255 apply, but the base-64 encoding adds another problem. 8-bit
yuuji@0 256 compression algorithms such as deflate work well on 8-bit file
yuuji@0 257 formats, however base-64 turns a file into something resembling 6-bit
yuuji@0 258 bytes, hiding most of the 8-bit file format from the compressor.
yuuji@0 259
yuuji@0 260 When using the zlib library (see [RFC1951]), the functions
yuuji@0 261 deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
yuuji@0 262 implement this extension. The windowBits value must be in the range
yuuji@0 263 -8 to -15, or else deflateInit2() uses the wrong format.
yuuji@0 264 deflateParams() can be used to improve compression rate and resource
yuuji@0 265 use. The Z_FULL_FLUSH argument to deflate() can be used to clear the
yuuji@0 266 dictionary (the receiving peer does not need to do anything).
yuuji@0 267
yuuji@0 268 A client can improve downstream compression by implementing BINARY
yuuji@0 269 (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY.
yuuji@0 270 In the author's experience, the improvement ranges from 5% to 40%
yuuji@0 271 depending on the attachment being downloaded.
yuuji@0 272
yuuji@0 273 A server can improve downstream compression if it hints to the
yuuji@0 274 compressor that the data type is about to change strongly, e.g., by
yuuji@0 275 sending a Z_FULL_FLUSH at the start and end of large non-text
yuuji@0 276 literals (before and after '*CHAR8' in the definition of literal in
yuuji@0 277 RFC 3501, page 86). Small literals are best left alone. A possible
yuuji@0 278 boundary is 5k.
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Gulbrandsen Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 285
yuuji@0 286
yuuji@0 287 A server can improve the CPU efficiency both of the server and the
yuuji@0 288 client if it adjusts the compression level (e.g., using the
yuuji@0 289 deflateParams() function in zlib) at these points, to avoid trying to
yuuji@0 290 compress incompressible attachments. A very simple strategy is to
yuuji@0 291 change the level to 0 at the start of a literal provided the first
yuuji@0 292 two bytes are either 0x1F 0x8B (as in deflate-compressed files) or
yuuji@0 293 0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time. More
yuuji@0 294 complex strategies are possible.
yuuji@0 295
yuuji@0 296 5. Formal Syntax
yuuji@0 297
yuuji@0 298 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 299 Form (ABNF) notation as specified in [RFC4234]. This syntax augments
yuuji@0 300 the grammar specified in [RFC3501]. [RFC4234] defines SP and
yuuji@0 301 [RFC3501] defines command-auth, capability, and resp-text-code.
yuuji@0 302
yuuji@0 303 Except as noted otherwise, all alphabetic characters are case-
yuuji@0 304 insensitive. The use of upper or lower case characters to define
yuuji@0 305 token strings is for editorial clarity only. Implementations MUST
yuuji@0 306 accept these strings in a case-insensitive fashion.
yuuji@0 307
yuuji@0 308 command-auth =/ compress
yuuji@0 309
yuuji@0 310 compress = "COMPRESS" SP algorithm
yuuji@0 311
yuuji@0 312 capability =/ "COMPRESS=" algorithm
yuuji@0 313 ;; multiple COMPRESS capabilities allowed
yuuji@0 314
yuuji@0 315 algorithm = "DEFLATE"
yuuji@0 316
yuuji@0 317 resp-text-code =/ "COMPRESSIONACTIVE"
yuuji@0 318
yuuji@0 319 Note that due the syntax of capability names, future algorithm names
yuuji@0 320 must be atoms.
yuuji@0 321
yuuji@0 322 6. Security Considerations
yuuji@0 323
yuuji@0 324 As for TLS compression [RFC3749].
yuuji@0 325
yuuji@0 326 7. IANA Considerations
yuuji@0 327
yuuji@0 328 The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.
yuuji@0 329
yuuji@0 330
yuuji@0 331
yuuji@0 332
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Gulbrandsen Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 341
yuuji@0 342
yuuji@0 343 8. Acknowledgements
yuuji@0 344
yuuji@0 345 Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
yuuji@0 346 Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey
yuuji@0 347 Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with
yuuji@0 348 this document.
yuuji@0 349
yuuji@0 350 The author would also like to thank various people in the rooms at
yuuji@0 351 meetings, whose help is real, but not reflected in the author's
yuuji@0 352 mailbox.
yuuji@0 353
yuuji@0 354 9. References
yuuji@0 355
yuuji@0 356 9.1. Normative References
yuuji@0 357
yuuji@0 358 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
yuuji@0 359 version 1.3", RFC 1951, May 1996.
yuuji@0 360
yuuji@0 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 362 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 363
yuuji@0 364 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
yuuji@0 365 4rev1", RFC 3501, March 2003.
yuuji@0 366
yuuji@0 367 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 368 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 369
yuuji@0 370 9.2. Informative References
yuuji@0 371
yuuji@0 372 [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
yuuji@0 373 RFC 1962, June 1996.
yuuji@0 374
yuuji@0 375 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
yuuji@0 376 April 2003.
yuuji@0 377
yuuji@0 378 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
yuuji@0 379 Compression Methods", RFC 3749, May 2004.
yuuji@0 380
yuuji@0 381 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
yuuji@0 382 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
yuuji@0 383
yuuji@0 384 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
yuuji@0 385 Security Layer (SASL)", RFC 4422, June 2006.
yuuji@0 386
yuuji@0 387 [V42BIS] ITU, "V.42bis: Data compression procedures for data
yuuji@0 388 circuit-terminating equipment (DCE) using error correction
yuuji@0 389 procedures", http://www.itu.int/rec/T-REC-V.42bis, January
yuuji@0 390 1990.
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Gulbrandsen Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 397
yuuji@0 398
yuuji@0 399 [MNP] Gilbert Held, "The Complete Modem Reference", Second
yuuji@0 400 Edition, Wiley Professional Computing, ISBN 0-471-00852-4,
yuuji@0 401 May 1994.
yuuji@0 402
yuuji@0 403 Author's Address
yuuji@0 404
yuuji@0 405 Arnt Gulbrandsen
yuuji@0 406 Oryx Mail Systems GmbH
yuuji@0 407 Schweppermannstr. 8
yuuji@0 408 D-81671 Muenchen
yuuji@0 409 Germany
yuuji@0 410
yuuji@0 411 Fax: +49 89 4502 9758
yuuji@0 412 EMail: arnt@oryx.com
yuuji@0 413
yuuji@0 414
yuuji@0 415
yuuji@0 416
yuuji@0 417
yuuji@0 418
yuuji@0 419
yuuji@0 420
yuuji@0 421
yuuji@0 422
yuuji@0 423
yuuji@0 424
yuuji@0 425
yuuji@0 426
yuuji@0 427
yuuji@0 428
yuuji@0 429
yuuji@0 430
yuuji@0 431
yuuji@0 432
yuuji@0 433
yuuji@0 434
yuuji@0 435
yuuji@0 436
yuuji@0 437
yuuji@0 438
yuuji@0 439
yuuji@0 440
yuuji@0 441
yuuji@0 442
yuuji@0 443
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Gulbrandsen Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4978 The IMAP COMPRESS Extension August 2007
yuuji@0 453
yuuji@0 454
yuuji@0 455 Full Copyright Statement
yuuji@0 456
yuuji@0 457 Copyright (C) The IETF Trust (2007).
yuuji@0 458
yuuji@0 459 This document is subject to the rights, licenses and restrictions
yuuji@0 460 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 461 retain all their rights.
yuuji@0 462
yuuji@0 463 This document and the information contained herein are provided on an
yuuji@0 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
yuuji@0 466 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
yuuji@0 467 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
yuuji@0 468 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 470
yuuji@0 471 Intellectual Property
yuuji@0 472
yuuji@0 473 The IETF takes no position regarding the validity or scope of any
yuuji@0 474 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 475 pertain to the implementation or use of the technology described in
yuuji@0 476 this document or the extent to which any license under such rights
yuuji@0 477 might or might not be available; nor does it represent that it has
yuuji@0 478 made any independent effort to identify any such rights. Information
yuuji@0 479 on the procedures with respect to rights in RFC documents can be
yuuji@0 480 found in BCP 78 and BCP 79.
yuuji@0 481
yuuji@0 482 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 483 assurances of licenses to be made available, or the result of an
yuuji@0 484 attempt made to obtain a general license or permission for the use of
yuuji@0 485 such proprietary rights by implementers or users of this
yuuji@0 486 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 487 http://www.ietf.org/ipr.
yuuji@0 488
yuuji@0 489 The IETF invites any interested party to bring to its attention any
yuuji@0 490 copyrights, patents or patent applications, or other proprietary
yuuji@0 491 rights that may cover technology that may be required to implement
yuuji@0 492 this standard. Please address the information to the IETF at
yuuji@0 493 ietf-ipr@ietf.org.
yuuji@0 494
yuuji@0 495
yuuji@0 496
yuuji@0 497
yuuji@0 498
yuuji@0 499
yuuji@0 500
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Gulbrandsen Standards Track [Page 9]
yuuji@0 507

UW-IMAP'd extensions by yuuji