RFC 2449

POP3 Extension Mechanism

📅 published November 1998, from ietf

POP3 Extension Mechanism 💖

Okay bestie, this is RFC 2449 and it's giving "POP3 finally gets a capability list" energy 🎀

  • RFC number: 2449
  • Stream: Network Working Group
  • Authors: R. Gellens (Qualcomm), C. Newman (Innosoft), L. Lundblade (Qualcomm)
  • Category: Standards Track
  • Date: November 1998
  • Updates: RFC 1939

Status of This Memo 📜

This doc is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (1998). All Rights Reserved.

IESG Note 🙈

So this extension is meant to be used by a server to express policy decisions made by the server administrator. It is not an endorsement of implementations of further POP3 extensions in general 💅 The general vibe is that POP3 should stay simple, with the simple purpose of downloading email from a mail server. If you need more complicated operations, the IMAP protocol [RFC 2060] should be used. And the first paragraph of section 7 should be read very carefully, no skipping 👀

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Conventions Used in this Document . . . . . . . . . . . . .   3
3.  General Command and Response Grammar . . . . . . . . . . . .  3
4.  Parameter and Response Lengths  . . . . . . . . . . . . . .   4
5.  The CAPA Command . . . . . . . . . . . . . . . . . . . . . .  4
6.  Initial Set of Capabilities . . . . . . . . . . . . . . . .   5
  6.1.  TOP capability . . . . . . . . . . . . . . . . . . . . .  6
  6.2.  USER capability . . . . . . . . . . . . . . . . . . . .   6
  6.3.  SASL capability  . . . . . . . . . . . . . . . . . . . .  7
  6.4.  RESP-CODES capability . . . . . . . . . . . . . . . . .   8
  6.5.  LOGIN-DELAY capability . . . . . . . . . . . . . . . . .  8
  6.6.  PIPELINING capability . . . . . . . . . . . . . . . . .   9
  6.7.  EXPIRE capability  . . . . . . . . . . . . . . . . . . . 10
  6.8.  UIDL capability . . . . . . . . . . . . . . . . . . . .  13
  6.9.  IMPLEMENTATION capability  . . . . . . . . . . . . . . . 13
7.  Future Extensions to POP3 . . . . . . . . . . . . . . . . .  14
8.  Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
  8.1.  Initial POP3 response codes . . . . . . . . . . . . . .  15
    8.1.1.  The LOGIN-DELAY response code  . . . . . . . . . . . 15
    8.1.2.  The IN-USE response code  . . . . . . . . . . . . .  16
9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
10.  Security Considerations . . . . . . . . . . . . . . . . . .  17
11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 17
12.  References  . . . . . . . . . . . . . . . . . . . . . . . .  17
13.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  18
14.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 19

1. Introduction 🧚

The Post Office Protocol version 3 [POP3] is seriously popular. It does include some optional commands (and some useful protocol extensions have been published), but it has no way to advertise support for those extensions or for behavior variations 🥺

Right now these optional features can only be found by probing, if at all. That's at best inefficient, and possibly worse 💀 So some clients ended up with manual configuration options for POP3 server capabilities.

POP3's biggest selling point is its simplicity, so extensions should be few in number (see section 7). Some extensions are still necessary, though, like ones that provide improved security [POP-AUTH], and others are really desirable in certain situations. A way to discover server behavior is needed too ✨

This memo updates RFC 1939 [POP3] to define a mechanism for announcing support for optional commands, extensions, and unconditional server behavior 🦋 It includes an initial set of currently deployed capabilities that vary between server implementations, plus several new ones: SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION. It also extends POP3 error messages so that machine parsable codes can be given to the client, with an initial set of response codes included. And there's an [ABNF] specification of POP3 commands and responses defined here too 🫶

Public comments should go to the IETF POP3 Extensions mailing list, <ietf-pop3ext@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-pop3ext-request@imc.org> 💌

2. Conventions Used in this Document 📏

The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].

In examples, "C:" and "S:" mark lines sent by the client and the server respectively 🍓

