RFC 2971

IMAP4 ID extension

📅 published October 2000, from ietf

RFC 2971: IMAP4 ID extension 💖

Network Working Group 🎀 Request for Comments: 2971 ✨

  • Author: T. Showalter, Mirapoint, Inc. 🧚
  • Category: Standards Track 👑
  • Date: October 2000 🌸
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates 🦋

Status of this Memo ✨

okay so this document is a standards track protocol spec for the internet community 🌈 it's literally asking for discussion and suggestions for improvements 💅 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and distribution of this memo is unlimited 🫶

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract 🦋

okay this is the big idea 💖 the ID extension to the Internet Message Access Protocol, Version 4rev1 (IMAP4rev1), lets the server and client swap identification info about their implementation ✨ so bug reports and usage stats can actually be complete 🔥 it's giving "know who you're debugging" energy 💅

1. Introduction 🌸

bestie, the IMAP4rev1 protocol described in [IMAP4rev1] is how you access remote mail stores 📬 but it has zero way to say what program a client or server is actually running 😭 that's rough for implementors, because bug reports from users are frequently missing that info, and it's hard to tell which client or server is even in use 🙈

and lowkey, some sites want usage stats based on which clients people use 📊 but when users are allowed to grab and maintain their own clients, that's really hard to pull off 💀

so the ID command is the fix 💖 it lets you advertise which programs are being used, along with contact info in case something ever goes wrong 🫶

2. Conventions Used in this Document 🦋

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [KEYWORDS] 📖 these are the capital-letter rule words, so watch for them 👀

the conventions are the same as the ones in [IMAP4rev1] ✨ in examples, "C:" is for lines the client sends and "S:" is for lines the server sends 🍓 line breaks got added so it's easier to read 💜

3. Specification 👑

the whole point of the ID extension is to let clients and servers trade info about their implementations 🎀 that's it, that's the tea, for statistics and figuring out problems 📊

info can be sent to a server by any client that wants to share stats, but only if the server says it's willing to take it 🫶 the server shows that by including the atom "ID" in the list of capabilities it returns from the CAPABILITY command 🌈

⚠️ Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only, and is not to be used in improving the performance of clients or servers. no tuning your behavior off these vibes, bestie 💀

this covers a bunch of stuff, including:

  • Servers MUST NOT try to work around client bugs by using information from the ID command. Clients MUST NOT try to work around server bugs based on the ID response.
  • Servers MUST NOT give a client features or otherwise optimize for a particular client by using information from the ID command. Clients MUST NOT give a server features or otherwise optimize for a particular server based on the ID response.
  • Servers MUST NOT deny access to or refuse service to a client based on information from the ID command. Clients MUST NOT refuse to operate or limit their operation with a server based on the ID response.

Rationale: this extension absolutely can't turn into a sketchy side door that replaces IMAP's CAPABILITY mechanism 🙅‍♀️ where implementations just guess each other's features based on who they say they are 💀 that's a no from me 😤

Implementations MUST NOT send false information in an ID command. 🚫

Implementations MAY send less information than they have available, or no information at all. that can be really useful for protecting user privacy 🔒 see Security Considerations, section 7 🫶

3.1. ID Command 💅

Arguments:  client parameter list or NIL

Responses:  OPTIONAL untagged response: ID

Result:     OK    identification information accepted
            BAD   command unknown or arguments invalid

the client sends its implementation identification info with the ID command ✨ this command is valid in any state 🧚

the info goes as a list of field/value pairs 📝 fields can be any IMAP4 string, and values can be any IMAP4 string or NIL 🍓 NIL means the client can't or won't specify that info 🙈 the client can also send NIL instead of the whole list, which means it doesn't want to send anything, but it would still take a server response 💖

the available fields are defined in section 3.3 🎀

example time 🎬

C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
              "Pink Floyd Music Limited")
S: * ID NIL
S: a023 OK ID completed

3.2. ID Response 🦋

contents are a server parameter list 🌸

when the client sends an ID command, the server answers with a tagged response that has info about its own implementation 🫶 the format is the same as the client's list 💜

example 🎀

C: a042 ID NIL
S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
     "os-version" "5.5" "support-url"
     "mailto:cyrus-bugs+@andrew.cmu.edu")
S: a042 OK ID command completed

a server MUST send a tagged ID response to an ID command ✨ but a server MAY send NIL in place of the list 🌈

3.3. Defined Field Values 🧚

any string can be sent as a field 🫶 but the following ones are defined for describing certain values 📋 implementations are free to send none, any, or all of them 💅 strings are not case-sensitive 🙈

field strings MUST NOT be longer than 30 octets 📏 value strings MUST NOT be longer than 1024 octets 📏 and implementations MUST NOT send more than 30 field-value pairs 🚫

name            Name of the program
version         Version number of the program
os              Name of the operating system
os-version      Version of the operating system
vendor          Vendor of the client/server
support-url     URL to contact for support
address         Postal address of contact/vendor
date            Date program was released, specified as a date-time
                  in IMAP4rev1
command         Command used to start the program
arguments       Arguments supplied on the command line, if any
                  if any
environment     Description of environment, i.e., UNIX environment
                  variables or Windows registry settings
🚫 Implementations MUST NOT use contact information to submit automatic bug reports. Implementations may include information from an ID response in a report that gets prepared automatically, but they are prohibited from sending that report without user authorization. the user has to say yes first, always 🫶

it's preferable to find the name and version of the underlying operating system at runtime, when that's possible 🧠

info sent through an ID response may violate user privacy 😭 see Security Considerations, section 7 🔒

Implementations MUST NOT send the same field name more than once. 🚫✨

okay so this part is the legal bit, but it's giving "you can share this, just keep the credit on it" 💅 Copyright (C) The Internet Society (2000). All Rights Reserved. ✨

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. 🦋 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌸

bestie, the vibe is basically: you can copy it, you can write stuff about it and share that, but you can't edit the original and strip the credit off 🙈 the only exceptions are making internet standards (follow the standards process rules) or translating it into another language 🌈

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💜 so like, these permissions never expire and nobody can take them back, not even the Society's future owners or whoever gets their stuff 🫶

This document and the information contained herein is 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. ⭐ ngl this part is the "we're giving you this as-is and we're not promising it'll be perfect or legal for every use" disclaimer 💀

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. 👑 so the people who keep the RFC series organised get their money from the Internet Society, iykyk 🍓

📦 where this page comes from