Internet DRAFT - draft-pep-sml-auto-processing-marker
draft-pep-sml-auto-processing-marker
Network Working Group B. Hoeneisen
Internet-Draft H. Marques
Updates: 3458 (if approved) pEp Foundation
Intended status: Standards Track 20 June 2023
Expires: 22 December 2023
Email Marker to Indicate Automatic Processing
draft-pep-sml-auto-processing-marker-00
Abstract
Structured Email suggests to complement existing email standards by
means that allow to replace or extend text-based email messages with
message parts that describe content (full or in parts) in a machine-
readable way.
This document specifies a means to mark messages (or parts of)
intended for automatic processing.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-pep-sml-auto-processing-
marker/.
Discussion of this document takes place on the sml non-WG mailing
list (mailto:sml@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/sml/.
Source for this draft and an issue tracker can be found at
https://gitea.pep.foundation/pEp.foundation/internet-drafts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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/.
Hoeneisen & Marques Expires 22 December 2023 [Page 1]
Internet-Draft Email Auto-Processing Marker June 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 December 2023.
Copyright Notice
Copyright (c) 2023 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Non-Deterministic Behavior . . . . . . . . . . . . . 4
1.1.2. User Confusion . . . . . . . . . . . . . . . . . . . 4
1.1.3. Automatic Filtering due to Unknown Attachment
Format . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Automatic Processing Marker Specification . . . . . . . . . . 5
3.1. Whole Email Message . . . . . . . . . . . . . . . . . . . 5
3.1.1. New Message Context Class, Parameters and Values . . 6
3.1.2. Message Context Specification . . . . . . . . . . . . 6
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. MIME Entity . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. New Content Disposition Parameters and Values . . . . 6
3.2.2. Content Disposition Specification . . . . . . . . . . 7
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7
4. Recipient Client Considerations . . . . . . . . . . . . . . . 7
4.1. Hiding Decision . . . . . . . . . . . . . . . . . . . . . 7
4.2. Rendering When Hidden . . . . . . . . . . . . . . . . . . 8
4.3. Simple Policy . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hoeneisen & Marques Expires 22 December 2023 [Page 2]
Internet-Draft Email Auto-Processing Marker June 2023
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Early Ideas for Enhanced Automatic Processing Marker
Specification . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Whole Email Message . . . . . . . . . . . . . . . . . . . 10
A.1.1. New Message Context Class, Parameters and Values . . 11
A.1.2. Message Context Specification . . . . . . . . . . . . 12
A.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. MIME Entity . . . . . . . . . . . . . . . . . . . . . . . 13
A.2.1. New Content Disposition Parameters and Values . . . . 13
A.2.2. Content Disposition Specification . . . . . . . . . . 14
A.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 15
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Recent IETF discussions on Structured Email (SML)
[I-D.happel-sml-problem-statement] suggest to complement existing
email standards by means that allow to replace or extend text-based
email messages with message parts that describe content (full or in
parts) in a machine-readable way.
This document specifies a means to mark messages (or parts of)
intended for automatic processing. Different Use Cases cover the
whole message, a Multipurpose Internet Mail Extensions (MIME)
[RFC2045] entity or just a part of a (MIME) entity.
Note: It is for further study whether the latter case is really
needed (cf. Section 2).
According to [I-D.happel-sml-problem-statement] such markers are in
scope for the Structured Email (SML) Working Group (in formation):
* Additional email header information might inform clients about
the presence of Structured Email content.
This document updates [RFC3458] to extend the "Internet Message
Context Classes" IANA registry.
1.1. Motivation
The following scenarios have been encountered in real life, which can
be mitigated by this new specification.
Hoeneisen & Marques Expires 22 December 2023 [Page 3]
Internet-Draft Email Auto-Processing Marker June 2023
1.1.1. Non-Deterministic Behavior
Email systems that process Structured Email messages often need to
apply fuzzy logic to guess, which parts of the email are applicable
to automatic processing. This may lead to non-deterministic behavior
or inconsistencies at receiver systems applying automatic processing.
In some cases Structured Email parts are missed.
1.1.2. User Confusion
Emails containing structured attachment may lead to confusion of the
recipient user; for example, if an email system by default attaches
the sender's pubkey key for OpenPGP [RFC4880] encryption (e.g.,
[I-D.pep-email]). If Alice is using such a system to send an email
message to Bob, he may get confused by the attachment containing the
public key, as he is lacking knowledge on how to handle such kinds of
attachments. As a consequence, Bob likely will send a reply to Alice
requesting said attachment in a format known to Bob (e.g., as PDF).
Alice then needs to explain to Bob that he may simply ignore this
attachment (as sending the public key in PDF normally does not make
sense).
Another case of user confusion are messages that are solely meant for
automatic processing. For example, Email systems that inform peers
with structures emails about revoked keys for cryptographic email
(e.g., [I-D.pep-keyreset]) or systems that feature private key
synchronization (e.g., [I-D.pep-keysync]). In both cases such email
messages may lead to user confusion.
1.1.3. Automatic Filtering due to Unknown Attachment Format
Emails containing structured attachments may get filtered by the
recipient's Email system due to unknown attachment format. This may
lead to removal of such an attachment or a bounce message to the
sender to resend the email using an attachment format known by the
recipient's Email system.
1.2. 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.
Hoeneisen & Marques Expires 22 December 2023 [Page 4]
Internet-Draft Email Auto-Processing Marker June 2023
2. Requirements
The following requirements are discussed in this document. A
requirement marked with [M] is mandatory, while [O] means it is
optional.
1. Mark the whole email message for automatic processing [M]
2. Mark a MIME entity for automatic processing [M]
3. Mark part of a (MIME) entity (e.g., JSON, HTML, XML) for
automatic processing [O]
4. Specify automatic processing to be required or optional [O]
5. Provide a SML type of the content for automatic processing such
as public key, calendar data, etc. [O]
6. Provide a means to suggest hiding of specific parts meant for
automatic processing [O]
Note:
The optional requirements need further discussion on whether or
not and in which form those are needed. In Appendix A you can
find some early ideas on how requirements 4.-6. may be specified,
if considered useful.
3. Automatic Processing Marker Specification
Note:
As it is yet unclear, which requirements will be part of the final
specification, the following sections (for the time being) only
regard the requirements 1. and 2. (cf. Section 2). This
specification will be updated depending on the outcome of the
requirements discussion.
3.1. Whole Email Message
This section specifies a marker in case the whole email message is
intended for automatic processing.
Hoeneisen & Marques Expires 22 December 2023 [Page 5]
Internet-Draft Email Auto-Processing Marker June 2023
3.1.1. New Message Context Class, Parameters and Values
The existing "Message-Context" Header Field [RFC3458] is reused and
enhanced. The IANA registry for Internet Message Context Classes
(cf. https://www.iana.org/assignments/message-header-types/message-
header-types.xhtml) allows for registrations of Context Classes.
A new Message Context Class 'structured' will be registered with
IANA. Furthermore, the IANA registry will be enhanced to allow for
Message Context Class parameters and values. The following Message
Context parameter is registered with IANA:
* auto-processing
3.1.2. Message Context Specification
The "Message-Context" Header Field always applies to the whole
message (including the Header section).
To mark a message as Structured Email, the sender of an email SHOULD
add a Header Field "Message-Context" with the value "structured".
* Such a Header Field SHOULD also contain a Message Context
parameter "auto-processing" to indicate the whole message be
intended for automatic processing.
3.1.3. Example
The following example shows a Header Field "Message-Context":
Message-Context: structured; auto-processing
3.2. MIME Entity
This section specifies a marker in case some MIME [RFC2045] entity of
an email message is intended for automatic processing.
3.2.1. New Content Disposition Parameters and Values
The existing "Content-Disposition" MIME Header Field [RFC2183] is
reused and enhanced.
The IANA registry for Content Disposition (cf.
https://www.iana.org/assignments/cont-disp/cont-disp.xhtml) allows
for registrations of:
* Content Disposition values
Hoeneisen & Marques Expires 22 December 2023 [Page 6]
Internet-Draft Email Auto-Processing Marker June 2023
* Content Disposition parameters
* Content Disposition parameter values (if applicable)
A new Content-Disposition value "structured" is registered with IANA
and the IANA registry is enhanced by the following Content
Disposition parameter:
* auto-processing
3.2.2. Content Disposition Specification
The "Content-Disposition" Header Field applies to the corresponding
MIME entity (including all subordinate MIME nodes and leafs, if
present).
To mark a MIME entity as Structured Email part, the sender of an
email SHOULD add a Header Field "Content-Disposition" with the value
"structured". For backward compatibility reasons the existing
Content Disposition parameter "attachment" MAY be used instead of
"structured".
* Such a Header Field SHOULD also contain a Content Disposition
parameter "auto-processing" to indicate the whole message be
intended for automatic processing.
3.2.3. Example
The following example shows a MIME Header Field "Content-Disposition"
as it could be applied for an attachment containing the public key:
Content-Disposition: attachment;
filename="pEpkey.asc"; auto-processing
4. Recipient Client Considerations
4.1. Hiding Decision
The recipient client system may apply different policies or options
for Structured Emails (or parts) depending on:
* local circumstances
* whether or not the recipient system understands the Structured
Email (or parts)
Hoeneisen & Marques Expires 22 December 2023 [Page 7]
Internet-Draft Email Auto-Processing Marker June 2023
4.2. Rendering When Hidden
If the decision is to apply hiding (cf. Section 4.1), the system
may:
1. Hide Structured Email (or parts) altogether from the recipient
user
2. Simply notify there is a Structured Email (or part) meant for
automatic processing (but not allow to interact with it)
3. Notify there is a Structured Email (or part) meant for automatic
processing and allow to interact with it (e.g., allow to view or
download a structured attachment)
A short notification for hidden email could be: "Email intended for
automatic processing."
A notification for hidden attachments could be: "This attachment is
intended for automatic processing. If you don't know what this
means, you may ignore it."
Such notifications should be localized to match the language set in
the user interface.
4.3. Simple Policy
A simple policy may be:
* Render hidden emails with variant 2 and hidden email parts with
variant 3 (cf. Section 4.2)
5. Security Considerations
As with all content processing the recipient system needs to ensure
that also Structured Emails (or parts) are checked for harmful
content that may compromise the security (such as viruses, trojan
horses or other malware) before or during automatic processing.
6. IANA Considerations
The document requests the following IANA actions:
* Extend the "Context labels for Internet Messages" registry
[RFC3458] to include Parameters and Values for Message Context
Classes in similar manner as defined for the "Content-Disposition"
MIME Header Field [RFC2183].
Hoeneisen & Marques Expires 22 December 2023 [Page 8]
Internet-Draft Email Auto-Processing Marker June 2023
* Register the Message Context Class, Parameters and Values listed
in Section 3.1.1 to the "Context labels for Internet Messages"
registry in accordance with [RFC3458] and the IANA action in the
previous bullet point.
* Register the Content Disposition Parameters and Values listed in
Section 3.2.1 to the "Content Disposition Values and Parameters"
registry in accordance with [RFC2183].
7. Acknowledgements
The authors would like to thank the following people who have
provided feedback or significant contributions to the development of
this document: Hans-Joerg Happel
8. References
8.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>.
[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>.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458,
DOI 10.17487/RFC3458, January 2003,
<https://www.rfc-editor.org/info/rfc3458>.
[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>.
8.2. Informative References
Hoeneisen & Marques Expires 22 December 2023 [Page 9]
Internet-Draft Email Auto-Processing Marker June 2023
[I-D.happel-sml-problem-statement]
Happel, H. and C. Junghans, "Structured Email: Problem
Statement and Areas of Work", Work in Progress, Internet-
Draft, draft-happel-sml-problem-statement-00, 27 January
2023, <https://datatracker.ietf.org/doc/html/draft-happel-
sml-problem-statement-00>.
[I-D.pep-email]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Email Formats and Protocols", Work in Progress, Internet-
Draft, draft-pep-email-02, 16 December 2022,
<https://datatracker.ietf.org/doc/html/draft-pep-email-
02>.
[I-D.pep-keyreset]
Hoeneisen, B., "pretty Easy privacy (pEp): Key Reset",
Work in Progress, Internet-Draft, draft-pep-keyreset-00,
15 December 2022, <https://datatracker.ietf.org/doc/html/
draft-pep-keyreset-00>.
[I-D.pep-keysync]
Birk, V., Hoeneisen, B., and H. Marques, "pretty Easy
privacy (pEp): Key Synchronization Protocol (KeySync)",
Work in Progress, Internet-Draft, draft-pep-keysync-03, 6
June 2023, <https://datatracker.ietf.org/doc/html/draft-
pep-keysync-03>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
Appendix A. Early Ideas for Enhanced Automatic Processing Marker
Specification
In the following some early ideas on how the requirements 4.-6. (cf.
Section 2) could be implemented. Whether or not and in which forms
these requirements are needed is still to be discussed.
A.1. Whole Email Message
This section specifies a marker in case the whole email message is
intended for automatic processing.
Hoeneisen & Marques Expires 22 December 2023 [Page 10]
Internet-Draft Email Auto-Processing Marker June 2023
A.1.1. New Message Context Class, Parameters and Values
The existing "Message-Context" Header Field [RFC3458] is reused and
enhanced. The IANA registry for Internet Message Context Classes
(cf. https://www.iana.org/assignments/message-header-types/message-
header-types.xhtml) allows for registrations of Context Classes.
A new Message Context Class 'structured' will be registered with
IANA. Furthermore, the IANA registry will be enhanced to allow for
Message Context Class parameters and values. The following Message
Context parameters are registered with IANA:
* auto-processing
* sml-type
* hiding-recommendation
The Message Context parameter "auto-processing" may assume the
following values:
* optional
* required
The Message Context parameter "sml-type" may assume several values
that SHOULD be registered with IANA, including:
* order
* mailman-request
* public-key
* pep-key-reset
* pep-key-sync
* ...
The Message Context parameter "hiding-recommendation" may assume the
following values (in parentheses a terse explanation):
* 0 (not recommended)
* 1 (no recommendation; default)
* 2 (recommended; ordinary users likely get confused)
Hoeneisen & Marques Expires 22 December 2023 [Page 11]
Internet-Draft Email Auto-Processing Marker June 2023
* 3 (strongly recommended; even savvy users likely get confused)
The numbers allow to set a simple condition on whether or not apply
hiding.
A.1.2. Message Context Specification
The "Message-Context" Header Field always applies to the whole
message (including the Header section).
To mark a message as Structured Email, the sender of an email SHOULD
add a Header Field "Message-Context" with the value "structured".
* Such a Header Field SHOULD also contain a Message Context
parameter "auto-processing" to indicate the whole message be
intended for automatic processing.
- The Message Context parameter "auto-processing" MAY contain
either of the values "optional" (default) or "required". If
the recipient is unable to process a structured message
containing such a "required" parameter, it MAY send an
automatic reply to the sender indicating the inability to
process such a structured message. However, the exact
semantics are out-of-scope of this document. (Any
corresponding data-format or application specification may
further define such semantics.)
* Such a Header Field MAY also contain a Message Context parameter
"sml-type" (with a suitable value, e.g., "pep-key-reset") to
indicate the type of the automatic processing.
* Such a Header Field MAY also contain a Message Context parameter
"hiding-recommendation" (with a numeric value) to provide the
recipient's MUA with a hint on whether or not to apply hiding of
the message (cf. Section 4).
A.1.3. Example
The following example shows a Header Field "Message-Context" as it
could be applied to a pEp KeyReset [I-D.pep-keyreset] message (to
inform the peer about revoked keys):
Message-Context: structured; auto-processing="mandatory";
sml-type="pep-key-reset"; hiding-recommendation=3
Hoeneisen & Marques Expires 22 December 2023 [Page 12]
Internet-Draft Email Auto-Processing Marker June 2023
A.2. MIME Entity
This section specifies a marker in case some MIME [RFC2045] entity of
an email message is intended for automatic processing.
A.2.1. New Content Disposition Parameters and Values
The existing "Content-Disposition" MIME Header Field [RFC2183] is
reused and enhanced.
The IANA registry for Content Disposition (cf.
https://www.iana.org/assignments/cont-disp/cont-disp.xhtml) allows
for registrations of:
* Content Disposition values
* Content Disposition parameters
* Content Disposition parameter values (if applicable)
A new Content-Disposition value "structured" is registered with IANA
and the IANA registry is enhanced by the following Content
Disposition parameters:
* auto-processing
* sml-type
* hiding-recommendation
The Content Disposition parameters "auto-processing" and "attachment"
may (additionally) assume the following values:
* optional
* required
The Content Disposition parameter "sml-type" may assume several
values that SHOULD be registered with IANA, including:
* public-key
* calendar-data
* contact
* flight-itinerary
Hoeneisen & Marques Expires 22 December 2023 [Page 13]
Internet-Draft Email Auto-Processing Marker June 2023
* ...
The Content Disposition parameter "hiding-recommendation" may assume
the same values as defined in Appendix A.1.1 above.
A.2.2. Content Disposition Specification
The "Content-Disposition" Header Field applies to the corresponding
MIME entity (including all subordinate MIME nodes and leafs, if
present).
To mark a MIME entity as Structured Email part, the sender of an
email SHOULD add a Header Field "Content-Disposition" with the value
"structured". For backward compatibility reasons the existing
Content Disposition parameter "attachment" MAY be used instead of
"structured".
* Such a Header Field SHOULD also contain a Content Disposition
parameter "auto-processing" to indicate the whole message be
intended for automatic processing.
- The Content Disposition parameter "auto-processing" MAY contain
either of the values "optional" (default) or "required". If
the recipient is unable to process a structured message part
containing such a "required" parameter, it MAY send an
automatic reply to the sender indicating the inability to
process such a structured message part. However, the exact
semantics are out-of-scope of this document. (Any
corresponding data-format or application specification may
further define such semantics.)
* Such a Header Field MAY also contain a Content Disposition
parameter "sml-type" (with a suitable value, e.g., "public-key")
to indicate the type of the automatic processing.
* Such a Header Field MAY also contain a Content Disposition
parameter "hiding-recommendation" (with a numeric value) to
provide the recipient's MUA with a hint on whether or not to apply
hiding of the message part (cf. Section 4).
A.2.3. Example
The following example shows a MIME Header Field "Content-Disposition"
as it could be applied for an attachment containing the public key:
Content-Disposition: attachment; filename="pEpkey.asc";
auto-processing="optional"; sml-type="public-key";
hiding-recommendation=2
Hoeneisen & Marques Expires 22 December 2023 [Page 14]
Internet-Draft Email Auto-Processing Marker June 2023
Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]]
* draft-pep-sml-auto-processing-marker-00
- Initial version
Appendix C. Open Issues
[[ RFC Editor: This section should be empty and is to be removed
before publication ]]
* Decide on optional requirements: whether or not and in which form
those are needed (cf. Section 2, bullet points 3.-6.)
* Need to cover more Use Cases?
* Enhance Recipient Client Considerations (cf. Section 4)
* Enhance Security Considerations (cf. Section 5)
* Improve IANA Considerations (cf. Section 6)
* Verify Terminology in Section 3.1 based on the outcome of
https://www.rfc-editor.org/errata/eid7540
Authors' Addresses
Bernie Hoeneisen
pEp Foundation
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: bernie.hoeneisen@pep.foundation
URI: https://pep.foundation/
Hernani Marques
pEp Foundation
Oberer Graben 4
CH-8400 Winterthur
Switzerland
Email: hernani.marques@pep.foundation
URI: https://pep.foundation/
Hoeneisen & Marques Expires 22 December 2023 [Page 15]