3. General Command and Response Grammar 🧩

The general form of POP3 commands and responses is written out using [ABNF]:

POP3 commands:

   command      =  keyword *(SP param) CRLF    ;255 octets maximum
   keyword      =  3*4VCHAR
   param        =  1*VCHAR

POP3 responses:

   response     =  greeting / single-line / capa-resp / multi-line
   capa-resp    =  single-line *capability "." CRLF
   capa-tag     =  1*cchar
   capability   =  capa-tag *(SP param) CRLF   ;512 octets maximum
   cchar        =  %x21-2D / %x2F-7F
                       ;printable ASCII, excluding "."
   dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed
   gchar        =  %x21-3B / %x3D-7F
                       ;printable ASCII, excluding "<"
   greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
                       ;512 octets maximum
   multi-line   =  single-line *dot-stuffed "." CRLF
   rchar        =  %x21-2E / %x30-5C / %x5E-7F
                       ;printable ASCII, excluding "/" and "]"
   resp-code    =  "[" resp-level *("/" resp-level) "]"
   resp-level   =  1*rchar
   schar        =  %x21-5A / %x5C-7F
                       ;printable ASCII, excluding "["
   single-line  =  status [SP text] CRLF       ;512 octets maximum
   status       =  "+OK" / "-ERR"
   text         =  *schar / resp-code *CHAR
   timestamp    =  "<" *VCHAR ">"
                       ;MUST conform to RFC-822 msg-id

4. Parameter and Response Lengths 📐

This spec loosens the length limits on commands and parameters that RFC 1939 had set 💅

The maximum command length goes up from 47 characters (a 4 character command, a single space, a 40 character argument, and CRLF) to 255 octets, counting the terminating CRLF.

Servers that support the CAPA command MUST support commands up to 255 octets. Servers MUST also support the largest maximum command length specified by any supported capability 🔥

The maximum length of the first line of a command response (including the initial greeting) stays the same at 512 octets, again including the terminating CRLF.

5. The CAPA Command 🎀

The POP3 CAPA command returns the list of capabilities that the POP3 server supports. It's available in both the AUTHORIZATION and TRANSACTION states ✨

A capability description MUST document which states the capability is announced in, and which states its commands are valid in.

Capabilities available in the AUTHORIZATION state MUST be announced in both states.

If a capability is announced in both states but its argument might differ after authentication, that possibility MUST be stated in the capability description.

