ignore generated appdata
[claws.git] / doc / src / rfc2683.txt
1
2
3
4
5
6
7 Network Working Group                                           B. Leiba
8 Request for Comments: 2683               IBM T.J. Watson Research Center
9 Category: Informational                                   September 1999
10
11
12                   IMAP4 Implementation Recommendations
13
14 Status of this Memo
15
16    This memo provides information for the Internet community.  It does
17    not specify an Internet standard of any kind.  Distribution of this
18    memo is unlimited.
19
20 Copyright Notice
21
22    Copyright (C) The Internet Society (1999).  All Rights Reserved.
23
24 1. Abstract
25
26    The IMAP4 specification [RFC-2060] describes a rich protocol for use
27    in building clients and servers for storage, retrieval, and
28    manipulation of electronic mail.  Because the protocol is so rich and
29    has so many implementation choices, there are often trade-offs that
30    must be made and issues that must be considered when designing such
31    clients and servers.  This document attempts to outline these issues
32    and to make recommendations in order to make the end products as
33    interoperable as possible.
34
35 2. Conventions used in this document
36
37    In examples, "C:" indicates lines sent by a client that is connected
38    to a server.  "S:" indicates lines sent by the server to the client.
39
40    The words "must", "must not", "should", "should not", and "may" are
41    used with specific meaning in this document; since their meaning is
42    somewhat different from that specified in RFC 2119, we do not put
43    them in all caps here.  Their meaning is as follows:
44
45    must --       This word means that the action described is necessary
46                  to ensure interoperability.  The recommendation should
47                  not be ignored.
48    must not --   This phrase means that the action described will be
49                  almost certain to hurt interoperability.  The
50                  recommendation should not be ignored.
51
52
53
54
55
56
57
58 Leiba                        Informational                      [Page 1]
59 \f
60 RFC 2683          IMAP4 Implementation Recommendations    September 1999
61
62
63    should --     This word means that the action described is strongly
64                  recommended and will enhance interoperability or
65                  usability.  The recommendation should not be ignored
66                  without careful consideration.
67    should not -- This phrase means that the action described is strongly
68                  recommended against, and might hurt interoperability or
69                  usability.  The recommendation should not be ignored
70                  without careful consideration.
71    may --        This word means that the action described is an
72                  acceptable implementation choice.  No specific
73                  recommendation is implied; this word is used to point
74                  out a choice that might not be obvious, or to let
75                  implementors know what choices have been made by
76                  existing implementations.
77
78 3. Interoperability Issues and Recommendations
79
80 3.1.   Accessibility
81
82    This section describes the issues related to access to servers and
83    server resources.  Concerns here include data sharing and maintenance
84    of client/server connections.
85
86 3.1.1. Multiple Accesses of the Same Mailbox
87
88    One strong point of IMAP4 is that, unlike POP3, it allows for
89    multiple simultaneous access to a single mailbox.  A user can, thus,
90    read mail from a client at home while the client in the office is
91    still connected; or the help desk staff can all work out of the same
92    inbox, all seeing the same pool of questions.  An important point
93    about this capability, though is that NO SERVER IS GUARANTEED TO
94    SUPPORT THIS.  If you are selecting an IMAP server and this facility
95    is important to you, be sure that the server you choose to install,
96    in the configuration you choose to use, supports it.
97
98    If you are designing a client, you must not assume that you can
99    access the same mailbox more than once at a time.  That means
100
101    1. you must handle gracefully the failure of a SELECT command if the
102       server refuses the second SELECT,
103    2. you must handle reasonably the severing of your connection (see
104       "Severed Connections", below) if the server chooses to allow the
105       second SELECT by forcing the first off,
106    3. you must avoid making multiple connections to the same mailbox in
107       your own client (for load balancing or other such reasons), and
108    4. you must avoid using the STATUS command on a mailbox that you have
109       selected (with some server implementations the STATUS command has
110       the same problems with multiple access as do the SELECT and
111
112
113
114 Leiba                        Informational                      [Page 2]
115 \f
116 RFC 2683          IMAP4 Implementation Recommendations    September 1999
117
118
119       EXAMINE commands).
120
121    A further note about STATUS: The STATUS command is sometimes used to
122    check a non-selected mailbox for new mail.  This mechanism must not
123    be used to check for new mail in the selected mailbox; section 5.2 of
124    [RFC-2060] specifically forbids this in its last paragraph.  Further,
125    since STATUS takes a mailbox name it is an independent operation, not
126    operating on the selected mailbox.  Because of this, the information
127    it returns is not necessarily in synchronization with the selected
128    mailbox state.
129
130 3.1.2. Severed Connections
131
132    The client/server connection may be severed for one of three reasons:
133    the client severs the connection, the server severs the connection,
134    or the connection is severed by outside forces beyond the control of
135    the client and the server (a telephone line drops, for example).
136    Clients and servers must both deal with these situations.
137
138    When the client wants to sever a connection, it's usually because it
139    has finished the work it needed to do on that connection.  The client
140    should send a LOGOUT command, wait for the tagged response, and then
141    close the socket.  But note that, while this is what's intended in
142    the protocol design, there isn't universal agreement here.  Some
143    contend that sending the LOGOUT and waiting for the two responses
144    (untagged BYE and tagged OK) is wasteful and unnecessary, and that
145    the client can simply close the socket.  The server should interpret
146    the closed socket as a log out by the client.  The counterargument is
147    that it's useful from the standpoint of cleanup, problem
148    determination, and the like, to have an explicit client log out,
149    because otherwise there is no way for the server to tell the
150    difference between "closed socket because of log out" and "closed
151    socket because communication was disrupted".  If there is a
152    client/server interaction problem, a client which routinely
153    terminates a session by breaking the connection without a LOGOUT will
154    make it much more difficult to determine the problem.
155
156    Because of this disagreement, server designers must be aware that
157    some clients might close the socket without sending a LOGOUT.  In any
158    case, whether or not a LOGOUT was sent, the server should not
159    implicitly expunge any messages from the selected mailbox.  If a
160    client wants the server to do so, it must send a CLOSE or EXPUNGE
161    command explicitly.
162
163    When the server wants to sever a connection it's usually due to an
164    inactivity timeout or is because a situation has arisen that has
165    changed the state of the mail store in a way that the server can not
166    communicate to the client.  The server should send an untagged BYE
167
168
169
170 Leiba                        Informational                      [Page 3]
171 \f
172 RFC 2683          IMAP4 Implementation Recommendations    September 1999
173
174
175    response to the client and then close the socket.  Sending an
176    untagged BYE response before severing allows the server to send a
177    human-readable explanation of the problem to the client, which the
178    client may then log, display to the user, or both (see section 7.1.5
179    of [RFC-2060]).
180
181    Regarding inactivity timeouts, there is some controversy.  Unlike
182    POP, for which the design is for a client to connect, retrieve mail,
183    and log out, IMAP's design encourages long-lived (and mostly
184    inactive) client/server sessions.  As the number of users grows, this
185    can use up a lot of server resources, especially with clients that
186    are designed to maintain sessions for mailboxes that the user has
187    finished accessing.  To alleviate this, a server may implement an
188    inactivity timeout, unilaterally closing a session (after first
189    sending an untagged BYE, as noted above).  Some server operators have
190    reported dramatic improvements in server performance after doing
191    this.  As specified in [RFC-2060], if such a timeout is done it must
192    not be until at least 30 minutes of inactivity.  The reason for this
193    specification is to prevent clients from sending commands (such as
194    NOOP) to the server at frequent intervals simply to avert a too-early
195    timeout.  If the client knows that the server may not time out the
196    session for at least 30 minutes, then the client need not poll at
197    intervals more frequent than, say, 25 minutes.
198
199 3.2.   Scaling
200
201    IMAP4 has many features that allow for scalability, as mail stores
202    become larger and more numerous.  Large numbers of users, mailboxes,
203    and messages, and very large messages require thought to handle
204    efficiently.  This document will not address the administrative
205    issues involved in large numbers of users, but we will look at the
206    other items.
207
208 3.2.1. Flood Control
209
210    There are three situations when a client can make a request that will
211    result in a very large response - too large for the client reasonably
212    to deal with: there are a great many mailboxes available, there are a
213    great many messages in the selected mailbox, or there is a very large
214    message part.  The danger here is that the end user will be stuck
215    waiting while the server sends (and the client processes) an enormous
216    response.  In all of these cases there are things a client can do to
217    reduce that danger.
218
219    There is also the case where a client can flood a server, by sending
220    an arbitratily long command.  We'll discuss that issue, too, in this
221    section.
222
223
224
225
226 Leiba                        Informational                      [Page 4]
227 \f
228 RFC 2683          IMAP4 Implementation Recommendations    September 1999
229
230
231 3.2.1.1.  Listing Mailboxes
232
233    Some servers present Usenet newsgroups to IMAP users.  Newsgroups,
234    and other such hierarchical mailbox structures, can be very numerous
235    but may have only a few entries at the top level of hierarchy.  Also,
236    some servers are built against mail stores that can, unbeknownst to
237    the server, have circular hierarchies - that is, it's possible for
238    "a/b/c/d" to resolve to the same file structure as "a", which would
239    then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
240    will never end.  The LIST response in this case will be unlimited.
241
242    Clients that will have trouble with this are those that use
243
244        C: 001 LIST "" *
245
246    to determine the mailbox list.  Because of this, clients should not
247    use an unqualified "*" that way in the LIST command.  A safer
248    approach is to list each level of hierarchy individually, allowing
249    the user to traverse the tree one limb at a time, thus:
250
251        C: 001 LIST "" %
252        S: * LIST () "/" Banana
253        S: * LIST ...etc...
254        S: 001 OK done
255
256    and then
257
258        C: 002 LIST "" Banana/%
259        S: * LIST () "/" Banana/Apple
260        S: * LIST ...etc...
261        S: 002 OK done
262
263    Using this technique the client's user interface can give the user
264    full flexibility without choking on the voluminous reply to "LIST *".
265
266    Of course, it is still possible that the reply to
267
268        C: 005 LIST "" alt.fan.celebrity.%
269
270    may be thousands of entries long, and there is, unfortunately,
271    nothing the client can do to protect itself from that.  This has not
272    yet been a notable problem.
273
274    Servers that may export circular hierarchies (any server that
275    directly presents a UNIX file system, for instance) should limit the
276    hierarchy depth to prevent unlimited LIST responses.  A suggested
277    depth limit is 20 hierarchy levels.
278
279
280
281
282 Leiba                        Informational                      [Page 5]
283 \f
284 RFC 2683          IMAP4 Implementation Recommendations    September 1999
285
286
287 3.2.1.2.  Fetching the List of Messages
288
289    When a client selects a mailbox, it is given a count, in the untagged
290    EXISTS response, of the messages in the mailbox.  This number can be
291    very large.  In such a case it might be unwise to use
292
293        C: 004 FETCH 1:* ALL
294
295    to populate the user's view of the mailbox.  One good method to avoid
296    problems with this is to batch the requests, thus:
297
298        C: 004 FETCH 1:50 ALL
299        S: * 1 FETCH ...etc...
300        S: 004 OK done
301        C: 005 FETCH 51:100 ALL
302        S: * 51 FETCH ...etc...
303        S: 005 OK done
304        C: 006 FETCH 101:150 ALL
305        ...etc...
306
307    Using this method, another command, such as "FETCH 6 BODY[1]" can be
308    inserted as necessary, and the client will not have its access to the
309    server blocked by a storm of FETCH replies.  (Such a method could be
310    reversed to fetch the LAST 50 messages first, then the 50 prior to
311    that, and so on.)
312
313    As a smart extension of this, a well designed client, prepared for
314    very large mailboxes, will not automatically fetch data for all
315    messages AT ALL.  Rather, the client will populate the user's view
316    only as the user sees it, possibly pre-fetching selected information,
317    and only fetching other information as the user scrolls to it.  For
318    example, to select only those messages beginning with the first
319    unseen one:
320
321        C: 003 SELECT INBOX
322        S: * 10000 EXISTS
323        S: * 80 RECENT
324        S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
325        S: * OK [UIDVALIDITY 824708485] UID validity status
326        S: * OK [UNSEEN 9921] First unseen message
327        S: 003 OK [READ-WRITE] SELECT completed
328        C: 004 FETCH 9921:* ALL
329        ... etc...
330
331    If the server does not return an OK [UNSEEN] response, the client may
332    use SEARCH UNSEEN to obtain that value.
333
334
335
336
337
338 Leiba                        Informational                      [Page 6]
339 \f
340 RFC 2683          IMAP4 Implementation Recommendations    September 1999
341
342
343    This mechanism is good as a default presentation method, but only
344    works well if the default message order is acceptable.  A client may
345    want to present various sort orders to the user (by subject, by date
346    sent, by sender, and so on) and in that case (lacking a SORT
347    extension on the server side) the client WILL have to retrieve all
348    message descriptors.  A client that provides this service should not
349    do it by default and should inform the user of the costs of choosing
350    this option for large mailboxes.
351
352 3.2.1.3.  Fetching a Large Body Part
353
354    The issue here is similar to the one for a list of messages.  In the
355    BODYSTRUCTURE response the client knows the size, in bytes, of the
356    body part it plans to fetch.  Suppose this is a 70 MB video clip. The
357    client can use partial fetches to retrieve the body part in pieces,
358    avoiding the problem of an uninterruptible 70 MB literal coming back
359    from the server:
360
361        C: 022 FETCH 3 BODY[1]<0.20000>
362        S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
363        S: ...data...)
364        S: 022 OK done
365        C: 023 FETCH 3 BODY[1]<20001.20000>
366        S: * 3 FETCH (BODY[1]<20001> {20000}
367        S: ...data...)
368        S: 023 OK done
369        C: 024 FETCH 3 BODY[1]<40001.20000>
370        ...etc...
371
372 3.2.1.4.  BODYSTRUCTURE vs. Entire Messages
373
374    Because FETCH BODYSTRUCTURE is necessary in order to determine the
375    number of body parts, and, thus, whether a message has "attachments",
376    clients often use FETCH FULL as their normal method of populating the
377    user's view of a mailbox.  The benefit is that the client can display
378    a paperclip icon or some such indication along with the normal
379    message summary.  However, this comes at a significant cost with some
380    server configurations.  The parsing needed to generate the FETCH
381    BODYSTRUCTURE response may be time-consuming compared with that
382    needed for FETCH ENVELOPE.  The client developer should consider this
383    issue when deciding whether the ability to add a paperclip icon is
384    worth the tradeoff in performance, especially with large mailboxes.
385
386    Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
387    (or the equivalent FETCH RFC822) to retrieve the entire message.
388    They then do the MIME parsing in the client.  This may give the
389    client slightly more flexibility in some areas (access, for instance,
390    to header fields that aren't returned in the BODYSTRUCTURE and
391
392
393
394 Leiba                        Informational                      [Page 7]
395 \f
396 RFC 2683          IMAP4 Implementation Recommendations    September 1999
397
398
399    ENVELOPE responses), but it can cause severe performance problems by
400    forcing the transfer of all body parts when the user might only want
401    to see some of them - a user logged on by modem and reading a small
402    text message with a large ZIP file attached may prefer to read the
403    text only and save the ZIP file for later.  Therefore, a client
404    should not normally retrieve entire messages and should retrieve
405    message body parts selectively.
406
407 3.2.1.5.  Long Command Lines
408
409    A client can wind up building a very long command line in an effort to
410    try to be efficient about requesting information from a server.  This
411    can typically happen when a client builds a message set from selected
412    messages and doesn't recognise that contiguous blocks of messages may
413    be group in a range.  Suppose a user selects all 10,000 messages in a
414    large mailbox and then unselects message 287.  The client could build
415    that message set as "1:286,288:10000", but a client that doesn't
416    handle that might try to enumerate each message individually and build
417    "1,2,3,4, [and so on] ,9999,10000".  Adding that to the fetch command
418    results in a command line that's almost 49,000 octets long, and,
419    clearly, one can construct a command line that's even longer.
420
421    A client should limit the length of the command lines it generates to
422    approximately 1000 octets (including all quoted strings but not
423    including literals).  If the client is unable to group things into
424    ranges so that the command line is within that length, it should
425    split the request into multiple commands.  The client should use
426    literals instead of long quoted strings, in order to keep the command
427    length down.
428
429    For its part, a server should allow for a command line of at least
430    8000 octets.  This provides plenty of leeway for accepting reasonable
431    length commands from clients.  The server should send a BAD response
432    to a command that does not end within the server's maximum accepted
433    command length.
434
435 3.2.2. Subscriptions
436
437    The client isn't the only entity that can get flooded: the end user,
438    too, may need some flood control.  The IMAP4 protocol provides such
439    control in the form of subscriptions.  Most servers support the
440    SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
441    narrow down a large list of available mailboxes by subscribing to the
442    ones that they usually want to see.  Clients, with this in mind,
443    should give the user a way to see only subscribed mailboxes.  A
444    client that never uses the LSUB command takes a significant usability
445    feature away from the user.  Of course, the client would not want to
446    hide the LIST command completely; the user needs to have a way to
447
448
449
450 Leiba                        Informational                      [Page 8]
451 \f
452 RFC 2683          IMAP4 Implementation Recommendations    September 1999
453
454
455    choose between LIST and LSUB.  The usual way to do this is to provide
456    a setting like "show which mailboxes?:  [] all  [] subscribed only".
457
458 3.2.3. Searching
459
460    IMAP SEARCH commands can become particularly troublesome (that is,
461    slow) on mailboxes containing a large number of messages.  So let's
462    put a few things in perspective in that regard.
463
464    The flag searches should be fast.  The flag searches (ALL, [UN]SEEN,
465    [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
466    are known to be used by clients for the client's own use (for
467    instance, some clients use "SEARCH UNSEEN" to find unseen mail and
468    "SEARCH DELETED" to warn the user before expunging messages).
469
470    Other searches, particularly the text searches (HEADER, TEXT, BODY)
471    are initiated by the user, rather than by the client itself, and
472    somewhat slower performance can be tolerated, since the user is aware
473    that the search is being done (and is probably aware that it might be
474    time-consuming).  A smart server might use dynamic indexing to speed
475    commonly used text searches.
476
477    The client may allow other commands to be sent to the server while a
478    SEARCH is in progress, but at the time of this writing there is
479    little or no server support for parallel processing of multiple
480    commands in the same session (and see "Multiple Accesses of the Same
481    Mailbox" above for a description of the dangers of trying to work
482    around this by doing your SEARCH in another session).
483
484    Another word about text searches: some servers, built on database
485    back-ends with indexed search capabilities, may return search results
486    that do not match the IMAP spec's "case-insensitive substring"
487    requirements.  While these servers are in violation of the protocol,
488    there is little harm in the violation as long as the search results
489    are used only in response to a user's request.  Still, developers of
490    such servers should be aware that they ARE violating the protocol,
491    should think carefully about that behaviour, and must be certain that
492    their servers respond accurately to the flag searches for the reasons
493    outlined above.
494
495    In addition, servers should support CHARSET UTF-8 [UTF-8] in
496    searches.
497
498
499
500
501
502
503
504
505
506 Leiba                        Informational                      [Page 9]
507 \f
508 RFC 2683          IMAP4 Implementation Recommendations    September 1999
509
510
511 3.3    Avoiding Invalid Requests
512
513    IMAP4 provides ways for a server to tell a client in advance what is
514    and isn't permitted in some circumstances.  Clients should use these
515    features to avoid sending requests that a well designed client would
516    know to be invalid.  This section explains this in more detail.
517
518 3.3.1. The CAPABILITY Command
519
520    All IMAP4 clients should use the CAPABILITY command to determine what
521    version of IMAP and what optional features a server supports.  The
522    client should not send IMAP4rev1 commands and arguments to a server
523    that does not advertize IMAP4rev1 in its CAPABILITY response.
524    Similarly, the client should not send IMAP4 commands that no longer
525    exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
526    CAPABILITY response.  An IMAP4rev1 server is NOT required to support
527    obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
528    fact lull you into thinking that it's valid to send such commands to
529    an IMAP4rev1 server).
530
531    A client should not send commands to probe for the existance of
532    certain extensions.  All standard and standards-track extensions
533    include CAPABILITY tokens indicating their presense.  All private and
534    experimental extensions should do the same, and clients that take
535    advantage of them should use the CAPABILITY response to determine
536    whether they may be used or not.
537
538 3.3.2. Don't Do What the Server Says You Can't
539
540    In many cases, the server, in response to a command, will tell the
541    client something about what can and can't be done with a particular
542    mailbox.  The client should pay attention to this information and
543    should not try to do things that it's been told it can't do.
544
545    Examples:
546
547    *  Do not try to SELECT a mailbox that has the \Noselect flag set.
548    *  Do not try to CREATE a sub-mailbox in a mailbox that has the
549       \Noinferiors flag set.
550    *  Do not respond to a failing COPY or APPEND command by trying to
551       CREATE the target mailbox if the server does not respond with a
552       [TRYCREATE] response code.
553    *  Do not try to expunge a mailbox that has been selected with the
554       [READ-ONLY] response code.
555
556
557
558
559
560
561
562 Leiba                        Informational                     [Page 10]
563 \f
564 RFC 2683          IMAP4 Implementation Recommendations    September 1999
565
566
567 3.4.   Miscellaneous Protocol Considerations
568
569    We describe here a number of important protocol-related issues, the
570    misunderstanding of which has caused significant interoperability
571    problems in IMAP4 implementations.  One general item is that every
572    implementer should be certain to take note of and to understand
573    section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
574    [RFC-2060].
575
576 3.4.1. Well Formed Protocol
577
578    We cannot stress enough the importance of adhering strictly to the
579    protocol grammar.  The specification of the protocol is quite rigid;
580    do not assume that you can insert blank space for "readability" if
581    none is called for.  Keep in mind that there are parsers out there
582    that will crash if there are protocol errors.  There are clients that
583    will report every parser burp to the user.  And in any case,
584    information that cannot be parsed is information that is lost.  Be
585    careful in your protocol generation.  And see "A Word About Testing",
586    below.
587
588    In particular, note that the string in the INTERNALDATE response is
589    NOT an RFC-822 date string - that is, it is not in the same format as
590    the first string in the ENVELOPE response.  Since most clients will,
591    in fact, accept an RFC-822 date string in the INTERNALDATE response,
592    it's easy to miss this in your interoperability testing.  But it will
593    cause a problem with some client, so be sure to generate the correct
594    string for this field.
595
596 3.4.2. Special Characters
597
598    Certain characters, currently the double-quote and the backslash, may
599    not be sent as-is inside a quoted string.  These characters must be
600    preceded by the escape character if they are in a quoted string, or
601    else the string must be sent as a literal.  Both clients and servers
602    must handle this, both on output (they must send these characters
603    properly) and on input (they must be able to receive escaped
604    characters in quoted strings).  Example:
605
606        C: 001 LIST "" %
607        S: * LIST () "" INBOX
608        S: * LIST () "\\" TEST
609        S: * LIST () "\\" {12}
610        S: "My" mailbox
611        S: 001 OK done
612        C: 002 LIST "" "\"My\" mailbox\\%"
613        S: * LIST () "\\" {17}
614        S: "My" mailbox\Junk
615
616
617
618 Leiba                        Informational                     [Page 11]
619 \f
620 RFC 2683          IMAP4 Implementation Recommendations    September 1999
621
622
623        S: 002 OK done
624
625    Note that in the example the server sent the hierarchy delimiter as
626    an escaped character in the quoted string and sent the mailbox name
627    containing imbedded double-quotes as a literal.  The client used only
628    quoted strings, escaping both the backslash and the double-quote
629    characters.
630
631    The CR and LF characters may be sent ONLY in literals; they are not
632    allowed, even if escaped, inside quoted strings.
633
634    And while we're talking about special characters: the IMAP spec, in
635    the section titled "Mailbox International Naming Convention",
636    describes how to encode mailbox names in modified UTF-7 [UTF-7 and
637    RFC-2060].  Implementations must adhere to this in order to be
638    interoperable in the international market, and servers should
639    validate mailbox names sent by client and reject names that do not
640    conform.
641
642    As to special characters in userids and passwords: clients must not
643    restrict what a user may type in for a userid or a password.  The
644    formal grammar specifies that these are "astrings", and an astring
645    can be a literal.  A literal, in turn can contain any 8-bit
646    character, and clients must allow users to enter all 8-bit characters
647    here, and must pass them, unchanged, to the server (being careful to
648    send them as literals when necessary).  In particular, some server
649    configurations use "@" in user names, and some clients do not allow
650    that character to be entered; this creates a severe interoperability
651    problem.
652
653 3.4.3. UIDs and UIDVALIDITY
654
655    Servers that support existing back-end mail stores often have no good
656    place to save UIDs for messages.  Often the existing mail store will
657    not have the concept of UIDs in the sense that IMAP has: strictly
658    increasing, never re-issued, 32-bit integers.  Some servers solve
659    this by storing the UIDs in a place that's accessible to end users,
660    allowing for the possibility that the users will delete them.  Others
661    solve it by re-assigning UIDs every time a mailbox is selected.
662
663    The server should maintain UIDs permanently for all messages if it
664    can.  If that's not possible, the server must change the UIDVALIDITY
665    value for the mailbox whenever any of the UIDs may have become
666    invalid.  Clients must recognize that the UIDVALIDITY has changed and
667    must respond to that condition by throwing away any information that
668    they have saved about UIDs in that mailbox.  There have been many
669    problems in this area when clients have failed to do this; in the
670    worst case it will result in loss of mail when a client deletes the
671
672
673
674 Leiba                        Informational                     [Page 12]
675 \f
676 RFC 2683          IMAP4 Implementation Recommendations    September 1999
677
678
679    wrong piece of mail by using a stale UID.
680
681    It seems to be a common misunderstanding that "the UIDVALIDITY and
682    the UID, taken together, form a 64-bit identifier that uniquely
683    identifies a message on a server".  This is absolutely NOT TRUE.
684    There is no assurance that the UIDVALIDITY values of two mailboxes be
685    different, so the UIDVALIDITY in no way identifies a mailbox.  The
686    ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
687    client a way to check the validity of the UIDs it has cached.  While
688    it is a valid implementation choice to put these values together to
689    make a 64-bit identifier for the message, the important concept here
690    is that UIDs are not unique between mailboxes; they are only unique
691    WITHIN a given mailbox.
692
693    Some server implementations have attempted to make UIDs unique across
694    the entire server.  This is inadvisable, in that it limits the life
695    of UIDs unnecessarily.  The UID is a 32-bit number and will run out
696    in reasonably finite time if it's global across the server.  If you
697    assign UIDs sequentially in one mailbox, you will not have to start
698    re-using them until you have had, at one time or another, 2**32
699    different messages in that mailbox.  In the global case, you will
700    have to reuse them once you have had, at one time or another, 2**32
701    different messages in the entire mail store.  Suppose your server has
702    around 8000 users registered (2**13).  That gives an average of 2**19
703    UIDs per user.  Suppose each user gets 32 messages (2**5) per day.
704    That gives you 2**14 days (16000+ days = about 45 years) before you
705    run out.  That may seem like enough, but multiply the usage just a
706    little (a lot of spam, a lot of mailing list subscriptions, more
707    users) and you limit yourself too much.
708
709    What's worse is that if you have to wrap the UIDs, and, thus, you
710    have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
711    you have to do it for EVERY mailbox in the system, since they all
712    share the same UID pool.  If you assign UIDs per mailbox and you have
713    a problem, you only have to kill the UIDs for that one mailbox.
714
715    Under extreme circumstances (and this is extreme, indeed), the server
716    may have to invalidate UIDs while a mailbox is in use by a client -
717    that is, the UIDs that the client knows about in its active mailbox
718    are no longer valid.  In that case, the server must immediately
719    change the UIDVALIDITY and must communicate this to the client.  The
720    server may do this by sending an unsolicited UIDVALIDITY message, in
721    the same form as in response to the SELECT command.  Clients must be
722    prepared to handle such a message and the possibly coincident failure
723    of the command in process.  For example:
724
725
726
727
728
729
730 Leiba                        Informational                     [Page 13]
731 \f
732 RFC 2683          IMAP4 Implementation Recommendations    September 1999
733
734
735        C: 032 UID STORE 382 +Flags.silent \Deleted
736        S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
737        S: 032 NO UID command rejected because UIDVALIDITY changed!
738        C: ...invalidates local information and re-fetches...
739        C: 033 FETCH 1:* UID
740        ...etc...
741
742    At the time of the writing of this document, the only server known to
743    do this does so only under the following condition: the client
744    selects INBOX, but there is not yet a physical INBOX file created.
745    Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
746    temporary UIDVALIDITY of 1.  While the INBOX remains selected, mail
747    is delivered to the user, which creates the real INBOX file and
748    assigns a permanent UIDVALIDITY (that is likely not to be 1).  The
749    server reports the change of UIDVALIDITY, but as there were no
750    messages before, so no UIDs have actually changed, all the client
751    must do is accept the change in UIDVALIDITY.
752
753    Alternatively, a server may force the client to re-select the
754    mailbox, at which time it will obtain a new UIDVALIDITY value.  To do
755    this, the server closes this client session (see "Severed
756    Connections" above) and the client then reconnects and gets back in
757    synch.  Clients must be prepared for either of these behaviours.
758
759    We do not know of, nor do we anticipate the future existance of, a
760    server that changes UIDVALIDITY while there are existing messages,
761    but clients must be prepared to handle this eventuality.
762
763 3.4.4. FETCH Responses
764
765    When a client asks for certain information in a FETCH command, the
766    server may return the requested information in any order, not
767    necessarily in the order that it was requested.  Further, the server
768    may return the information in separate FETCH responses and may also
769    return information that was not explicitly requested (to reflect to
770    the client changes in the state of the subject message).  Some
771    examples:
772
773        C: 001 FETCH 1 UID FLAGS INTERNALDATE
774        S: * 5 FETCH (FLAGS (\Deleted))
775        S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
776        S: 001 OK done
777
778    (In this case, the responses are in a different order.  Also, the
779    server returned a flag update for message 5, which wasn't part of the
780    client's request.)
781
782
783
784
785
786 Leiba                        Informational                     [Page 14]
787 \f
788 RFC 2683          IMAP4 Implementation Recommendations    September 1999
789
790
791        C: 002 FETCH 2 UID FLAGS INTERNALDATE
792        S: * 2 FETCH (INTERNALDATE "...")
793        S: * 2 FETCH (UID 399)
794        S: * 2 FETCH (FLAGS ())
795        S: 002 OK done
796
797    (In this case, the responses are in a different order and were
798    returned in separate responses.)
799
800        C: 003 FETCH 2 BODY[1]
801        S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
802        S: Hello world!
803        S: )
804        S: 003 OK done
805
806    (In this case, the FLAGS response was added by the server, since
807    fetching the body part caused the server to set the \Seen flag.)
808
809    Because of this characteristic a client must be ready to receive any
810    FETCH response at any time and should use that information to update
811    its local information about the message to which the FETCH response
812    refers.  A client must not assume that any FETCH responses will come
813    in any particular order, or even that any will come at all.  If after
814    receiving the tagged response for a FETCH command the client finds
815    that it did not get all of the information requested, the client
816    should send a NOOP command to the server to ensure that the server
817    has an opportunity to send any pending EXPUNGE responses to the
818    client (see [RFC-2180]).
819
820 3.4.5. RFC822.SIZE
821
822    Some back-end mail stores keep the mail in a canonical form, rather
823    than retaining the original MIME format of the messages.  This means
824    that the server must reassemble the message to produce a MIME stream
825    when a client does a fetch such as RFC822 or BODY[], requesting the
826    entire message.  It also may mean that the server has no convenient
827    way to know the RFC822.SIZE of the message.  Often, such a server
828    will actually have to build the MIME stream to compute the size, only
829    to throw the stream away and report the size to the client.
830
831    When this is the case, some servers have chosen to estimate the size,
832    rather than to compute it precisely.  Such an estimate allows the
833    client to display an approximate size to the user and to use the
834    estimate in flood control considerations (q.v.), but requires that
835    the client not use the size for things such as allocation of buffers,
836    because those buffers might then be too small to hold the actual MIME
837    stream.  Instead, a client should use the size that's returned in the
838    literal when you fetch the data.
839
840
841
842 Leiba                        Informational                     [Page 15]
843 \f
844 RFC 2683          IMAP4 Implementation Recommendations    September 1999
845
846
847    The protocol requires that the RFC822.SIZE value returned by the
848    server be EXACT.  Estimating the size is a protocol violation, and
849    server designers must be aware that, despite the performance savings
850    they might realize in using an estimate, this practice will cause
851    some clients to fail in various ways.  If possible, the server should
852    compute the RFC822.SIZE for a particular message once, and then save
853    it for later retrieval.  If that's not possible, the server must
854    compute the value exactly every time.  Incorrect estimates do cause
855    severe interoperability problems with some clients.
856
857 3.4.6. Expunged Messages
858
859    If the server allows multiple connections to the same mailbox, it is
860    often possible for messages to be expunged in one client unbeknownst
861    to another client.  Since the server is not allowed to tell the
862    client about these expunged messages in response to a FETCH command,
863    the server may have to deal with the issue of how to return
864    information about an expunged message.  There was extensive
865    discussion about this issue, and the results of that discussion are
866    summarized in [RFC-2180].  See that reference for a detailed
867    explanation and for recommendations.
868
869 3.4.7. The Namespace Issue
870
871    Namespaces are a very muddy area in IMAP4 implementation right now
872    (see [NAMESPACE] for a proposal to clear the water a bit).  Until the
873    issue is resolved, the important thing for client developers to
874    understand is that some servers provide access through IMAP to more
875    than just the user's personal mailboxes, and, in fact, the user's
876    personal mailboxes may be "hidden" somewhere in the user's default
877    hierarchy.  The client, therefore, should provide a setting wherein
878    the user can specify a prefix to be used when accessing mailboxes. If
879    the user's mailboxes are all in "~/mail/", for instance, then the
880    user can put that string in the prefix.  The client would then put
881    the prefix in front of any name pattern in the LIST and LSUB
882    commands:
883
884        C: 001 LIST "" ~/mail/%
885
886    (See also "Reference Names in the LIST Command" below.)
887
888 3.4.8. Creating Special-Use Mailboxes
889
890    It may seem at first that this is part of the namespace issue; it is
891    not, and is only indirectly related to it.  A number of clients like
892    to create special-use mailboxes with particular names.  Most
893    commonly, clients with a "trash folder" model of message deletion
894    want to create a mailbox with the name "Trash" or "Deleted".  Some
895
896
897
898 Leiba                        Informational                     [Page 16]
899 \f
900 RFC 2683          IMAP4 Implementation Recommendations    September 1999
901
902
903    clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
904    "Sent Mail" mailbox.  And so on.  There are two major
905    interoperability problems with this practice:
906
907    1. different clients may use different names for mailboxes with
908       similar functions (such as "Trash" and "Deleted"), or may manage
909       the same mailboxes in different ways, causing problems if a user
910       switches between clients and
911    2. there is no guarantee that the server will allow the creation of
912       the desired mailbox.
913
914    The client developer is, therefore, well advised to consider
915    carefully the creation of any special-use mailboxes on the server,
916    and, further, the client must not require such mailbox creation -
917    that is, if you do decide to do this, you must handle gracefully the
918    failure of the CREATE command and behave reasonably when your
919    special-use mailboxes do not exist and can not be created.
920
921    In addition, the client developer should provide a convenient way for
922    the user to select the names for any special-use mailboxes, allowing
923    the user to make these names the same in all clients used and to put
924    them where the user wants them.
925
926 3.4.9. Reference Names in the LIST Command
927
928    Many implementers of both clients and servers are confused by the
929    "reference name" on the LIST command.  The reference name is intended
930    to be used in much the way a "cd" (change directory) command is used
931    on Unix, PC DOS, Windows, and OS/2 systems.  That is, the mailbox
932    name is interpreted in much the same way as a file of that name would
933    be found if one had done a "cd" command into the directory specified
934    by the reference name.  For example, in Unix we have the following:
935
936        > cd /u/jones/junk
937        > vi banana        [file is "/u/jones/junk/banana"]
938        > vi stuff/banana  [file is "/u/jones/junk/stuff/banana"]
939        > vi /etc/hosts    [file is "/etc/hosts"]
940
941    In the past, there have been several interoperability problems with
942    this.  First, while some IMAP servers are built on Unix or PC file
943    systems, many others are not, and the file system semantics do not
944    make sense in those configurations.  Second, while some IMAP servers
945    expose the underlying file system to the clients, others allow access
946    only to the user's personal mailboxes, or to some other limited set
947    of files, making such file-system-like semantics less meaningful.
948    Third, because the IMAP spec leaves the interpretation of the
949    reference name as "implementation-dependent", in the past the various
950    server implementations handled it in vastly differing ways.
951
952
953
954 Leiba                        Informational                     [Page 17]
955 \f
956 RFC 2683          IMAP4 Implementation Recommendations    September 1999
957
958
959    The following recommendations are the result of significant
960    operational experience, and are intended to maximize
961    interoperability.
962
963    Server implementations must implement the reference argument in a way
964    that matches the intended "change directory" operation as closely as
965    possible.  As a minimum implementation, the reference argument may be
966    prepended to the mailbox name (while suppressing double delimiters;
967    see the next paragraph).  Even servers that do not provide a way to
968    break out of the current hierarchy (see "breakout facility" below)
969    must provide a reasonable implementation of the reference argument,
970    as described here, so that they will interoperate with clients that
971    use it.
972
973    Server implementations that prepend the reference argument to the
974    mailbox name should insert a hierarchy delimiter between them, and
975    must not insert a second if one is already present:
976
977        C: A001 LIST ABC DEF
978        S: * LIST () "/" ABC/DEF   <=== should do this
979        S: A001 OK done
980
981        C: A002 LIST ABC/ /DEF
982        S: * LIST () "/" ABC//DEF     <=== must not do this
983        S: A002 OK done
984
985    On clients, the reference argument is chiefly used to implement a
986    "breakout facility", wherein the user may directly access a mailbox
987    outside the "current directory" hierarchy.  Client implementations
988    should have an operational mode that does not use the reference
989    argument.  This is to interoperate with older servers that did not
990    implement the reference argument properly.  While it's a good idea to
991    give the user access to a breakout facility, clients that do not
992    intend to do so should not use the reference argument at all.
993
994    Client implementations should always place a trailing hierarchy
995    delimiter on the reference argument.  This is because some servers
996    prepend the reference argument to the mailbox name without inserting
997    a hierarchy delimiter, while others do insert a hierarchy delimiter
998    if one is not already present.  A client that puts the delimiter in
999    will work with both varieties of server.
1000
1001    Client implementations that implement a breakout facility should
1002    allow the user to choose whether or not to use a leading hierarchy
1003    delimiter on the mailbox argument.  This is because the handling of a
1004    leading mailbox hierarchy delimiter also varies from server to
1005    server, and even between different mailstores on the same server.  In
1006    some cases, a leading hierarchy delimiter means "discard the
1007
1008
1009
1010 Leiba                        Informational                     [Page 18]
1011 \f
1012 RFC 2683          IMAP4 Implementation Recommendations    September 1999
1013
1014
1015    reference argument" (implementing the intended breakout facility),
1016    thus:
1017
1018        C: A001 LIST ABC/ /DEF
1019        S: * LIST () "/" /DEF
1020        S: A001 OK done
1021
1022    In other cases, however, the two are catenated and the extra
1023    hierarchy delimiter is discarded, thus:
1024
1025        C: A001 LIST ABC/ /DEF
1026        S: * LIST () "/" ABC/DEF
1027        S: A001 OK done
1028
1029    Client implementations must not assume that the server supports a
1030    breakout facility, but may provide a way for the user to use one if
1031    it is available.  Any breakout facility should be exported to the
1032    user interface.  Note that there may be other "breakout" characters
1033    besides the hierarchy delimiter (for instance, UNIX filesystem
1034    servers are likely to use a leading "~" as well), and that their
1035    interpretation is server-dependent.
1036
1037 3.4.10.   Mailbox Hierarchy Delimiters
1038
1039    The server's selection of what to use as a mailbox hierarchy
1040    delimiter is a difficult one, involving several issues: What
1041    characters do users expect to see?  What characters can they enter
1042    for a hierarchy delimiter if it is desired (or required) that the
1043    user enter it?  What character can be used for the hierarchy
1044    delimiter, noting that the chosen character can not otherwise be used
1045    in the mailbox name?
1046
1047    Because some interfaces show users the hierarchy delimiters or allow
1048    users to enter qualified mailbox names containing them, server
1049    implementations should use delimiter characters that users generally
1050    expect to see as name separators.  The most common characters used
1051    for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
1052    file names), and "." (as in news groups).  There is little to choose
1053    among these apart from what users may expect or what is dictated by
1054    the underlying file system, if any.  One consideration about using
1055    "\" is that it's also a special character in the IMAP protocol. While
1056    the use of other hierarchy delimiter characters is permissible, A
1057    DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
1058    server is intended for special purposes only.  Implementers might be
1059    thinking about using characters such as "-", "_", ";", "&", "#", "@",
1060    and "!", but they should be aware of the surprise to the user as well
1061    as of the effect on URLs and other external specifications (since
1062    some of these characters have special meanings there).  Also, a
1063
1064
1065
1066 Leiba                        Informational                     [Page 19]
1067 \f
1068 RFC 2683          IMAP4 Implementation Recommendations    September 1999
1069
1070
1071    server that uses "\" (and clients of such a server) must remember to
1072    escape that character in quoted strings or to send literals instead.
1073    Literals are recommended over escaped characters in quoted strings in
1074    order to maintain compatibility with older IMAP versions that did not
1075    allow escaped characters in quoted strings (but check the grammar to
1076    see where literals are allowed):
1077
1078        C: 001 LIST "" {13}
1079        S: + send literal
1080        C: this\%\%\%\h*
1081        S: * LIST () "\\" {27}
1082        S: this\is\a\mailbox\hierarchy
1083        S: 001 OK LIST complete
1084
1085    In any case, a server should not use normal alpha-numeric characters
1086    (such as "X" or "0") as delimiters; a user would be very surprised to
1087    find that "EXPENDITURES" actually represented a two-level hierarchy.
1088    And a server should not use characters that are non-printable or
1089    difficult or impossible to enter on a standard US keyboard.  Control
1090    characters, box-drawing characters, and characters from non-US
1091    alphabets fit into this category.  Their use presents
1092    interoperability problems that are best avoided.
1093
1094    The UTF-7 encoding of mailbox names also raises questions about what
1095    to do with the hierarchy delimiters in encoded names: do we encode
1096    each hierarchy level and separate them with delimiters, or do we
1097    encode the fully qualified name, delimiters and all?  The answer for
1098    IMAP is the former: encode each hierarchy level separately, and
1099    insert delimiters between.  This makes it particularly important not
1100    to use as a hierarchy delimiter a character that might cause
1101    confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
1102
1103    To repeat: a server should use "/", "\", or "." as its hierarchy
1104    delimiter.  The use of any other character is likely to cause
1105    problems and is STRONGLY DISCOURAGED.
1106
1107 3.4.11.   ALERT Response Codes
1108
1109    The protocol spec is very clear on the matter of what to do with
1110    ALERT response codes, and yet there are many clients that violate it
1111    so it needs to be said anyway: "The human-readable text contains a
1112    special alert that must be presented to the user in a fashion that
1113    calls the user's attention to the message."  That should be clear
1114    enough, but I'll repeat it here: Clients must present ALERT text
1115    clearly to the user.
1116
1117
1118
1119
1120
1121
1122 Leiba                        Informational                     [Page 20]
1123 \f
1124 RFC 2683          IMAP4 Implementation Recommendations    September 1999
1125
1126
1127 3.4.12.   Deleting Mailboxes
1128
1129    The protocol does not guarantee that a client may delete a mailbox
1130    that is not empty, though on some servers it is permissible and is,
1131    in fact, much faster than the alternative or deleting all the
1132    messages from the client.  If the client chooses to try to take
1133    advantage of this possibility it must be prepared to use the other
1134    method in the even that the more convenient one fails.  Further, a
1135    client should not try to delete the mailbox that it has selected, but
1136    should first close that mailbox; some servers do not permit the
1137    deletion of the selected mailbox.
1138
1139    That said, a server should permit the deletion of a non-empty
1140    mailbox; there's little reason to pass this work on to the client.
1141    Moreover, forbidding this prevents the deletion of a mailbox that for
1142    some reason can not be opened or expunged, leading to possible
1143    denial-of-service problems.
1144
1145    Example:
1146
1147        [User tells the client to delete mailbox BANANA, which is
1148        currently selected...]
1149        C: 008 CLOSE
1150        S: 008 OK done
1151        C: 009 DELETE BANANA
1152        S: 009 NO Delete failed; mailbox is not empty.
1153        C: 010 SELECT BANANA
1154        S: * ... untagged SELECT responses
1155        S: 010 OK done
1156        C: 011 STORE 1:* +FLAGS.SILENT \DELETED
1157        S: 011 OK done
1158        C: 012 CLOSE
1159        S: 012 OK done
1160        C: 013 DELETE BANANA
1161        S: 013 OK done
1162
1163 3.5.   A Word About Testing
1164
1165    Since the whole point of IMAP is interoperability, and since
1166    interoperability can not be tested in a vacuum, the final
1167    recommendation of this treatise is, "Test against EVERYTHING."  Test
1168    your client against every server you can get an account on.  Test
1169    your server with every client you can get your hands on.  Many
1170    clients make limited test versions available on the Web for the
1171    downloading.  Many server owners will give serious client developers
1172    guest accounts for testing.  Contact them and ask.  NEVER assume that
1173    because your client works with one or two servers, or because your
1174    server does fine with one or two clients, you will interoperate well
1175
1176
1177
1178 Leiba                        Informational                     [Page 21]
1179 \f
1180 RFC 2683          IMAP4 Implementation Recommendations    September 1999
1181
1182
1183    in general.
1184
1185    In particular, in addition to everything else, be sure to test
1186    against the reference implementations: the PINE client, the
1187    University of Washington server, and the Cyrus server.
1188
1189    See the following URLs on the web for more information here:
1190
1191        IMAP Products and Sources: http://www.imap.org/products.html
1192        IMC MailConnect: http://www.imc.org/imc-mailconnect
1193
1194 4. Security Considerations
1195
1196    This document describes behaviour of clients and servers that use the
1197    IMAP4 protocol, and as such, has the same security considerations as
1198    described in [RFC-2060].
1199
1200 5. References
1201
1202    [RFC-2060]  Crispin, M., "Internet Message Access Protocol - Version
1203                4rev1", RFC 2060, December 1996.
1204
1205    [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
1206                Requirement Levels", BCP 14, RFC 2119, March 1997.
1207
1208    [RFC-2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
1209                2180, July 1997.
1210
1211    [UTF-8]     Yergeau, F., " UTF-8, a transformation format of Unicode
1212                and ISO 10646", RFC 2044, October 1996.
1213
1214    [UTF-7]     Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
1215                Transformation Format of Unicode", RFC 2152, May 1997.
1216
1217    [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
1218                Progress.
1219
1220 6. Author's Address
1221
1222    Barry Leiba
1223    IBM T.J. Watson Research Center
1224    30 Saw Mill River Road
1225    Hawthorne, NY  10532
1226
1227    Phone: 1-914-784-7941
1228    EMail: leiba@watson.ibm.com
1229
1230
1231
1232
1233
1234 Leiba                        Informational                     [Page 22]
1235 \f
1236 RFC 2683          IMAP4 Implementation Recommendations    September 1999
1237
1238
1239 7. Full Copyright Statement
1240
1241    Copyright (C) The Internet Society (1999).  All Rights Reserved.
1242
1243    This document and translations of it may be copied and furnished to
1244    others, and derivative works that comment on or otherwise explain it
1245    or assist in its implementation may be prepared, copied, published
1246    and distributed, in whole or in part, without restriction of any
1247    kind, provided that the above copyright notice and this paragraph are
1248    included on all such copies and derivative works.  However, this
1249    document itself may not be modified in any way, such as by removing
1250    the copyright notice or references to the Internet Society or other
1251    Internet organizations, except as needed for the purpose of
1252    developing Internet standards in which case the procedures for
1253    copyrights defined in the Internet Standards process must be
1254    followed, or as required to translate it into languages other than
1255    English.
1256
1257    The limited permissions granted above are perpetual and will not be
1258    revoked by the Internet Society or its successors or assigns.
1259
1260    This document and the information contained herein is provided on an
1261    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1262    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1263    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1264    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1265    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1266
1267 Acknowledgement
1268
1269    Funding for the RFC Editor function is currently provided by the
1270    Internet Society.
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Leiba                        Informational                     [Page 23]
1291 \f