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]