(These rules mean a client can get away with issuing only one CAPA command, as long as it doesn't use any TRANSACTION-only capabilities or any capabilities whose values might change after authentication 🧠)

If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating, to check for active down-negotiation attacks 🚨

Each capability may enable additional protocol commands, additional parameters and responses for existing commands, or describe an aspect of server behavior. The details are spelled out in each capability's description 🌸

Section 3 describes the CAPA response using [ABNF]. When a capability response describes an optional command, the <capa-tag> SHOULD be identical to the command keyword. CAPA response tags are case-insensitive 🧚

Here's the CAPA command itself:

CAPA

Arguments:
    none

Restrictions:
    none

Discussion:
    An -ERR response indicates the capability command is not
    implemented and the client will have to probe for
    capabilities as before.

    An +OK response is followed by a list of capabilities, one
    per line.  Each capability name MAY be followed by a single
    space and a space-separated list of parameters.  Each
    capability line is limited to 512 octets (including the
    CRLF).  The capability list is terminated by a line
    containing a termination octet (".") and a CRLF pair.

 Possible Responses:
     +OK -ERR

 Examples:
     C: CAPA
     S: +OK Capability list follows
     S: TOP
     S: USER
     S: SASL CRAM-MD5 KERBEROS_V4
     S: RESP-CODES
     S: LOGIN-DELAY 900
     S: PIPELINING
     S: EXPIRE 60
     S: UIDL
     S: IMPLEMENTATION Shlemazle-Plotz-v302
     S: .

6. Initial Set of Capabilities 🌈

This section defines the first batch of POP3 capabilities. That covers the optional POP3 commands, extensions that are already published, and behavior differences between POP3 servers that can affect clients 💜

Quick heads up on APOP: there is no APOP capability, even though APOP is an optional command in [POP3]. Clients figure out whether a server supports APOP from the presence of an initial challenge in angle brackets ("<>") in the greeting banner. So an APOP capability would give a server two ways to announce the same thing, which is just messy 🙃

6.1. TOP capability 🔝

Here's the TOP capability. It just says the optional TOP command is available 🎀

CAPA tag:
    TOP

Arguments:
    none

Added commands:
    TOP

Standard commands affected:
    none

Announced states / possible differences:
    both / no

Commands valid in states:
    TRANSACTION

Specification reference:
    [POP3]

Discussion:
    The TOP capability indicates the optional TOP command is
    available.

6.2. USER capability 👤

Next up is the USER capability. It says the USER and PASS commands are supported, though they might not be available to every user 💅

CAPA tag:
    USER

Arguments:
    none

Added commands:
    USER PASS

Standard commands affected:
    none

Announced states / possible differences:
    both / no

Commands valid in states:
    AUTHENTICATION

Specification reference:
    [POP3]

Discussion:
    The USER capability indicates that the USER and PASS commands
    are supported, although they may not be available to all users.

6.3. SASL capability ✨

CAPA tag:
    SASL

Arguments:
    Supported SASL mechanisms

Added commands:
    AUTH

Standard commands affected:
    none

Announced states / possible differences:
    both / no

Commands valid in states:
    AUTHENTICATION

Specification reference:
    [POP-AUTH, SASL]

Okay so the POP3 AUTH command [POP-AUTH] lets you use [SASL] authentication mechanisms with POP3 🔐 bestie. This capability tells you AUTH is available and that it takes an optional base64 encoded second argument for an initial client response, just like the SASL spec describes. The argument is a space separated list of the SASL mechanisms the server supports 🦋

6.4. RESP-CODES capability 🎀

CAPA tag:
    RESP-CODES

Arguments:
    none

Added commands:
    none

Standard commands affected:
    none

Announced states / possible differences:
    both / no

Commands valid in states:
    n/a

Specification reference:
    this document

This one is so simple but so useful 🥹 If the server announces RESP-CODES, any response text it sends that starts with an open square bracket ("[") is an extended response code (see section 8). So when you see a bracket at the front, you know it's a code and not just random words 🧚

6.5. LOGIN-DELAY capability ⏳

CAPA tag:
    LOGIN-DELAY

Arguments:
    minimum seconds between logins; optionally followed by USER in
    AUTHENTICATION state.

Added commands:
    none

Standard commands affected:
    USER PASS APOP AUTH

Announced states / possible differences:
    both / yes

Commands valid in states:
    n/a

Specification reference:
    this document

POP3 clients keep checking for new mail constantly, and ngl that's kind of a lot 😭 Making a connection, logging the user in, and opening their maildrop is super resource intensive on the server, so a bunch of POP3 servers out there make you wait between logins to ease the load 💅 This capability has an integer argument for how many seconds have to pass after an "+OK" reply to a PASS, APOP, or AUTH command before the server will accept another authentication.

Clients that let the user set a mail check interval SHOULD use this capability to find the smallest interval they're allowed to use 🫶 Servers that advertise LOGIN-DELAY SHOULD enforce it, no excuses.

Now here's the tricky part 👀 The minimum delay could be different for each user, meaning the LOGIN-DELAY argument might change after authentication. If that's the case, the server MUST announce, in AUTHENTICATION state, the largest value that could be set for any user. That might be the largest value in use for any user right now (so only one value per server), or even the largest value the server lets anyone have. Then the server SHOULD tack the token USER onto the LOGIN-DELAY parameter in AUTHENTICATION state, so the client knows a more accurate value is coming after login. The server SHOULD announce that more accurate value in TRANSACTION state. (The USER token is what lets the client decide whether it needs a second CAPA command, which is honestly so clever 🧠✨)

Servers enforce LOGIN-DELAY by rejecting an authentication command, with or without the LOGIN-DELAY error response. See section 8.1.1 for more information.

6.6. PIPELINING capability 🚀

CAPA tag:
    PIPELINING

Arguments:
    none

Added commands:
    none

Standard commands affected:
    all

Announced states / possible differences:
    both / no

Commands valid in states:
    n/a

Specification reference:
    this document

PIPELINING means the server can take in several commands at once, so the client doesn't have to sit around waiting for the reply to one command before sending the next one 🏃‍♀️💨 If a server supports PIPELINING, it MUST process each command in turn. If a client uses PIPELINING, it MUST keep track of which commands are still waiting on a reply, and match each server response to its command in order. If either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer. Tea. Spill. Remember those limits 🫠

Some POP3 clients have a setting for "Overlapped POP3 commands." This capability means the client doesn't have to be configured for it manually, which is such a relief 🙌

This is basically the same idea as the ESMTP PIPELINING extension [PIPELINING]. But SMTP [SMTP] tends to have short commands and responses, so the win there is bundling a bunch of commands together and sending them as one chunk. POP can do that too. USER and PASS could be batched, and multiple RETR and/or DELE commands could be sent as a group 📦 But POP has short commands and sometimes really long responses, so there's also a big perk in sending new commands while you're still receiving the response to an earlier one. For example, you can send RETR and/or DELE commands while the UIDL reply is still being processed 🧃

6.7. EXPIRE capability 🗓️

CAPA tag:
    EXPIRE

Arguments:
    server-guaranteed minimum retention days, or NEVER; optionally
    followed by USER in AUTHENTICATION state

Added commands:
    none

Standard commands affected:
    none

Announced states / possible differences:
    both / yes

Commands valid in states:
    n/a

Specification reference:
    this document

POP3 lets clients leave messages on the server, but RFC 1939 [POP3] warns that this can cause problems, and lets servers delete messages based on site policy 🫣 The EXPIRE capability fixes that drama by letting the server tell the client what policy is in effect 💖 The argument is the minimum number of days messages stay on the server.

EXPIRE 0 means the client is not allowed to leave mail on the server. When the session enters the UPDATE state, the server MAY assume an implicit DELE for each message that was downloaded with RETR. Harsh, but clear 💀

EXPIRE NEVER means the server does not delete messages. Iconic behavior 👑

The idea of a "retention period" is intentionally a little vague 🌫️ Servers might start counting days to expiration when a message lands in a maildrop, when a client first finds out about a message through the LIST or UIDL commands, when a message has been acted on in some way (for example, TOP or RETR), or at some other event. So EXPIRE can't tell you exactly when any given message will expire. It just helps clients behave in ways that match site policy and what the user wants. For example, a client might show a warning when someone tries to set a "leave mail on server" period that's greater than or equal to some percentage of the value the server announced 🚨

If a site uses any automatic deletion policy, it SHOULD use the EXPIRE capability to announce that. An EXPIRE value other than 0 or NEVER tells the client that the server does permit mail to be left on it, and gives the smallest value that might be in force 🌸

Sites that let users keep messages indefinitely SHOULD announce this with the EXPIRE NEVER response.

If the expiration policy differs per user (meaning the EXPIRE argument might change after authentication), the server MUST announce, in AUTHENTICATION state, the smallest value that could be set for any user. That might be the smallest value in use for any user right now (so only one value per server), or even the smallest value the server permits for any user. The server SHOULD append the token USER to the EXPIRE parameter in AUTHENTICATION state, so the client knows a more accurate value can be obtained after authentication. The server SHOULD announce the more accurate value in TRANSACTION state. (Same deal as LOGIN-DELAY: the USER token lets the client decide whether a second CAPA command is needed or not.)

A site might have an expiration policy that treats messages differently depending on what the user has done with them, or based on other factors. For example, a site might delete unseen messages after 60 days, and completely- or partially-seen messages after 15 days 👀

The announced EXPIRE value is the smallest retention period that is or might be used by any category or condition of the current site policy. In AUTHENTICATION state that's for any user, and in TRANSACTION state it's for the specific user. Basically, EXPIRE tells the client the minimum number of days messages may stay on the server under any circumstances 📆

Examples:

EXPIRE 5 USER
EXPIRE 30
EXPIRE NEVER
EXPIRE 0

The first example says the server might delete messages after five days, but the period differs per user, so a more accurate value can be grabbed by issuing a second CAPA command in TRANSACTION state. The second example says the server could delete messages after 30 days. In the third example, the server announces that it does not delete messages. The fourth example means the site does not permit messages to be left on the server at all 🫶

6.8. UIDL capability 🧾

CAPA tag:
    UIDL

Arguments:
    none

Added commands:
    UIDL

Standard commands affected:
    none

Announced states / possible differences:
    both / no

Commands valid in states:
    TRANSACTION

Specification reference:
    [POP3]

Short and sweet 💕 The UIDL capability tells you the optional UIDL command is supported.

6.9. IMPLEMENTATION capability 🪪

CAPA tag:
    IMPLEMENTATION

Arguments:
    string giving server implementation information

Added commands:
    none

Standard commands affected:
    none

Announced states / possible differences:
    both (optionally TRANSACTION only) / no

Commands valid in states:
    n/a

Specification reference:
    this document

It's really handy to know exactly which server implementation you're talking to, like when you're logging stuff 📝 People usually put that in the welcome banner, but then you have to guess whether a string is an implementation ID or just a random message 🙃

The argument to the IMPLEMENTATION capability is one or more tokens that identify the server. (Since CAPA response tag arguments are space-separated, it might be easier if the IMPLEMENTATION argument has no spaces, so it's one single token 🧩)

Normally, servers announce IMPLEMENTATION in both states. However, a server MAY choose to do so only in TRANSACTION state.

A server MAY include the implementation identification both in the welcome banner and in the IMPLEMENTATION capability.

Clients MUST NOT modify their behavior based on the server implementation. Instead, the server and client should agree on a private extension 🔒✨

7. Future Extensions to POP3 ✨

Okay so, future extensions to POP3 are generally discouraged, bestie 🥺 because POP3's whole thing is being simple. It's meant to be a download-and-delete protocol, and if you want full mail access, that's literally what IMAP [IMAP4] is for 💅. Extensions that add support for extra mailboxes, let you upload messages to the server, or stray from POP's download-and-delete model are strongly discouraged 😭 and unlikely to be permitted on the IETF standards track 💀.

Clients MUST NOT require any extension for basic functionality, except the authentication commands (APOP, AUTH [section 6.3] and USER/PASS) 🔐.

Section 9 explains how additional capabilities get defined 🧚.

8. Extended POP3 Response Codes 💖

Plain POP3 is basically just "yes" or "no" for most commands 🙃. But clients really need to know why something failed so they can recover gracefully 🫶. This matters most for a failed login. There are super popular clients that parse the error text of a PASS result to tell "unable to get maildrop lock" apart from "bad login" 👀 iykyk.

This spec amends POP3 so a response can start with an optional response code in square brackets, right at the beginning of the human-readable text of an "+OK" or "-ERR" reply. Clients that support this MAY strip anything in square brackets before showing the text to the user 🌸. The code right after the opening "[" is read in a case-insensitive way by the client 🦋.

The response code is hierarchical, with a "/" separating levels of detail about the error. Clients MUST ignore any unknown hierarchical detail 🙅‍♀️. This is so important because future codes might need more detail, and we don't want older clients breaking 🥹.

Section 3 describes response codes using [ABNF] 📝.

If a server supports extended response codes, it says so by including the RESP-CODES capability in its CAPA response ✨.

Examples:

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?

8.1. Initial POP3 response codes 🎀

This spec defines two POP3 response codes that tell you why a login failed. Section 9 explains how more get defined 🍓.

8.1.1. The LOGIN-DELAY response code ⏰

This shows up on an -ERR reply to an AUTH, USER (see note), PASS or APOP command. It means the user logged in recently and can't log in again until the login delay period is over 🙃.

NOTE: Returning the LOGIN-DELAY response code to the USER command skips the work of authenticating the user, but it also tells the client that the specified user exists 👀. Unless the server is running somewhere user names aren't secret (like many popular email clients that advertise the POP server and user name in an outgoing mail header), or where server access is restricted, or the server can verify the connection is to the same user, it is strongly recommended that the server not issue this response code to the USER command 🙈. The server still saves the cost of opening the maildrop, which in some environments is the most expensive step 💸.

8.1.2. The IN-USE response code 🔒

This shows up on an -ERR reply to an AUTH, APOP, or PASS command. It means the authentication worked, but the user's maildrop is already in use, probably by another POP3 client 📬.

9. IANA Considerations 🗂️

This document asks IANA to maintain two new registries: POP3 capabilities and POP3 response codes 🎀.

New POP3 capabilities MUST be defined in a standards track or IESG approved experimental RFC, and MUST NOT begin with the letter "X" 🚫.

New POP3 capabilities MUST include the following information:

  • CAPA tag
  • Arguments
  • Added commands
  • Standard commands affected
  • Announced states / possible differences
  • Commands valid in states
  • Specification reference
  • Discussion

In addition, new limits for POP3 command and response lengths may need to be included 📏.

New POP3 response codes MUST be defined in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. (This is the "Specification Required" policy described in [IANA] 🧾.)

New POP3 response code specifications MUST include the complete response code, the responses (+OK or -ERR) and commands it is valid for, and a definition of its meaning and expected client behavior ✅.

10. Security Considerations 🔐💀

Okay, this part is serious, bestie 😤. A capability list can reveal information about the server's authentication mechanisms, and attackers can use that to figure out whether certain attacks will work. ⚠️ However, letting clients automatically detect stronger mechanisms and switch their configurations to use them can really improve overall security at a site 💪.

Section 8.1 discusses the security issues related to using the LOGIN-DELAY response code with the USER command 👀.

11. Acknowledgments 🙏

This document was revised in part based on comments and discussions that happened on and off the IETF POP3 Extensions mailing list 💬. Huge thanks to everyone who took the time to review this memo and make suggestions, especially Alexey Melnikov, Harald Alvestrand, and Mike Gahrns 🫶✨.

12. References 📚

[ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications:  ABNF", RFC 2234, November 1997.

[IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

[IMAP4]      Crispin, M., "Internet Message Access Protocol --
             Version 4rev1", RFC 2060, December 1996.

[KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[PIPELINING] Freed, N., "SMTP Service Extension for Command
             Pipelining", RFC 2197, September 1997.

[POP3]       Myers, J. and M. Rose, "Post Office Protocol -- Version
             3", STD 53, RFC 1939, May 1996.

[POP-AUTH]   Myers, J., "POP3 AUTHentication command", RFC 1734,
             December 1994.

[SASL]       Myers, J., "Simple Authentication and Security Layer
             (SASL)", RFC 2222, October 1997.

[SMTP]       Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
             821, August 1982.

13. Authors' Addresses 📮

Randall Gellens
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, CA  92121-2779
USA

Phone: +1 619 651 5115
Fax:   +1 619 845 7268
EMail: randy@qualcomm.com


Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA

EMail: chris.newman@innosoft.com


Laurence Lundblade
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, Ca, 92121-2779
USA

Phone: +1 619 658 3584
Fax:   +1 619 845 7268
EMail: lgl@qualcomm.com

Copyright (C) The Internet Society (1998). All Rights Reserved.

Anyone can copy and share this document and its translations, and write derivative works that comment on it, explain it, or help implement it, and publish and distribute those works in whole or in part with no restrictions at all 🌈. The only catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🔖.

The document itself can't be modified in any way, though. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations 🚫. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and translating it into languages other than English 🌍.

These permissions are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫠.
📦 where this page comes from