RFC 8255
Multiple Language Content Type
RFC 8255: Multiple Language Content Type 🌈
Part 1 of 4 🎀
- Who wrote it: N. Tomkinson and N. Borenstein, both at Mimecast, Ltd. 💖
- Published by: the Internet Engineering Task Force (IETF) 🌸
- Category: Standards Track 🔥
- Date: October 2017 📅
- ISSN: 2070-1721
- Obsoletes or updates: nothing listed in this header ✨
Abstract ✨
okay so this doc defines the 'multipart/multilingual' content type, which is an add-on to MIME (Multipurpose Internet Mail Extensions). it lets you send one message that holds several language versions of the same info 💌 each translation gets a language tag, and the email client picks the right one based on the user's language settings. iconic 👑
Status of This Memo 🧾
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8255.
Copyright Notice ©️
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Content-Type Header Field . . . . . . . . . . . . . . . . 3
3. The Message Parts . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The Multilingual Preface . . . . . . . . . . . . . . . . 4
3.2. The Language Message Parts . . . . . . . . . . . . . . . 5
3.3. The Language-Independent Message Part . . . . . . . . . . 5
4. Message Part Selection . . . . . . . . . . . . . . . . . . . 6
5. The Content-Language Field . . . . . . . . . . . . . . . . . 6
6. The Content-Translation-Type Field . . . . . . . . . . . . . 7
7. The Subject Field in the Language Message Parts . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. An Example of a Simple Multiple-Language Email Message . 8
8.2. An Example of a Multiple-Language Email Message with a
Language-Independent Part . . . . . . . . . . . . . . . . 9
8.3. An Example of a Complex Multiple-Language Email Message
with a Language-Independent Part . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. The 'multipart/multilingual' Media Type . . . . . . . . . 13
9.2. The Content-Translation-Type Field . . . . . . . . . . . 15
9.3. The Content-Translation-Type Header Field Values . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction 🌍
ever since email got invented and the Internet spread like crazy, more and more people can talk to each other across more countries and in more languages. but email has basically stayed a single-language tool 😭 whether it's English to English, Spanish to Spanish, or Japanese to Japanese.
meanwhile, tons of companies have set up offices in multicultural cities, with teams spanning continents, cultures, and languages. so the need to communicate clearly, with very little room for miscommunication, has grown a LOT 📈
this document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard specified in [RFC2045], [RFC2046], [RFC2047], [RFC4289], and [RFC6838]. it lets you send one message to a group of people so that everyone can read it in their preferred language 🫶 how you translate the content is out of scope here. this doc only nails down how the email itself is structured ✨
this document depends on identifying the language in message parts for non-real-time communication. [HUMAN-LANG] tackles a similar problem for real-time communication 💬
1.1. Requirements Language 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
2. The Content-Type Header Field 🎀
The 'multipart/multilingual' Media Subtype lets you send a message in a bunch of different languages, with each language version embedded in the same message. it also helps the receiving email client figure out the message structure 🧩
the multipart subtype 'multipart/multilingual' has similar semantics to 'multipart/alternative' (as discussed in RFC 2046 [RFC2046]). in both, each part is an alternative version of the same info. the big difference is that with 'multipart/multilingual', the part to render is picked based on the Content-Language field and, optionally, the Content-Translation-Type field. with 'multipart/alternative', it's picked based on the order of the parts and the Content-Types instead 💅
the syntax for this multipart subtype follows the common syntax for subtypes of multipart given in Section 5.1.1. of RFC 2046 [RFC2046]. an example 'multipart/multilingual' Content-Type header field would look like this:
Content-Type: multipart/multilingual; boundary=011899988199911972533. The Message Parts 💌
A 'multipart/multilingual' message has a few kinds of message parts: exactly one multilingual preface, one or more language message parts, and zero or one language-independent message part. details below 👇
3.1. The Multilingual Preface 🌸
So the message can be received and displayed in non-conforming email clients, the message SHOULD contain an explanatory message part. that part MUST NOT be marked with a Content-Language field and MUST be the first of the message parts. for the most basic non-conforming clients, it SHOULD have a Content-Type of 'text/plain' 📄 non-conforming clients are expected to treat a message with an unknown multipart type as 'multipart/mixed' (per Sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]). so they might show all the parts one after another, or as attachments. having this explanatory part helps the recipient understand the structure 🫠
this initial part SHOULD briefly explain to the recipient that the message has multiple languages, and that the parts may be rendered sequentially or as attachments. it SHOULD be written in the same languages as the language message parts that follow 🌐
since this explanation will probably use scripts that need non-US-ASCII characters, it is RECOMMENDED that a UTF-8 charset be used for this message part. see RFC 3629 [RFC3629] for details of UTF-8 🔤
this section is useful for backward compatibility, but it'll usually only get shown by a non-conforming email client. that's because conforming email clients SHOULD only show the single language message part that matches the user's preferred language and the language message part's Content-Language 💖
for the preface to display correctly in a non-conforming email client, the sender MAY use the Content-Disposition field with a value of 'inline', in conformance with RFC 2183 [RFC2183] (which defines the Content-Disposition field). if it's provided, it SHOULD be placed at the 'multipart/multilingual' level and in the multilingual preface. this makes it clear to a non-conforming client that the preface should be shown right away, followed by any later parts marked as 'inline' 🦋
for examples of a multilingual preface, see Section 8.
3.2. The Language Message Parts 🌷
the language message parts are usually translations of the same content. these parts SHOULD be ordered so that the first part after the multilingual preface is in the language most likely to be recognized by the recipient. that one becomes the default part when language negotiation fails and there's no language-independent part 🥇 all of the language message parts MUST have a Content-Language field and a Content-Type field. they MAY also have a Content-Translation-Type field 🍓
the Content-Type for each language message part SHOULD be 'message/rfc822' so non-conforming email clients get good support. however, an implementation MAY use 'message/global' as support for it becomes more common. (see RFC 6532 [RFC6532] for details of 'message/global'.) each language message part should have a Subject field in the appropriate language for that part 🙌 if there's a From field, its value MUST include the same email address as the top-level From header field, although the display name MAY be a localized version. if the sender email address doesn't match, the top-level From header field value SHOULD be shown to the recipient 📬
3.3. The Language-Independent Message Part 🧚
if there's language-independent content for the recipient to see, say they have a preferred language that isn't one of the ones in the language message parts, and the default language message part probably won't be understood, another part MAY be provided. this part could typically include one or more language-independent graphics 🖼️ when this part is present, it MUST be the last part and MUST have a Content-Language field with a value of "zxx" (as described in BCP 47 [RFC5646]). the part SHOULD have a Content-Type of 'message/rfc822' or 'message/global', to match the language message parts ✨
4. Message Part Selection ✨
okay so here's how the email client figures out which part to show you 💅 it's kinda like a little decision tree, and I'm obsessed with it.
If the email client does not understand multipart/multilingual, it treats the message like a regular multipart/mixed and renders the parts that way (following Sections 5.1.3 and 5.1.7 of RFC 2046 [RFC2046]). Lowkey a safe fallback 🌸
If the email client does understand multipart/multilingual, it SHOULD ignore the multilingual preface and pick the best match for the user's preferred language out of the language message parts available 🎀 But wait, there's a twist! The user might actually want the original content in their second language over a machine translation in their first language 👀 That's where the Content-Translation-Type field comes in, since its value can be used for further selection based on that preference. There are a bunch of ways to do the language selection, but the matching schemes in RFC 4647 [RFC4647] are RECOMMENDED as a starting point 🦋 The whole goal is to show the most appropriate translation for the user. Iconic behavior, no cap ✨
If there's no match for the user's preferred language, or there's no preferred language information at all, the email client SHOULD select the language-independent part (if one exists). If there isn't one, it goes with the first language part right after the multilingual preface 💖
If there's no translation type preference information available, the values of the Content-Translation-Type field may be ignored 🙈
And finally, interactive implementations MAY offer the user a choice from among the available languages, or the option to see them all 🌈 bestie gets the final say!!
5. The Content-Language Field
okay the Content-Language field lives in each individual language message part and tells you what language that part is written in 🇬🇧 Based on this value, a conforming email client can figure out which part to display, depending on the user's language settings. Very sorted 💅
The Content-Language MUST comply with RFC 3282 [RFC3282] (which defines the Content-Language field) and BCP 47 [RFC5646] (which defines the structure and semantics for the language tag values). Non-negotiable, periodt 🫶
Examples of this field could look like the following:
Content-Language: en-GBContent-Language: deContent-Language: es-MX, frContent-Language: sr-Cyrl6. The Content-Translation-Type Field
the Content-Translation-Type field can be used in the individual language message parts to say what kind of translation it is 🦋 Based on this value and the user's preferences, a conforming email client can decide which part to show. It's giving main character energy 💜
This field can have one of three possible values: 'original', 'human', or 'automated' (although other values may be added in the future) ✨ Here's the vibe for each one:
- 'original' is for the language message part that's in the original language 🍓
- 'human' is for a part that a human translator translated, OR a part where a human checked and fixed up an automated translation 👑
- 'automated' is for a part that an electronic agent translated without anyone proofreading or correcting it afterwards 🤖
New values of the Content-Translation-Type header field ("translTypeExt" in the ABNF) are added following the procedure in Section 9.3 💅
Examples of this field include:
Content-Translation-Type: originalContent-Translation-Type: humanThe syntax of the Content-Translation-Type field in ABNF [RFC5234] is:
Content-Translation-Type = [FWS] translationtype
FWS = <Defined in RFC 5322>
translationtype = "original" / "human" / "automated" /
translTypeExt
translTypeExt = 1*atext
atext = <Defined in RFC 5322>This references RFC 5322 [RFC5322] for the predefined rules 'folding white space (FWS)' and 'atext' 🧚
7. The Subject Field in the Language Message Parts
okay so when the message arrives, conforming email clients need to show the subject in the right language for the recipient 🌸 To make that happen, the Subject field SHOULD be provided in each language message part. The value for this field should be a translation of the email subject 💖
US-ASCII and 'encoded-word' examples of this field include:
Subject: A really simple email subjectSubject: =?UTF-8?Q?Un_asunto_de_correo_electr=C3=b3nico_
realmente_sencillo?=See RFC 2047 [RFC2047] for the specification of 'encoded-word' 📚 (it's the nerdy part, but it's important!)
The subject to be presented to the recipient SHOULD be selected from the message part identified during the message part selection stage 🎀 If no Subject field is found, the top-level Subject header field value should be used. Backup plan, iykyk 🫶
8. Examples ✨
8.1. An Example of a Simple Multiple-Language Email Message
okay this one is the minimal example and I'm obsessed 😭 It's a multiple-language email message with the multilingual preface and two language message parts. Let's gooo 🔥
From: Nik@example.com
To: Nathaniel@example.com
Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 21:28:00 +0100
MIME-Version: 1.0
Content-Type: multipart/multilingual;
boundary="01189998819991197253"
--01189998819991197253
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a message in multiple languages. It says the
same thing in each language. If you can read it in one language,
you can ignore the other translations. The other translations may be
presented as attachments or grouped together.
Este es un mensaje en varios idiomas. Dice lo mismo en
cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
traducciones. Las otras traducciones pueden presentarse como archivos
adjuntos o agrupados.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: en-GB
Content-Translation-Type: original
Content-Disposition: inline
Subject: Example of a message in Spanish and English
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Hello, this message content is provided in your language.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: es
Content-Translation-Type: human
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Hola, el contenido de este mensaje esta disponible en su idioma.
--01189998819991197253--8.2. An Example of a Multiple-Language Email Message with a Language-Independent Part
this one adds a language-independent part on the end, a png image that doesn't need any translating 🖼️🦋 It's a multilingual preface, then two language message parts, then the png. Literally so organized 🧚
From: Nik@example.com
To: Nathaniel@example.com
Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 21:08:00 +0100
MIME-Version: 1.0
Content-Type: multipart/multilingual;
boundary="01189998819991197253"
--01189998819991197253
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a message in multiple languages. It says the
same thing in each language. If you can read it in one language,
you can ignore the other translations. The other translations may
be presented as attachments or grouped together.
Este es un mensaje en varios idiomas. Dice lo mismo en
cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
traducciones. Las otras traducciones pueden presentarse como
archivos adjuntos o agrupados.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: en
Content-Translation-Type: original
Content-Disposition: inline
Subject: Example of a message in Spanish and English
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Hello, this message content is provided in your language.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: es-ES
Content-Translation-Type: human
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Hola, el contenido de este mensaje esta disponible en su idioma.
--01189998819991197253
Content-Type: message/rfc822; name="Icon"
Content-Language: zxx
Content-Disposition: inline
Content-Type: image/png; name="icon.png"
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
--01189998819991197253--8.3. An Example of a Complex Multiple-Language Email Message with a Language-Independent Part ✨
Okay bestie, this one is the full glow-up 💅 It has the multilingual preface, two language message parts, and then a language-independent png image at the end 🖼️ Both language message parts have multipart/alternative contents, so a client would need to do some extra processing to figure out what to actually display 🧠
From: Nik@example.com
To: Nathaniel@example.com
Subject: Example of a message in Spanish and English
Date: Thu, 7 Apr 2017 20:55:00 +0100
MIME-Version: 1.0
Content-Type: multipart/multilingual;
boundary="01189998819991197253"
--01189998819991197253
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This is a message in multiple languages. It says the
same thing in each language. If you can read it in one language,
you can ignore the other translations. The other translations may
be presented as attachments or grouped together.
Este es un mensaje en varios idiomas. Dice lo mismo en
cada idioma. Si puede leerlo en un idioma, puede ignorar las otras
traducciones. Las otras traducciones pueden presentarse como
archivos adjuntos o agrupados.
--01189998819991197253
Content-Type: message/rfc822
Content-Language: en
Content-Translation-Type: original
Content-Disposition: inline
Subject: Example of a message in Spanish and English
Content-Type: multipart/alternative;
boundary="72530118999911999881"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--72530118999911999881
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hello, this message content is provided in your language.
--72530118999911999881
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hello, this message content is <b>provided</b> in
<i>your</i> language.</body></html>
--72530118999911999881--
--01189998819991197253
Content-Type: message/rfc822
Content-Language: es
Content-Translation-Type: human
Content-Disposition: inline
Subject: =?UTF-8?Q?Ejemplo_pr=C3=A1ctico_de_mensaje_?=
=?UTF-8?Q?en_espa=C3=B1ol_e_ingl=C3=A9s?=
Content-Type: multipart/alternative;
boundary="53011899989991197281"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--53011899989991197281
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hola, el contenido de este mensaje esta disponible en su idioma.
--53011899989991197281
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
<html><body>Hola, el contenido de este <b>mensaje</b> <i>esta</i>
disponible en su idioma.</body></html>
--53011899989991197281--
--01189998819991197253
Content-Type: message/rfc822; name="Icon"
Content-Language: zxx
Content-Disposition: inline
Content-Type: multipart/mixed;
boundary="99911972530118999881"; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
--99911972530118999881
Content-Type: image/png; name="icon.png"
Content-Disposition: inline
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAKQ2lDQ1BJQ0MgUHJvZmlsZ
QAASA2dlndUU1... shortened for brevity ...7yxfd1SNsEy+OXr76qr
997zF2hvZYeDEP5ftGV6Xzx2o9MAAAAASUVORK5CYII=
--99911972530118999881--
--01189998819991197253--9. IANA Considerations 🌸
9.1. The 'multipart/multilingual' Media Type 🎀
The 'multipart/multilingual' Media Type has been registered with IANA. Here's the registration template, which is based on the template specified in [RFC6838]:
Media Type name: multipart
Media subtype name: multilingual
Required parameters: boundary (defined in RFC 2046)
Optional parameters: N/A
Encoding considerations:
There are no encoding considerations for this multipart other
than that of the embedded body parts. The embedded body parts
(typically one 'text/plain' plus one or more 'message/*') may
contain 7-bit, 8-bit, or binary encodings.
Security considerations:
See the Security Considerations section in RFC 8255
Interoperability considerations:
Existing systems that do not treat unknown multipart subtypes
as 'multipart/mixed' may not correctly render a
'multipart/multilingual' type. These systems would also be non-
compliant with MIME.
Published specification: RFC 8255
Applications that use this media type:
Mail Transfer Agents, Mail User Agents, spam detection,
virus detection modules, and message authentication modules.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
Nik Tomkinson
rfc.nik.tomkinson@gmail.com
Nathaniel Borenstein
nsb@mimecast.com
Intended usage: COMMON
Restrictions on usage: N/A
Author/Change controller: IETF9.2. The Content-Translation-Type Field 💜
The Content-Translation-Type field has been added to the IANA "Permanent Message Header Field Names" registry. That entry references this document. This is the registration template:
Header field name: Content-Translation-Type
Applicable protocol: MIME
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8255
Related information: none9.3. The Content-Translation-Type Header Field Values 🦋
IANA has created a new registry titled "Content-Translation-Type Header Field Values". New values must be registered using the "Specification Required" [RFC8126] IANA registration procedure. Registrations must include a translation type value, a short description, and a reference to the specification.
This document also registers three initial values, specified below.
Value: original
Description:
Content in the original language
Reference: RFC 8255
Value: human
Description:
Content that has been translated by a human translator
or a human has checked and corrected an automated translation
Reference: RFC 8255
Value: automated
Description:
Content that has been translated by an electronic agent
without proofreading or subsequent correction
Reference: RFC 825510. Security Considerations 💀
Okay, this section is serious, so let's go 🚨 It is intended that each language message part is a direct translation of the original message, but this may not always be the case. These parts could contain undesirable content. That means there is a possible risk that undesirable text or images could be shown to the recipient if the message is passed through a spam filter that does not check all of the message parts. The risk should be minimal because an unknown multipart subtype should be treated as 'multipart/mixed', so each message part should be scanned afterwards 🛡️
If the email contains undesirable content in a language that the recipient cannot understand, and this unknown content is assumed to be a direct translation of the content the recipient can understand, the recipient may unintentionally forward undesirable content to someone who can understand it. To reduce this risk, an interactive implementation may allow the recipient to see all of the translations for comparison 👀
Because the language message parts have a Content-Type of 'message/rfc822' or 'message/global', they might contain From fields that have different values from the top-level From field, and they may not reflect the actual sender. These inconsistent From field values might get shown to the recipient in a non-conforming email client, and they may mislead the recipient into thinking that the email came from someone other than the real sender 😱
11. References 📚
11.1. Normative References 🌈
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, DOI 10.17487/RFC2047, November 1996,
<https://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
DOI 10.17487/RFC2183, August 1997,
<https://www.rfc-editor.org/info/rfc2183>.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
DOI 10.17487/RFC3282, May 2002,
<https://www.rfc-editor.org/info/rfc3282>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/info/rfc4289>.
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,
<https://www.rfc-editor.org/info/rfc4647>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.11.2. Informative References
okay so this is where the sources that are helpful to read but not required to implement live 📚 bestie, the reference is the work-in-progress draft from Randall Gellens, and it's the one about negotiating human language in real-time comms 🎀
[HUMAN-LANG]Gellens, R., "Negotiating Human Language in Real-Time Communications", Work in Progress,draft-ietf-slim-negotiating-human-language-13, July 2017.
Acknowledgements ✨
the authors really wanted to thank everyone who gave them helpful input 🫶 it's a long list, and it's giving community 💜 they'd like to specially shout out Harald Alvestrand, Stephane Bortzmeyer, Eric Burger, Ben Campbell, Mark Davis, Doug Ewell, Ned Freed, Randall Gellens, Gunnar Hellstrom, Mirja Kuehlewind, Barry Leiba, Sean Leonard, John Levine, Alexey Melnikov, Addison Phillips, Julian Reschke, Pete Resnick, Adam Roach, Brian Rosen, Fiona Tomkinson, Simon Tyler, and Daniel Vargha 🌸
the authors also wanted to thank Fernando Alvaro and Luis de Pablo for their work on the Spanish translations 🇪🇸 literally iconic teamwork 👑
Authors' Addresses 📮
here's where you can find the two authors, Nik Tomkinson and Nathaniel Borenstein, who both worked at Mimecast, Ltd. 🦋
Nik Tomkinson:
Nik Tomkinson
Mimecast, Ltd.
CityPoint, One Ropemaker Street
London EC2Y 9AW
United Kingdom
Email: `rfc.nik.tomkinson@gmail.com`Nathaniel Borenstein:
Nathaniel Borenstein
Mimecast, Ltd.
480 Pleasant Street
Watertown, MA 02472
United States of America
Email: nsb@mimecast.com📦 where this page comes from
- ietf: rfc8255 2017-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms