forked from pEp.foundation/internet-drafts
implement Kelly's feedback and adjust introduction and case "unknown"
parent
e0d15e9822
commit
abc450db42
|
|
@ -61,25 +61,28 @@ with name "forwarded" and its registration with IANA.
|
|||
|
||||
This document defines a new Content-Type header field parameter
|
||||
[RFC2045] with name "forwarded". The parameter value is case-
|
||||
insensitive and can be either "yes", "no" or "unknown", with the default
|
||||
value being "yes". Setting the value to "no" is meaningful with media type
|
||||
"message/rfc822" and "message/global" {{RFC6532}} when used within
|
||||
S/MIME or PGP/MIME signed or encrypted body parts
|
||||
insensitive and can be either "yes", "no" or "unknown". Setting the
|
||||
value to "no" is meaningful with media type "message/rfc822" and
|
||||
"message/global" {{RFC6532}} when used within S/MIME or PGP/MIME
|
||||
signed or encrypted body parts
|
||||
(cf. {{I-D.ietf-lamps-header-protection-requirements}}. The value
|
||||
"yes" means that the message nested inside "message/rfc822"
|
||||
("message/global") is a simple forwarded message.
|
||||
("message/global") is a simple forwarded message. If the value has
|
||||
been set to "unknown" (or no such parameter), the default assumption
|
||||
is the message has been forwarded.
|
||||
|
||||
|
||||
## Use Cases
|
||||
|
||||
Two use cases have been discovered so far:
|
||||
|
||||
1. This parameter indicates whether a nested message is signed
|
||||
(S/MIME or PGP/MIME) and/or encrypted, which tells the receiving
|
||||
side how to display the message to the user. Currently, many email
|
||||
clients display "weird artefacts" to users due to this missing information.
|
||||
1. This parameter indicates whether a nested message is signed and/or
|
||||
encrypted (S/MIME or PGP/MIME), which tells the receiving side how
|
||||
to display the message to the user. Currently, many email clients
|
||||
display "weird artefacts" to users due to this missing information.
|
||||
|
||||
2. This parameter indicates to Mailing lists which email messages are
|
||||
forwarded, and which are signed (S/MIME or PGP/MIME) and/or encrypted,
|
||||
2. This parameter indicates to mailing lists which email messages are
|
||||
forwarded, and which are signed and/or encrypted (S/MIME or PGP/MIME),
|
||||
and how to handle these respective messages.
|
||||
|
||||
|
||||
|
|
@ -110,25 +113,28 @@ field parameter.
|
|||
The Content-Type header field parameter "forwarded" may assume three
|
||||
values:
|
||||
|
||||
* "Yes": The email message contained in the MIME part is a forwarded
|
||||
* "yes": The email message contained in the MIME part is a forwarded
|
||||
message. A MUA (Mail User Agent) that is forwarding a message should
|
||||
add a Content-Type header field parameter "forwarded=yes".
|
||||
|
||||
* "No": The email message contained in the MIME part is an
|
||||
encapsulated email message, e.g. for the sake of header protection
|
||||
by signing and encryption. MUAs SHOULD add a Content-Type header
|
||||
field parameter "forwarded=no" to indicate the message is not
|
||||
forwarded, but encapsulated to protection or other reasons than
|
||||
forwarding. (cf. {{I-D.ietf-lamps-header-protection-requirements}})
|
||||
**[KRB: Suggested "...email message, such as encapsulation through signing and/or encryption for header protection." "...but encapsulated for header protection or reasons other than forwarding." Please note I'm not 100% clear on what is being explained here, these suggestions are the best I can make from this paragraph as it stands.]
|
||||
|
||||
* "Unknown": If the MUA has no information to determine whether an
|
||||
* "no": The email message contained in the MIME part is a encapsulated
|
||||
email message that has been signed and/or encrypted for header
|
||||
protection. MUAs SHOULD add a Content-Type header field parameter
|
||||
"forwarded=no" to indicate the message is not forwarded, but
|
||||
encapsulated for header protection
|
||||
(cf. {{I-D.ietf-lamps-header-protection-requirements}}).
|
||||
|
||||
* "unknown": If the MUA has no information to determine whether an
|
||||
email message is forwarded or encapsulated, it MAY add a
|
||||
Content-Type header field parameter "forwarded=unknown" to indicate
|
||||
support for this Content-Type header field parameter. Email messages
|
||||
containing a Content-Type header field parameter "forwarded=unknown"
|
||||
are normally treated the same as messages where the Content-Type
|
||||
header field parameter "forwarded" is missing or left blank.
|
||||
header field parameter "forwarded" is missing. The latter is
|
||||
normally the case for legacy clients unaware of the Content-Type
|
||||
header field parameter "forwarded" specified herein. A receiving
|
||||
MUAs default behavior is to assume the email message contained in
|
||||
the MIME part is a forwarded message.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -399,8 +399,8 @@
|
|||
<meta name="dct.creator" content="Melnikov, A. and B. Hoeneisen" />
|
||||
<meta name="dct.identifier" content="urn:ietf:id:draft-melnikov-iana-reg-forwarded-00" />
|
||||
<meta name="dct.issued" scheme="ISO8601" content="2019-11-01" />
|
||||
<meta name="dct.abstract" content="This document defines a new Content-Type header field parameter with name “forwarded” and its regustration with IANA." />
|
||||
<meta name="description" content="This document defines a new Content-Type header field parameter with name “forwarded” and its regustration with IANA." />
|
||||
<meta name="dct.abstract" content="This document defines a new Content-Type header field parameter with name “forwarded” and its registration with IANA." />
|
||||
<meta name="description" content="This document defines a new Content-Type header field parameter with name “forwarded” and its registration with IANA." />
|
||||
|
||||
</head>
|
||||
|
||||
|
|
@ -438,7 +438,7 @@
|
|||
<span class="filename">draft-melnikov-iana-reg-forwarded-00</span></p>
|
||||
|
||||
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
|
||||
<p>This document defines a new Content-Type header field parameter with name “forwarded” and its regustration with IANA.</p>
|
||||
<p>This document defines a new Content-Type header field parameter with name “forwarded” and its registration with IANA.</p>
|
||||
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
|
||||
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
|
||||
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
|
||||
|
|
@ -494,21 +494,21 @@
|
|||
<h1 id="rfc.section.1">
|
||||
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
|
||||
</h1>
|
||||
<p id="rfc.section.1.p.1">This document defines a new Content-Type header field parameter <a href="#RFC2045" class="xref">[RFC2045]</a> with name “forwarded”. The parameter value is case- insensitive and can be either “yes”, “no” or “unknown”. (The default value being “yes”). Setting is to “no” is meaningful with media type “message/rfc822” and “message/global” <a href="#RFC6532" class="xref">[RFC6532]</a> when used within S​/​MIME or PGP/MIME signed or encrypted body parts (cf. <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a>. The value “yes” means that the message nested inside “message/rfc822” (“message/global”) is a simple forwarded message.</p>
|
||||
<p id="rfc.section.1.p.1">This document defines a new Content-Type header field parameter <a href="#RFC2045" class="xref">[RFC2045]</a> with name “forwarded”. The parameter value is case- insensitive and can be either “yes”, “no” or “unknown”. Setting the value to “no” is meaningful with media type “message/rfc822” and “message/global” <a href="#RFC6532" class="xref">[RFC6532]</a> when used within S​/​MIME or PGP/MIME signed or encrypted body parts (cf. <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a>. The value “yes” means that the message nested inside “message/rfc822” (“message/global”) is a simple forwarded message. If the value has been set to “unknown” (or no such parameter), the default assumption is the message has been forwarded.</p>
|
||||
<h1 id="rfc.section.1.1">
|
||||
<a href="#rfc.section.1.1">1.1.</a> <a href="#use-cases" id="use-cases">Use Cases</a>
|
||||
</h1>
|
||||
<p id="rfc.section.1.1.p.1">Two use cases have been discovered so for:</p>
|
||||
<p id="rfc.section.1.1.p.1">Two use cases have been discovered so far:</p>
|
||||
<p></p>
|
||||
|
||||
<ol>
|
||||
<li>Indicate a nested messages is S​/​MIME or PGP/MIME signed and/or encrypted to help the receiving side how to display the message to the user. It has been discovered that many clients present “weired artefacts” to users due to missing such information.</li>
|
||||
<li>Indicated to Mailing lists which email messages are forwarded and which are S​/​MIME or PGP/MIME signed and/or encrypted to treat those accordingly.</li>
|
||||
<li>This parameter indicates whether a nested message is signed and/or encrypted (S​/​MIME or PGP/MIME), which tells the receiving side how to display the message to the user. Currently, many email clients display “weird artefacts” to users due to this missing information.</li>
|
||||
<li>This parameter indicates to mailing lists which email messages are forwarded, and which are signed and/or encrypted (S​/​MIME or PGP/MIME), and how to handle these respective messages.</li>
|
||||
</ol>
|
||||
<h1 id="rfc.section.1.2">
|
||||
<a href="#rfc.section.1.2">1.2.</a> <a href="#implementations" id="implementations">Implementations</a>
|
||||
</h1>
|
||||
<p id="rfc.section.1.2.p.1">At this time it is known that two email systems are using this Content-Type header field parameter:</p>
|
||||
<p id="rfc.section.1.2.p.1">At this time, there are two known email systems which use this Content-Type header field parameter:</p>
|
||||
<p></p>
|
||||
|
||||
<ol>
|
||||
|
|
@ -541,9 +541,9 @@
|
|||
<p></p>
|
||||
|
||||
<ul>
|
||||
<li>“yes”: the email message contained in the MIME part is a fowarded message. A MUA (Mail User Agent) that is forwarding a message should add a Content-Type header field parameter “forwarded=yes”</li>
|
||||
<li>“no”: the email message contained in the MIME part is an encapsulated email message, e.g. for the sake of header protection by signing and encryption. MUAs SHOULD add add a Content-Type header field parameter “forwarded=no” to indicate the message is not forwarded, but encapsulated to protection or other reasons than forwarding. (cf. <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a>)</li>
|
||||
<li>“unknown”: if the MUA has no information to determine whether an email messages is forwarded or encapsulated, it MAY add a Content-Type header field parameter “forwarded=unknown” to indicate support for this Content-Type header field parameter. Appart from the latter, email messages containing a Content-Type header field parameter “forwarded=unknown” are normally treated the same as messages without a Content-Type header field parameter “forwarded”.</li>
|
||||
<li>“yes”: The email message contained in the MIME part is a forwarded message. A MUA (Mail User Agent) that is forwarding a message should add a Content-Type header field parameter “forwarded=yes”.</li>
|
||||
<li>“no”: The email message contained in the MIME part is a encapsulated email message that has been signed and/or encrypted for header protection. MUAs SHOULD add a Content-Type header field parameter “forwarded=no” to indicate the message is not forwarded, but encapsulated for header protection (cf. <a href="#I-D.ietf-lamps-header-protection-requirements" class="xref">[I-D.ietf-lamps-header-protection-requirements]</a>).</li>
|
||||
<li>“unknown”: If the MUA has no information to determine whether an email message is forwarded or encapsulated, it MAY add a Content-Type header field parameter “forwarded=unknown” to indicate support for this Content-Type header field parameter. Email messages containing a Content-Type header field parameter “forwarded=unknown” are normally treated the same as messages where the Content-Type header field parameter “forwarded” is missing. The latter is normally the case for legacy clients unaware of the Content-Type header field parameter “forwarded” specified herein. A receiving MUAs default behavior is to assume the email message contained in the MIME part is a forwarded message.</li>
|
||||
</ul>
|
||||
<h1 id="rfc.section.3">
|
||||
<a href="#rfc.section.3">3.</a> <a href="#example" id="example">Example</a>
|
||||
|
|
@ -558,11 +558,11 @@
|
|||
Content-Type: multipart/signed; charset=us-ascii; micalg=sha1;
|
||||
protocol="application/pkcs7-signature";
|
||||
boundary=.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
|
||||
|
||||
This is a multipart message in MIME format.
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Type: message/rfc822; forwarded=no
|
||||
|
||||
|
||||
Date: Mon, 25 Sep 2017 17:31:42 +0100 (GMT Daylight Time)
|
||||
From: "Alexey Melnikov" <alexey.melnikov@example.net>
|
||||
Message-ID: <e4a483cb-1dfb-481d-903b-298c92c21f5e@matt.example.net>
|
||||
|
|
@ -572,15 +572,15 @@
|
|||
To: somebody@example.net
|
||||
X-Mailer: Isode Harrier Web Server
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
|
||||
|
||||
This is an important message that I don't want to be modified.
|
||||
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237
|
||||
Content-Transfer-Encoding: base64
|
||||
Content-Type: application/pkcs7-signature
|
||||
|
||||
|
||||
[[base-64 encoded signature]]
|
||||
|
||||
|
||||
--.cbe16d2a-e1a3-4220-b821-38348fc97237--
|
||||
|
||||
</pre>
|
||||
|
|
@ -595,7 +595,7 @@
|
|||
<h1 id="rfc.section.6">
|
||||
<a href="#rfc.section.6">6.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
|
||||
</h1>
|
||||
<p id="rfc.section.6.p.1">This document requests the regisration of the Content-Type header field parameter <a href="#RFC2045" class="xref">[RFC2045]</a> with name “forwarded” with IANA as specified in <a href="#specification" class="xref">Section 2</a> of this document.</p>
|
||||
<p id="rfc.section.6.p.1">This document requests the registration of the Content-Type header field parameter <a href="#RFC2045" class="xref">[RFC2045]</a> with name “forwarded” with IANA as specified in <a href="#specification" class="xref">Section 2</a> of this document.</p>
|
||||
<h1 id="rfc.section.7">
|
||||
<a href="#rfc.section.7">7.</a> <a href="#acknowledgments" id="acknowledgments">Acknowledgments</a>
|
||||
</h1>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Expires: May 4, 2020 Ucom.ch
|
|||
Abstract
|
||||
|
||||
This document defines a new Content-Type header field parameter with
|
||||
name "forwarded" and its regustration with IANA.
|
||||
name "forwarded" and its registration with IANA.
|
||||
|
||||
Status of This Memo
|
||||
|
||||
|
|
@ -82,29 +82,29 @@ Table of Contents
|
|||
|
||||
This document defines a new Content-Type header field parameter
|
||||
[RFC2045] with name "forwarded". The parameter value is case-
|
||||
insensitive and can be either "yes", "no" or "unknown". (The default
|
||||
value being "yes"). Setting is to "no" is meaningful with media type
|
||||
"message/rfc822" and "message/global" [RFC6532] when used within
|
||||
S/MIME or PGP/MIME signed or encrypted body parts (cf.
|
||||
insensitive and can be either "yes", "no" or "unknown". Setting the
|
||||
value to "no" is meaningful with media type "message/rfc822" and
|
||||
"message/global" [RFC6532] when used within S/MIME or PGP/MIME signed
|
||||
or encrypted body parts (cf.
|
||||
[I-D.ietf-lamps-header-protection-requirements]. The value "yes"
|
||||
means that the message nested inside "message/rfc822" ("message/
|
||||
global") is a simple forwarded message.
|
||||
global") is a simple forwarded message. If the value has been set to
|
||||
"unknown" (or no such parameter), the default assumption is the
|
||||
message has been forwarded.
|
||||
|
||||
1.1. Use Cases
|
||||
|
||||
Two use cases have been discovered so for:
|
||||
|
||||
1. Indicate a nested messages is S/MIME or PGP/MIME signed and/or
|
||||
encrypted to help the receiving side how to display the message
|
||||
to the user. It has been discovered that many clients present
|
||||
"weired artefacts" to users due to missing such information.
|
||||
|
||||
2. Indicated to Mailing lists which email messages are forwarded and
|
||||
which are S/MIME or PGP/MIME signed and/or encrypted to treat
|
||||
those accordingly.
|
||||
|
||||
Two use cases have been discovered so far:
|
||||
|
||||
1. This parameter indicates whether a nested message is signed and/
|
||||
or encrypted (S/MIME or PGP/MIME), which tells the receiving side
|
||||
how to display the message to the user. Currently, many email
|
||||
clients display "weird artefacts" to users due to this missing
|
||||
information.
|
||||
|
||||
2. This parameter indicates to mailing lists which email messages
|
||||
are forwarded, and which are signed and/or encrypted (S/MIME or
|
||||
PGP/MIME), and how to handle these respective messages.
|
||||
|
||||
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
|||
|
||||
1.2. Implementations
|
||||
|
||||
At this time it is known that two email systems are using this
|
||||
At this time, there are two known email systems which use this
|
||||
Content-Type header field parameter:
|
||||
|
||||
1. Isode with S/MIME [RFC8551]
|
||||
|
|
@ -145,23 +145,23 @@ Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
|||
The Content-Type header field parameter "forwarded" may assume three
|
||||
values:
|
||||
|
||||
o "yes": the email message contained in the MIME part is a fowarded
|
||||
o "yes": The email message contained in the MIME part is a forwarded
|
||||
message. A MUA (Mail User Agent) that is forwarding a message
|
||||
should add a Content-Type header field parameter "forwarded=yes"
|
||||
should add a Content-Type header field parameter "forwarded=yes".
|
||||
|
||||
o "no": the email message contained in the MIME part is an
|
||||
encapsulated email message, e.g. for the sake of header protection
|
||||
by signing and encryption. MUAs SHOULD add add a Content-Type
|
||||
header field parameter "forwarded=no" to indicate the message is
|
||||
not forwarded, but encapsulated to protection or other reasons
|
||||
than forwarding. (cf.
|
||||
[I-D.ietf-lamps-header-protection-requirements])
|
||||
o "no": The email message contained in the MIME part is a
|
||||
encapsulated email message that has been signed and/or encrypted
|
||||
for header protection. MUAs SHOULD add a Content-Type header
|
||||
field parameter "forwarded=no" to indicate the message is not
|
||||
forwarded, but encapsulated for header protection (cf.
|
||||
[I-D.ietf-lamps-header-protection-requirements]).
|
||||
|
||||
o "unknown": if the MUA has no information to determine whether an
|
||||
email messages is forwarded or encapsulated, it MAY add a Content-
|
||||
o "unknown": If the MUA has no information to determine whether an
|
||||
email message is forwarded or encapsulated, it MAY add a Content-
|
||||
Type header field parameter "forwarded=unknown" to indicate
|
||||
support for this Content-Type header field parameter. Appart from
|
||||
the latter, email messages containing a Content-Type header field
|
||||
support for this Content-Type header field parameter. Email
|
||||
messages containing a Content-Type header field parameter
|
||||
"forwarded=unknown" are normally treated the same as messages
|
||||
|
||||
|
||||
|
||||
|
|
@ -170,9 +170,12 @@ Melnikov & Hoeneisen Expires May 4, 2020 [Page 3]
|
|||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||||
|
||||
|
||||
parameter "forwarded=unknown" are normally treated the same as
|
||||
messages without a Content-Type header field parameter
|
||||
"forwarded".
|
||||
where the Content-Type header field parameter "forwarded" is
|
||||
missing. The latter is normally the case for legacy clients
|
||||
unaware of the Content-Type header field parameter "forwarded"
|
||||
specified herein. A receiving MUAs default behavior is to assume
|
||||
the email message contained in the MIME part is a forwarded
|
||||
message.
|
||||
|
||||
3. Example
|
||||
|
||||
|
|
@ -218,9 +221,6 @@ Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Melnikov & Hoeneisen Expires May 4, 2020 [Page 4]
|
||||
|
||||
Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
||||
|
|
@ -237,7 +237,7 @@ Internet-Draft Content-Type HF Parameter 'forwarded' November 2019
|
|||
|
||||
6. IANA Considerations
|
||||
|
||||
This document requests the regisration of the Content-Type header
|
||||
This document requests the registration of the Content-Type header
|
||||
field parameter [RFC2045] with name "forwarded" with IANA as
|
||||
specified in Section 2 of this document.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue