RFC 5259
Internet Message Access Protocol - CONVERT Extension
Internet Message Access Protocol - CONVERT Extension 🦋
Network Working Group, Request for Comments 5259, from July 2008. The authors are A. Melnikov, Ed. (Isode Ltd) and P. Coates, Ed. (Sun Microsystems). It's a Standards Track doc. The title block doesn't list anything it obsoletes or updates. 💅
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸
Abstract 💖
CONVERT adds extensions to IMAP so clients can ask for attachments to be adapted and/or transcoded. Clients can spell out the conversion details, or let the server decide based on what it knows about the client's capabilities, user or admin preferences, or server settings. 🎀
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Relation with Other IMAP Specifications . . . . . . . . . . . 4
3.1. CAPABILITY Response . . . . . . . . . . . . . . . . . . . 4
4. Scope of Conversions . . . . . . . . . . . . . . . . . . . . . 4
5. Discovery of Available Conversions . . . . . . . . . . . . . . 4
5.1. CONVERSIONS Command . . . . . . . . . . . . . . . . . . . 4
5.2. CONVERSION Response . . . . . . . . . . . . . . . . . . . 6
6. CONVERT and UID CONVERT Commands . . . . . . . . . . . . . . . 6
7. CONVERT Conversion Parameters . . . . . . . . . . . . . . . . 12
7.1. Mandatory-to-Implement Conversions and Conversion
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Additional Features for Mobile Usage . . . . . . . . . . . 13
8. Request/Response Data Items to CONVERT/UID CONVERT Commands . 14
8.1. CONVERTED Untagged Response . . . . . . . . . . . . . . . 14
8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item . . . 14
8.3. BINARY.SIZE CONVERT Request and Response Item . . . . . . 15
8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item . . 16
8.5. Implementation Considerations . . . . . . . . . . . . . . 17
9. Status Responses and Response Code Extensions . . . . . . . . 17
10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Manageability Considerations . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Registration of unknown-character-replacement Media
Type Parameter . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . . 291. Introduction 🧚
This doc defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT handles adapting and transcoding of body parts when the client needs it. The client can request a conversion and the server does it on a best effort basis. Or, if the client asks, the server decides based on what it knows about the client's capabilities, user or admin preferences, or server settings. ✨
This extension is mainly for mobile clients, and it meets the requirements in [OMA-ME-RD]. 📱
A server that supports CONVERT can convert body parts into other formats so they can be viewed on something like a mobile device. The client can ask for one specific conversion, or tell the server to pick the best one it has. If the client allows it, the server decides how to convert using its own strategy (for example, based on what it knows about the client, as covered below). If the server knows the device's characteristics (which is out of scope for CONVERT), or can work them out (for example, from a conversion parameter that includes the device type), then converted body parts can also be optimized for that device, like the form factor of pictures. The client controls conversions with optional conversion parameters, which this document also calls "transcoding" parameters. 🎀
This doc relies on the registry of conversion parameters set up by [MEDIAFEAT-REG]. You can use that registry to find the legal values these parameters can take. More conversion parameters, like the ones defined by [OMA-STI], are expected to be registered later. 💜
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 [RFC2119]. 🔥
In the examples, "C:" marks lines sent by the client and "S:" marks lines sent by the server. If one "C:" or "S:" label covers several lines, the line breaks between them are just for readability and aren't part of the real protocol exchange. The five characters [...] mean that something has been left out. 🙈
When describing the general syntax, some definitions are skipped because they're already defined in [RFC3501]. In particular, "session" is used here the way Section 1.2 of [RFC3501] defines it. 💅
3. Relation with Other IMAP Specifications 🌈
Converting attachments while streaming is out of scope for CONVERT. That's covered in a separate Lemonade WG document, [LEM-STREAMING]. 🦋
A server that claims to comply with this spec MUST support the IMAP Binary specification [RFC3516]. 🫶
3.1. CAPABILITY Response 💖
A server that supports the CONVERT extension MUST return "CONVERT" and "BINARY" in the CAPABILITY response or response code. (Client and server authors, quick reminder: the order of tokens in the CAPABILITY response or response code is arbitrary. 💅)
Example: A server that implements CONVERT.
C: a000 CAPABILITY
S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...]
S: a000 OK CAPABILITY completed4. Scope of Conversions 🌸
Conversions only affect what gets sent to the client. The original data in the message store MUST NOT be altered. This document doesn't say how the server actually performs conversions. ✨
Note: Keeping the original data unaltered means other clients can still access it, replies or forwards of the original documents still work, signature verification still works (the converted body parts probably won't have any signatures), and BODYSTRUCTURE and related info stay intact. 🧠
5. Discovery of Available Conversions 🔍
5.1. CONVERSIONS Command 🎀
Arguments: source MIME type
target MIME type
Responses: untagged responses: CONVERSION
Result: OK - CONVERSIONS command completed
BAD - unrecognized syntax of an argument, unexpected extra
argument, missing argument, etc.The CONVERSIONS command is allowed in the Authenticated and Selected IMAP states. 💜
The first parameter is a source MIME type and the second is a target MIME type. Both can be wildcarded, either partially (like "text/") or completely (""). 🦋
Conversions that match the source/target pair, along with their conversion parameters, come back in untagged CONVERSION responses. If the source/target pair doesn't match any conversion the server supports, then no CONVERSION response comes back. 🙈
Examples:
For conversion info from GIF to JPEG (if no conversion is possible, no untagged CONVERSION response comes back):
C: a CONVERSIONS "image/gif" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: a OK CONVERSIONS completedFor conversion info from GIF to anything:
C: b CONVERSIONS "image/gif" "*"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/gif" "image/png" ([...])
[...]
S: b OK CONVERSIONS completedFor conversion of anything to JPEG:
C: c CONVERSIONS "*" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/png" "image/jpeg" (...)
[...]
S: c OK CONVERSIONS completedFor conversions from all image formats to all text formats, the client can send this:
C: d CONVERSIONS "image/*" "text/*"5.2. CONVERSION Response 🌟
Contents: source MIME type
target MIME type
optional list of supported conversion parametersWhen a CONVERSIONS command runs, the server can send back one or more CONVERSION responses. Each CONVERSION response says which source MIME type can be converted to which target MIME type, and lists the conversion parameters it supports. 👑
6. CONVERT and UID CONVERT Commands ✨
Arguments: sequence set
conversion parameters
CONVERT data item names
Responses: untagged responses: CONVERTED
Result: OK - convert completed
NO - convert error: can't fetch and/or convert that data
BAD - unrecognized syntax of an argument, unexpected extra
argument, missing argument, etc.okay bestie, this is where the CONVERT commands come in and absolutely slay 💅✨ The CONVERT extension adds CONVERT and UID CONVERT commands that transcode a MIME part into a different media type, and/or the same media type with different encoding parameters 🦋 They're built a lot like FETCH and UID FETCH (as extended by [RFC3516]) so if you already know those, you're basically set 💜
- A successful CONVERT or UID CONVERT command gets back one or more untagged CONVERTED responses, one per message 📬 They're giving FETCH responses vibes. Heads up: one CONVERT/UID CONVERT command can only do ONE type of conversion, as set by the conversion parameters 🙅♀️ So if a client needs several different conversions, it has to send several CONVERT/UID CONVERT commands. Such a client MAY pipeline them 🧚
BINARY[...]asks for a body part (or the whole message) to be converted using the conversion parameters, and wants the converted message or body part back as binary 📦BINARY.SIZEis like RFC822.SIZE, except it tells you the size of the converted body part or message 📏BODYPARTSTRUCTUREis like the BODYSTRUCTURE FETCH data item, but it gives you the MIME structure of the converted body part 🌈BODY[...HEADER]converts the encoded words in the requested headers into the specified charset. The CHARSET parameter is REQUIRED for this conversion 🎀BODY[...MIME]also converts encoded words in the requested headers into the specified charset. The CHARSET parameter is REQUIRED for this conversion too 💖AVAILABLECONVERSIONSasks for the list of target MIME types that the body part (or the whole message) can be converted to 📋
The CONVERT extension also adds one new response code. See Section 9 for more details 🔥
Typically clients will ask for conversion of leaf body parts 🍓 Servers CAN also offer conversion of non-leaf body parts (like converting from multipart/related), and they MAY do that 🌸
Here's a fun one 🎀 Instead of naming the exact target media type, the client MAY send the special marker NIL (aka "default conversion") and let the server pick a suitable one 🧚 This doc doesn't spell out how the server makes that choice, but there are some basic guidelines, ngl 🙈 If the server knows the device's characteristics, either in-band (like a device type in a conversion parameter) or out-of-band, it should convert to a media type the device is likely to support and display or play successfully 📱 Unless a conversion parameter overrides it, the server MAY also strip out any unnecessary detail that's beyond what the device can handle, like scaling an image to just fit the screen 🖼️ If there's no in-band or out-of-band way to figure out the device's characteristics, the server should convert to the most standard or widely deployed media type in that category, like text/plain or image/jpeg 📄 and it should minimize quality loss 🫶 Servers are REQUIRED to support "default conversion" requests 👑 Server implementations that support conversions to multiple target MIME types SHOULD make the default conversion configurable ⚙️ Clients SHOULD avoid default conversion unless they've got a way (in-band or out-of-band) to tell the server what they can do, because there's no guarantee the server will guess their capabilities right 😭 Client implementors should consider using the AVAILABLECONVERSIONS CONVERT data item or the CONVERSIONS command instead 🦋
CONVERT's command syntax is modeled on the FETCH command syntax in [RFC3501], as extended by [RFC3516] 💅 CONVERT data items are generally shaped like this:
BINARY[section-part]<partial>
BINARY.SIZE[section-part]
BODYPARTSTRUCTURE[section-part]
BODY[HEADER]
BODY[section-part.HEADER]
BODY[section-part.MIME]
AVAILABLECONVERSIONS[section-part]A partial CONVERT BINARY[...] works the same way as a partial FETCH BODY[...], with one twist: the <partial> arguments refer to the TRANSCODED and DECODED section data 🧩
Plot twist 🙀 Unlike FETCH, the CONVERT command NEVER sets the \Seen flag on converted messages. If a client wants to mark a message with \Seen, it needs to send a STORE command (it can pipeline that with the CONVERT request) 👀
UID CONVERT is different from CONVERT in the same way UID FETCH is different from FETCH:
- UID CONVERT takes a sequence of UIDs instead of a sequence of message numbers 🔢
- The UID CONVERT command MUST result in the UID data item appearing in a corresponding CONVERTED response 🆔
- An EXPUNGE response MUST NOT be sent while responding to a CONVERT command 🚫 This rule exists to stop the client and server from losing sync on message sequence numbers 🧠 An EXPUNGE response MAY be sent during a UID CONVERT command though 💜
Example: the client fetches body part section 3 in the message with message sequence number 2, and asks for that attachment to be converted to PDF 📄✨
C: a001 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: * 2 CONVERTED (TAG "a001") (BINARY[3] {2135}
<the document in .pdf format>
)
S: a001 OK CONVERT COMPLETEDExample: the client asks for a text/html body part to be converted to text/plain, with a charset of us-ascii. The server can't honour the charset request because the text/html body part has non-us-ascii characters in it 🙃 So it fails the request by returning an ERROR phrase in place of the converted data (see Section 9) 💀
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3]
S: * 2 CONVERTED (tag "b001") (BINARY[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii")))
S: b001 NO All conversions failedIf the client also specified the "unknown-character-replacement" conversion parameter (see Section 12.1), the same example can look like this 🎀
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii"
"unknown-character-replacement" "?")) BINARY[3]
S: * 2 CONVERTED (TAG "b001") (BINARY[3] {2135}
<the document in text/plain format with us-ascii
charset>
)
S: b001 OK CONVERT COMPLETEDThe server replaced the non-us-ascii characters with a us-ascii character, like "?" 🔄✨
Example: the client first asks for the converted size of a text/html body part converted to text/plain 📏
C: c000 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii"))
BINARY.SIZE[4]
S: * 2 CONVERTED (TAG "c000") (BINARY.SIZE[4] 3135)
S: c000 OK CONVERT COMPLETEDLater on, the client asks for 1000 bytes from that converted body part, starting at byte 2001 🧚
C: c001 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii"))
BINARY[4]<2001.1000>
S: * 2 CONVERTED (TAG "c001") (BINARY[4]<2001> {135}
<bytes 2001 - 2135 of the document in text/plain format>
)
S: c001 OK CONVERT COMPLETEDThe server MUST respect the target MIME type and the conversion parameters the client asked for in the transcoding request 🫡 Just a heads up that some conversion parameters can restrict what kind of conversion is possible, while others can remove some restrictions 🧐
It's legal for a client to ask for conversion of a non-leaf body part, like turning a multipart/* into a PDF document 📚 But servers implementing this extension are not required to support those conversions 🙈 Servers that DO support them MUST return one or more CONVERSION responses to a CONVERSIONS "multipart/*" "*" command. See Section 5.1 for more details 📋
Clients can request header conversions with the BODY[...HEADER] CONVERT request, like this 💌
C: D001 FETCH 2 BODY[HEADER]
S: * 2 FETCH (BODY[HEADER] {158}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?KOI8-R?Q?why encode this?=
S:
S: )
S: D001 OK
C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER]
S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {157}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?UTF-8?Q?why encode this?=
S:
S: )
S: D002 OKAny such request MUST include the CHARSET parameter 🎀 When the server gets the request, it MUST decode any encoded words in the headers (as described in [RFC2047]) and send them back re-encoded in the specified charset 💅 Encoded words might not even be needed if the result can be written entirely in US-ASCII, so the server MAY swap them for their pure US-ASCII version 🦋 If the server can't decode a particular encoded word, like when the charset or encoding isn't recognized, it MUST leave that word as is 🙅♀️ Servers SHOULD also support decoding of parameters as described in [RFC2231] 🌈 Supporting RFC 2231 parameters might mean reformatting header fields during conversion 🧩 Check out this one:
C: D011 FETCH 3 BODY[1.MIME]
S: * 3 FETCH (BODY[1.MIME] {118}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0;
S: foo*1*(very)=%03s_m%c0;
S: foo*2*=(nasty)%09chant
S:
S: D011 OKThe server should keep the headers as intact as it can during conversion 🫶 If characters are split (legally!) across fragments of an encoded parameter, the server MUST put the parameter fragments back together, then convert, emit, and re-fragment them as needed to keep each line under 78 characters 🧵 Comments embedded like this SHOULD be preserved during conversion, but clients MUST handle gracefully the case where comments get removed entirely 😌 If the comments are kept, they MAY be moved to after the parameter 🔁 For example (continuing the previous example) 💜
C: D012 CONVERT 3 (NIL) BODY[1.MIME]
S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0%03s_;
S: foo*1*=%m%c0%09chant (very)(nasty)
S:
S: D012 OKNo destination MIME type MUST be specified with BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME] 🙅♀️ In other words, those three can ONLY be used with "default conversion" 🎯 When doing these conversions, the server SHOULD leave encoded words as encoded words 🧠 Not doing that could mess up the meaning of structured headers 😭
7. CONVERT Conversion Parameters 🎀
okay so the registry from [MEDIAFEAT-REG] is where all the conversion parameter names live, and those names are what you can use in a CONVERT command. some of them are mandatory, which we'll get to in Section 7.1 🫶
According to [MEDIAFEAT-REG], parameter names are case-insensitive, so PIX-X and pix-x are the same thing 💅
Here's a cute example of setting target picture dimensions with the PIX-X and PIX-Y parameters from [DISP-FEATURES] 🦋
C: e001 UID CONVERT 100 ("IMAGE/JPEG" ("PIX-X" "128"
"PIX-Y" "96")) BINARY[2]
S: * 2 CONVERTED (TAG "e001") (UID 100 BINARY[2] ~{4182}
<this part of a document is a rescaled image in
JPEG format with width=128, height=96.>
)
S: e001 OK UID CONVERT COMPLETED7.1. Mandatory-to-Implement Conversions and Conversion Parameters ✨
A server implementing CONVERT MUST support charset conversions for the text/plain MIME type, and MUST support charset conversions from iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8, and iso-8859-15 to utf-8. this is the baseline everyone has to hit, no exceptions 😭
The server MUST list "text/plain" as an allowed destination conversion from "text/plain" MIME type (see Section 5.1). A command CONVERSIONS "text/plain" "text/plain" MUST also return "charset" and "unknown-character-replacement" (see Section 12.1) as supported conversion parameters in the corresponding CONVERSION response. so basically, ask about text/plain to text/plain and it has to show you those two parameters 🔥
IMAP servers implementing the CONVERT extension MUST support recognition of the "charset" [CHARSET-REG] parameter for text/plain, text/html, text/css, text/csv, text/enriched, and text/xml MIME types. Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory-to-implement conversion described above. That is, a server implementation MUST support the "charset" parameter for text/csv, only if it supports any conversion from text/csv. so recognizing "charset" is the requirement, but actually converting those types is up to the server (apart from the mandatory one) 🌸
The server MUST support decoding of [RFC2047] headers and their conversion to UTF-8 as long as the encoded words are in one of the supported charsets. 💜
Servers SHOULD offer additional character encoding conversions where they make sense, as character conversion libraries are generally available on many platforms. 🧚
If the server cannot carry out the charset conversion while preserving all the characters (i.e., a source character can't be represented in the target charset), and the "unknown-character-replacement" conversion parameter is not specified, then the server MUST fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9). If the value specified in the "unknown-character-replacement" conversion itself can't be represented in the target charset, then the server MUST also fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9).
the vibe check: if a character can't survive the trip and you didn't give a replacement, the server has to fail it with BADPARAMETERS. and if your replacement character can't survive the trip either, same thing. no silently mangling text 🙅♀️
7.2. Additional Features for Mobile Usage ✨
This section is informative.
Based on the expected usage of CONVERT in mobile environments, server implementors should consider support for the following conversions:
- Conversion of HTML and XHTML documents to text/plain in ways that preserve at the minimum the document structure and tables.
- Image conversions among the types image/gif, image/jpeg, and image/png for at least the following parameters:
- size limit (i.e., reduce quality)
- width ("pix-x" parameter)
- height ("pix-y" parameter)
- resize directive (crop, stretch, aspect ratio)
The support for "depth" may also be of interest.
Audio conversion is also of interest but the relevant formats depend significantly on the usage context. it's giving "it depends on the vibe" 🎧
8. Request/Response Data Items to CONVERT/UID CONVERT Commands 🦋
8.1. CONVERTED Untagged Response 💖
Contents: convert correlator
CONVERTED return data itemsThe CONVERTED response may be sent as a result of a successful, partially successful, or unsuccessful CONVERT or UID CONVERT command specified in Section 6. even the failed ones can get a CONVERTED response, so don't assume silence means nothing happened 👀
The CONVERTED response starts with a message number, followed by the "CONVERTED" label. The label is followed by a convert correlator, which contains the tag of the command that caused the response to be returned. This can be used by a client to match a CONVERTED response against a corresponding CONVERT/UID CONVERT command. the tag is basically the matchmaker here 💕
The convert correlator is followed by a list of one or more CONVERT return data items. If the UID data item is returned, it MUST be returned as the first data item in the CONVERTED response. This requirement is to simplify client implementations. See Section 10 and the remainder of Section 8 for more details. UID goes first, always, because it makes clients' lives easier 🫶
8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item ✨
BODYPARTSTRUCTURE[section-part]The CONVERT extension defines the BODYPARTSTRUCTURE CONVERT data item. Data contained in the BODYPARTSTRUCTURE return data item follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but only contains information for the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted MIME type, subtype, size, or charset. Note that the client can expect the returned MIME type to match the one it requested (as the server is required to obey the requested MIME type) and can treat mismatch as an error. so the MIME type you asked for is the one you should get back, and if it's different that's a real error 🚨
The returned BODYPARTSTRUCTURE data MUST match the BINARY data returned for exactly the same conversion in the same IMAP "session". This requirement allows a client to request BODYPARTSTRUCTURE and BINARY data in separate commands in the same IMAP session. the two have to agree, no drama 💅
If the client lists a BODYPARTSTRUCTURE data item for a section-part before a BINARY data item for the same section-part, then, in the CONVERTED response, the server MUST return the BODYPARTSTRUCTURE data prior to the corresponding BINARY data. Also, any BODYSTRUCTURE data items MUST be after the UID data item if the UID data item is present. Both requirements are to simplify handling of converted data in clients. the order is the whole point here, it keeps client code clean 🧚
Example:
C: e002 CONVERT 2 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2]
BODYPARTSTRUCTURE[2])
S: * 2 CONVERTED (TAG "e002") (BODYPARTSTRUCTURE[2] ("IMAGE"
"JPEG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2]
~{4182}
<this part of a document is a rescaled image in
JPEG format with width=128, height=96.>
)
S: e002 OK CONVERT COMPLETED8.3. BINARY.SIZE CONVERT Request and Response Item 🌈
BINARY.SIZE[section-part]This item requests the converted size of the section (i.e., the size to expect in a response to the corresponding CONVERT BINARY request). The returned value MUST be exact and MUST NOT change during a duration of an IMAP "session", unless the message is expunged in another session (see below). This allows a client to download a converted part in chunks (using "<partial>"). This requirement means that in most cases the server needs to perform conversion of the requested body part before returning its size. so the server often has to do the whole conversion just to tell you the size, which is a fun little plot twist 🙈
If the message is expunged in another session, then the server MAY return the value 0 in response to the BINARY.SIZE request item later in the same session.
In order to allow for upgrade of server transcoding components, clients MUST NOT assume that repeating a particular body part conversion in another IMAP "session" would yield the same result as a previous conversion of the very same body part -- any characteristics of the converted body part might be different (format, size, etc.). In particular, clients MUST NOT cache sizes of converted messages/body parts beyond duration of any IMAP "session", or use sizes obtained in one connection in another IMAP connection to the same server. the server can get upgraded, so don't trust old sizes across sessions, bestie 🔄
historical tea ☕: previous experience with IMAP servers that returned estimated RFC822.SIZE value shows that this caused interoperability problems. If the server returns a value that is smaller than the actual size, this will result in data truncation if <partial> download is used. If the server returns a value that is bigger than the actual size, this might mislead a client to believe that it doesn't have enough storage to download a body part. estimates were a mess before, so exact sizes are the move 😭
Note for client implementors: client authors are cautioned that this might be an expensive operation for some server implementations. Requesting BINARY.SIZE for a large number of converted body parts or for multiple conversions of the same body part can result in slow performance and/or excessive server load and is discouraged. Client implementors should consider implementation approaches that limit this request to only the most necessary cases and are encouraged to test the performance impact of BINARY.SIZE with multiple server implementations. so don't spam BINARY.SIZE on everything, it can be super expensive on some servers 💀 test it out first and keep the requests lean 🍓
8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item 🎀
AVAILABLECONVERSIONS[section-part]AVAILABLECONVERSIONS[section-part] allows the client to request the list of target MIME types the specified body part of a message or the whole message can be converted to. This data item is only useful when the default conversion (see Section 6) is requested. it's the "what can this become?" question 🦋
This data item MUST return a list of target MIME types that is a subset of the list returned by the CONVERSIONS command for the same source and target MIME type pairs. If specific conversion is requested, it MUST return the target MIME type as requested in the CONVERT command, or the ERROR phrase. no making up new options, the answer has to come from CONVERSIONS 💅
For both specific or default conversion requests, if conversion parameters are specified, then the server must take them into consideration when generating the list of target MIME types. For example, if one or more of the conversion parameters doesn't apply to a potential target MIME type, then such MIME type MUST be omitted from the resulting list. If the server only had a single target MIME type candidate and it was discarded due to the list of conversion parameters, then the server SHOULD return the ERROR phrase instead of the empty list of the target MIME types. so if the only option gets filtered out, ERROR is better than an awkward empty list 🙃
The AVAILABLECONVERSIONS request SHOULD be processed quickly if specified by itself. Note that if a MIME type is returned in response to the AVAILABLECONVERSIONS, there is no guaranty that the corresponding BINARY/BINARY.SIZE/BODYPARTSTRUCTURE CONVERT request will not fail. so a MIME type showing up in the list is a hint, not a promise that the actual conversion will work 🥺
Example:
C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2])
S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2]
(("IMAGE/JPEG" "application/PostScript"))
S: f001 OK CONVERT COMPLETED8.5. Implementation Considerations ✨
Okay bestie, this bit is NORMATIVE 🫶 so these are the real rules, not vibes. Let's go!
Servers MAY refuse conversion requests that try to convert several messages and/or body parts at once, like a request that lists multiple message numbers/UIDs. 💅 If a server says no because the request lists too many messages, it MUST return the MAXCONVERTMESSAGES response code (see Section 9). Here's how that looks:
C: g001 CONVERT 1:* ("text/plain" ("charset" "us-ascii"))
BINARY[3]
S: g001 NO [MAXCONVERTMESSAGES 1]Same deal if the request lists too many body parts. The server MUST return the MAXCONVERTPARTS response code (see Section 9) 🙈
C: h001 CONVERT 1 ("text/plain" ("charset" "us-ascii"))
(BINARY[1] BINARY[2])
S: g001 NO [MAXCONVERTPARTS 1] You can only request 1 body part at
any given timeNote for server implementors: 🧚 Okay this one is lowkey the best tip. To improve performance, implementations SHOULD cache converted body parts. For example, a server might do the conversion when it gets the first BINARY.SIZE[...], BODYPARTSTRUCTURE[...], or BINARY[...] request, and then keep that cached until the client asks for a different body part, a different conversion of the same body part, or until the mailbox is closed. 🍓 To protect against denial-of-service attacks from misbehaving or badly-written clients, a server SHOULD limit how many converted body parts it can cache. Servers SHOULD be able to cache at least 2 conversions at any given time.
9. Status Responses and Response Code Extensions 🎀
Okay, the status responses are where the server explains itself, so pay attention. ✨
A syntactically invalid MIME media type SHOULD generate a BAD tagged response from the server. An unrecognized MIME media type generates a NO tagged response. 🙃
Some transcodings need parameters. If a transcoding request with no parameters is sent for a format that requires them, the server will return an ERROR MISSINGPARAMETERS phrase in place of the data for the requested data items. It's kind of like the NIL response in FETCH, except there's structured data attached to explain what went wrong. 🌸
If the server can't do the requested conversion because a resource is temporarily unavailable (for example, it's out of disk space, has a temporary internal error, or the transcoding service is down), then the server MUST return a tagged NO response. That response SHOULD contain the TEMPFAIL response code (see below), or an ERROR TEMPFAIL phrase. 😭
If the requested conversion can't be done because of a permanent error, like a proprietary document format that has no transcoding implementation, the server MUST return a CONVERTED response containing an ERROR BADPARAMETERS or ERROR MISSINGPARAMETERS phrase. 💀
The server MAY choose to return one ERROR phrase for a single conversion when several related data items are requested. For instance:
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii"))
(BINARY[3] BODYPARTSTRUCTURE[3])
S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii")))
S: b002 NO All conversions failedIf at least one conversion succeeds, the server MUST return an OK response. If all conversions fail, the server MAY return OK or NO. For instance:
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii"))
(BINARY[3] BODYPARTSTRUCTURE[3] BINARY[4]
BODYPARTSTRUCTURE[4])
S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii"))
BODYSTRUCTURE[4] ("TEXT" "PLAIN" (CHARSET US-ASCII)
NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[4] {4182}
<body in text plain>
)
S: b002 OK Some conversions failedIn general, the client can tell from the BODYPARTSTRUCTURE response whether its request was honored exactly, but it might not know why. 🔍
This document defines the following response codes that can be returned in the tagged NO response code. 👑
TEMPFAIL: The transcoding request failed temporarily. It might succeed later, so the client MAY retry.MAXCONVERTMESSAGES <number>: The server is unable or unwilling to convert more than <number> messages in any given CONVERT/UID CONVERT request.MAXCONVERTPARTS <number>: The server is unable or unwilling to convert more than <number> body parts of a message at once in any given CONVERT/UID CONVERT request.
The word ERROR is always followed by an informal, human-readable description, and then the convert-error-code. The convert-error-code MUST be one of the following: 🌈
TEMPFAIL mm: The transcoding request failed temporarily. It might succeed later, so the client MAY retry. The client SHOULD wait for at least mm minutes before retrying.BADPARAMETERS: The listed parameters were not understood, weren't valid for that source/destination MIME type pair, had invalid values, or couldn't be honored for another reason. That reason is noted in the human-readable text after the ERROR label. The format is:
BADPARAMETERS from-concrete-mime-type to-mime-type
"(" transcoding-params ")"The transcoding-params can be left out, which means that the conversion from the from-concrete-mime-type to the to-mime-type isn't possible. If the from-concrete-mime-type is NIL, the specified body part doesn't exist. All unrecognized or irrelevant parameters MUST be listed in the transcoding-params. Ignoring irrelevant parameters is not legal behavior. 🚫
Note that if the client requested the "default conversion" (see Section 6), the to-mime-type contains the destination MIME type chosen by the server.
MISSINGPARAMETERS: The listed parameters are required to convert the specified source MIME type to the destination MIME type, but they weren't in the request. The format is:
MISSINGPARAMETERS from-concrete-mime-type to-mime-type
"(" transcoding-params ")"Note that if the client requested the "default conversion" (see Section 6), the to-mime-type contains the destination MIME type chosen by the server.
Examples: 🧁
C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: b002 NO [TEMPFAIL] All conversions failed
C: b003 CONVERT 2 ("TEXT/PLAIN") BINARY[3]
S: * 2 CONVERTED (tag "b003") (BINARY[3]
(ERROR "CHARSET must be specified for text conversions"
MISSINGPARAMETERS (CHARSET)))
S: b003 NO All conversions failed
C: b005 CONVERT 2 ("TEXT/PLAIN" (CHARSET "US-ASCII"
UNKNOWN-CHARACTER-REPLACEMENT "<badchar>")) BINARY[3]
S: * 2 CONVERTED (tag "b005") (BINARY[3]
(ERROR "UNKNOWN-CHARACTER-REPLACEMENT limited to 4
bytes" BADPARAMETERS (UNKNOWN-CHARACTER-REPLACEMENT
"<badchar>")))
S: b005 NO All conversions failed10. Formal Syntax 🎀
okay so the grammar is written in ABNF (that's [ABNF] 💅), and it also borrows the core rules from that doc. This syntax builds on [RFC3501] and [RFC3516]. Anything not defined here is hiding in [RFC3501], [RFC3516], [IMAPABNF], [MIME-MTSRP], or [MEDIAFEAT-REG] 🌸
command-select =/ convert
uid =/ "UID" SP convert
; Unique identifiers used instead of message
; sequence numbers
convert = "CONVERT" SP sequence-set SP convert-params SP
( convert-att /
"(" convert-att *(SP convert-att) ")" )
convert-att = "UID" /
"BODYPARTSTRUCTURE" section-convert /
"BINARY" section-convert [partial] /
"BINARY.SIZE" section-convert /
"BODY[HEADER]" /
"BODY[" section-part ".HEADER]" /
"BODY[" section-part ".MIME]" /
"AVAILABLECONVERSIONS" section-convert
; <partial> is defined in [RFC3516].
; <section-part> is defined in [RFC3501].
convert-params = "(" (quoted-to-mime-type / default-conversion)
[SP "(" transcoding-params ")"] ")"
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
transcoding-params = transcoding-param
*(SP transcoding-param)
transcoding-param-names = transcoding-param-name
*(SP transcoding-param-name)
transcoding-param = transcoding-param-name SP
transcoding-param-value
transcoding-param-name = astring
; <transcod-param-name-nq> represented as a quoted,
; literal or atom. Note that
; <transcod-param-name-nq> allows for "%", which is
; not allowed in atoms. Such values must be
; represented as quoted or literal.
transcod-param-name-nq = Feature-tag
; <Feature-tag> is defined in [MEDIAFEAT-REG].
transcoding-param-value = astring
default-conversion = "NIL"
message-data =/ nz-number SP "CONVERTED" SP convert-correlator
SP convert-msg-attrs
convert-correlator = "(" "TAG" SP tag-string ")"
tag-string = string
; tag of the command that caused
; the CONVERTED response, sent as
; a string.
convert-msg-attrs = "(" convert-msg-att *(SP convert-msg-att) ")"
; "UID" MUST be the first data item, if present.
convert-msg-att = msg-att-semistat / msg-att-conv-static
msg-att-conv-static = "UID" SP uniqueid
; MUST NOT change for a message
msg-att-semistat =
( "BINARY" section-convert ["<" number ">"] SP
(nstring / literal8 / converterror-phrase) ) /
( "BINARY.SIZE" section-convert SP
(number / converterror-phrase) ) /
( "BODYPARTSTRUCTURE" section-convert SP
(body / converterror-phrase) ) /
( "AVAILABLECONVERSIONS" section-convert SP
(mimetype-list / converterror-phrase) )
; MUST NOT change during an IMAP "session",
; but not necessarily static in the long term.
section-convert = section-binary
; <section-binary> is defined in [RFC3516].
;
; Note that unlike [RFC3516], conversion
; of a top level multipart/* is allowed.
resp-text-code =/ "TEMPFAIL" /
"MAXCONVERTMESSAGES" SP nz-number /
"MAXCONVERTPARTS" SP nz-number
; <resp-text-code> is defined in [RFC3501].
mimetype-and-params = quoted-to-mime-type
[SP "(" transcoding-params ")"]
; always includes a specific MIME type
mimetype-list = "(" "(" [quoted-to-mime-type
*(SP quoted-to-mime-type)] ")" ")"
; Unordered list of MIME types. It can be empty.
;
; Two levels of parenthesis is needed to distinguish this
; data from <converterror-phrase>.
converterror-phrase = "(" "ERROR" SP
convert-err-descript SP convert-error-code ")"
convert-error-code = "TEMPFAIL" [SP nz-number]
/ bad-params
/ missing-params
convert-err-descript = string
; Human-readable text explaining the conversion error.
; The default charset is US-ASCII, unless
; the LANGUAGE command [IMAP-I18N] is called, when
; the charset changes to UTF-8.
quoted-from-mime-type = DQUOTE from-concrete-mime-type DQUOTE
bad-params = "BADPARAMETERS"
1*(SP (quoted-from-mime-type / nil)
SP mimetype-and-params)
; nil is only returned when the body part doesn't exist.
missing-params = "MISSINGPARAMETERS"
1*(SP quoted-from-mime-type SP
mimetype-and-missing-params)
mimetype-and-missing-params = quoted-to-mime-type
"(" transcoding-param-names ")"
; always includes a specific MIME type
concrete-mime-type = type-name "/" subtype-name
; i.e., "type/subtype".
; type-name and subtype-name
; are defined in [MIME-MTSRP].
from-concrete-mime-type = concrete-mime-type
to-mime-type = concrete-mime-type
command-auth =/ conversions-cmd
conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP
to-mime-type-req
from-mime-type-req = astring
; "mime-type-req" represented as IMAP <atom>,
; <quoted> or <literal>
to-mime-type-req = astring
; <mime-type-req> represented as IMAP <atom>,
; <quoted> or <literal>.
; Note that <mime-type-req> allows for "*",
; which is not allowed in <atom>. Such values must
; be represented as <quoted> or <literal>.
any-mime-type = "*"
mime-type-req = any-mime-type /
(type-name "/" any-mime-type) /
concrete-mime-type
; '*', 'type/*' or 'type/subtype'.
; type-name is defined in [MIME-MTSRP].
response-payload =/ conversion-data
conversion-data = "CONVERSION" SP quoted-from-mime-type SP
quoted-to-mime-type
[SP "(" transcoding-param-name
*(SP transcoding-param-name) ")"]11. Manageability Considerations 🔧
keeping an eye on CONVERT is basically like keeping an eye on IMAP FETCH, so if you already watch FETCH you're halfway there 👀
as of writing, there's no standard IMAP MIB, and that goes for CONVERT too: there's no standard MIB for tracking CONVERT operations and their failures 😭 BUT the authors think that without one, server implementations SHOULD give operators tools to report the following:
- which conversions (source and target MIME types and possibly conversion parameters used) are invoked more frequently and how long they take,
- information about conversion errors and which error condition caused them (see Section 9), and
- information about users which invoke conversion operation.
this info helps operators spot client abuse of the extension and scalability problems that could pop up from using it 🚨
standardizing these tools might be future work, so stay tuned 🦋
12. IANA Considerations 📋
IMAP4 capabilities get registered by publishing a Standards Track or IESG-approved Experimental RFC. This doc defines the CONVERT IMAP capability, and IANA has added it to the IANA IMAP Capability registry ✨
IANA has also done the registrations in the subsections below 💖
12.1. Registration of unknown-character-replacement Media Type Parameter 🌈
IANA added a new entry to the registry that RFC 2506 set up. Here's the full registration form, copied exactly because the details matter:
To: "Media feature tags mailing list"
<media-feature-tags@apps.ietf.org>
Subject: Registration of media feature tag
unknown-character-replacement
Media feature tag name:
unknown-character-replacement
ASN.1 identifier associated with feature tag:
1.3.6.1.8.1.33
Summary of the media feature indicated by this feature tag:
Allows servers that can perform charset conversion for text/plain
text/html, text/css, text/csv, text/enriched, and text/xml MIME
types to replace characters not supported by the target charset
with a fixed string, such as "?".
This feature tag is also applicable to other conversions
to text, e.g., conversion of images using OCR (optical
character recognition).
Values appropriate for use with this feature tag:
The feature tag contains a UTF-8 string used to replace any
characters from the source media type that can't be
represented in the target media type.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
IMAP CONVERT extension [RFC5259]
Examples of typical use:
C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset"
"us-ascii" "unknown-character-replacement" "?"))]
Related standards or documents:
[RFC5259]
[CHARSET-REG]
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms:
None
Interoperability considerations: None
Security considerations: None
Additional information:
This media feature only make sense for MIME types that
also support the "charset" media type parameter
[CHARSET-REG].
Name(s) & email address(es) of person(s) to contact for further
information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage:
COMMON
Author/Change controller:
IETF
Requested IANA publication delay:
None
Other information:
None13. Security Considerations 🔒
Okay bestie, this section is where things get spicy 🌶️ Some conversions can be genuinely dangerous: turning a document into something damaging, exploiting a buffer overflow in a media codec or parser, or launching a denial-of-service attack on a client or server, like asking for an image to be scaled to absurd dimensions 💀 A Server SHOULD refuse to execute CPU-expensive conversions. Servers should avoid dangerous conversions if possible. Whenever possible, servers should verify the converted attachments before sending them back to the client ✅ Clients should be careful when they request conversions or process transformed attachments. Clients SHOULD use mutual Simple Authentication and Security Layer (SASL) authentication and the SASL/TLS integrity layer, so they know they're talking to trusted servers 🫶
Bestie, pay attention here: if the client asks the server to convert a signed body part (like a part inside multipart/signed), the client has no way to check that the converted content is authentic 😭
If a client doesn't trust the server to convert a signed body part, it can download the signed object, verify the signature, and do the conversion itself 🔐
A client can also craft a bad message with the APPEND command and then send the CONVERT command to attack the server 😱 If the server's conversion function or library has a security problem (like being vulnerable to a buffer overflow), that could lead to privilege escalation or denial of service. To help mitigate these attacks, servers SHOULD log the client authentication identity on APPEND and/or CONVERT operations, so abusive clients are easier to track 🕵️♀️ Server implementors SHOULD also isolate the conversion function or library from the privileged mailstore, maybe by running it in a separate process.
Deployments where the actual transcoding happens outside the IMAP server, in a separate server, are recommended to keep those servers in the same trusted domain (for example, the same subnet) 🧱
14. Acknowledgments 🎀
Stephane H. Maes and Ray Cromwell from Oracle edited several earlier versions of this document, and their contribution is gratefully acknowledged 🙌
The authors want to give a special shout-out to the excellent criticism and comments from Randall Gellens (Qualcomm), Arnt Gulbrandsen (Oryx), Zoltan Ordogh (Nokia), Ben Last (Emccsoft), Dan Karp (Zimbra), Pete Resnick (Qualcomm), Chris Newman (Sun), Ted Hardie (Qualcomm), Larry Masinter (Adobe), Philip Guenther (Sendmail), Greg Vaudreuil (Alcatel-Lucent), David Harrington (Comcast), Dave Cridland (Isode), Pasi Eronen (Nokia), Magnus Westerlund (Ericsson), and Jari Arkko (Ericsson). Their feedback made this spec so much better ✨
The authors would also like to specially thank Dave Cridland for the MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command proposal 💜
The authors also want to thank everyone who brought key insight and reviewed and discussed the concepts of CONVERT and its predecessor P-IMAP. This especially includes the authors of the LCONVERT document: Rafiul Ahad (Oracle Corporation), Eugene Chiu (Oracle Corporation), Ray Cromwell (Oracle Corporation), Jia-der Day (Oracle Corporation), Vi Ha (Oracle Corporation), Wook-Hyun Jeong (Samsung Electronics Co. LTF), Chang Kuang (Oracle Corporation), Rodrigo Lima (Oracle Corporation), Stephane H. Maes (Oracle Corporation), Gustaf Rosell (Sony Ericsson), Jean Sini (Symbol Technologies), Sung-Mu Son (LG Electronics), Fan Xiaohui (China Mobile Communications Corporation (CMCC)), and Zhao Lijun (China Mobile Communications Corporation (CMCC)) 🦋
15. References 📚
15.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[CHARSET-REG] Hoffman, P., "Registration of Charset and Languages
Media Features Tags", RFC 2987, November 2000.
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", RFC 4466, April 2006.
[MEDIAFEAT-REG] Holtman, K., Mutz, A., and T. Hardie, "Media Feature
Tag Registration Procedure", BCP 31, RFC 2506,
March 1999.
[MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288,
December 2005.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions
for Non-ASCII Text", RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions:
Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension",
RFC 3516, April 2003.15.2. Informative References
[DISP-FEATURES] Masinter, L., Wing, D., Mutz, A., and K. Holtman,
"Media Features for Display, Print, and Fax",
RFC 2534, March 1999.
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov,
"Internet Message Access Protocol
Internationalization", RFC 5255, June 2008.
[LEM-STREAMING] Cook, N., "Streaming Internet Messaging
Attachments", Work in Progress, June 2008.
[OMA-ME-RD] OMA, "Open Mobile Alliance Mobile Email Requirement
Document", OMA 55.919 3.0.0, December 2007.
[OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding
Interface Specification", OMA OMA-STI-V1_0,
December 2005.Authors' Addresses 🖊️
Alexey Melnikov (editor)
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Peter Coates (editor)
Sun Microsystems
185 Falcon Drive
Whitehorse, YT Y1A 6T2
Canada
EMail: peter.coates@Sun.COMFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 💅
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 🫶
📦 where this page comes from
- ietf: rfc5259 2008-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms