RFC 9869: Parsable Mail Pointer Email Protocol (PMPEP)

Dover                  Independent Submission                  [Page 1]
RFC 9869                        PMPEP                        April 2024

Parsable Mail Pointer Email Protocol (PMPEP)

Table of Contents

1. Introduction ................................................... 2
2. PMPEP Format Specification ..................................... 2
   2.1. Example Usage ............................................. 2
3. Limitations of Message-ID ...................................... 3
4. URL Encoding ................................................... 3
5. Usage .......................................................... 3
6. Implementation Notes ........................................... 3
7. Security Considerations ........................................ 3
8. IANA Considerations ............................................ 3
9. Author's Address ............................................... 3
10. References .................................................... 4

Dover                  Independent Submission                  [Page 2]
RFC 9869                        PMPEP                        April 2024

1. Introduction

One historically useful feature of the internet is hyperlinks, which allow
creators, via URIs[1], to unambiguously specify where to go to find a document
on the internet, and allow clients/readers to take a simple action (like
clicking) to retrieve that document. However, when it comes to internet
communication via email, this functionality does not exist, which forces
creators to resort to roundabout and ad hoc expressions that require some
effort on the part of the recipient. Examples of such workarounds include:

A) "The email you sent Friday around 10:15."

B) "The email with the subject line 'Critical Information' -- the third in
that thread."

C) Adding the downloaded email as an attachment (per RFC 2046[2]).

D) Perhaps infamously, the phrase "per my previous email", for cases when the
recipient has indicated ignorance of the most recent sender-initiated
communication, which, while unambiguous, has become coterminous with "Can't
you <expletive> read?"[3]

PMPEP seeks to address these challenges by providing a structured, easily
parseable format that encapsulates essential email identifiers and metadata,
facilitating direct referencing and retrieval of emails in a manner akin to
web URIs, thus enhancing the efficiency and clarity of email communication.

2. PMPEP Format Specification

The PMPEP identifier is structured as follows:

pmpep://UTCDate=YYYY-MM-DD&UTCTime=HH-MM&Offset=±HHMM&FromTo=encodedEmailAddress
&Subject=encodedSubject&BodyStart=encodedBodyStart

Where:
- pmpep:// indicates the Parsable Mail Pointer Email Protocol.
- UTCDate=YYYY-MM-DD specifies the email's sending date in UTC.
- UTCTime=HH-MM specifies the sending time in UTC.
- Offset=±HHMM reflects the sender's time zone offset from UTC.
- FromTo=encodedEmailAddress is the URL-encoded sender or recipient email
  address.
- Subject=encodedSubject and BodyStart=encodedBodyStart are URL-encoded.

2.1. Example Usage

A typical PMPEP identifier for an email might look like this:

pmpep://UTCDate=2024-03-21&UTCTime=14-55&Offset=-0400&FromTo=jane.doe%40example.com
&Subject=Project%20Update&BodyStart=Please%20find%20attached

This identifier represents an email sent on March 21, 2024, at 14:55 UTC,
with a time zone offset of -0400, from jane.doe@example.com, with the subject
"Project Update" and the body starting with "Please find attached".

Dover                  Independent Submission                  [Page 3]
RFC 9869                        PMPEP                        April 2024

3. Limitations of Message-ID

While the Message-ID of an email is unique and serves as a potentially
reliable identifier, relying on it has practical limitations. Not all email
clients or services provide easy access to or searchability by Message-ID.
Furthermore, the visibility and manipulation of Message-ID may require
technical knowledge beyond that of the average email user, limiting its
utility for general reference purposes. Therefore, PMPEP does not utilize
Message-ID, instead opting for additional, more universally accessible
metadata to ensure wider usability.

4. URL Encoding

To maintain the PMPEP identifier's integrity, special characters within the
FromTo, Subject, and BodyStart components must be URL-encoded as per RFC 3986[4].

5. Usage

PMPEP enables direct and unambiguous referencing of emails, facilitating
communication and documentation in professional and personal contexts. It is
designed for integration into email clients, web applications, and tools
requiring precise email identification.

6. Implementation Notes

Implementers should ensure the generation and decoding of PMPEP identifiers
are supported, accommodating URL-encoded values and providing user-friendly
interfaces for constructing and utilizing PMPEP references.

7. Security Considerations

Sharing PMPEP identifiers should be done with privacy and security in mind,
as they can directly point to specific email content. Users and applications
must consider the implications of sharing such identifiers.

8. IANA Considerations

This document does not require any IANA actions.

9. Author's Address

Benjamin Jeremiah Dover
Email: Benjamin.Jeremiah.Dover@gmail.com

Dover                  Independent Submission                  [Page 4]
RFC 9869                        PMPEP                        April 2024

10. References

[1] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. Available at:
    https://www.rfc-editor.org/rfc/rfc3986
[2] RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media
    Types. Available at: https://emailstuff.org/rfc/2046
[3] Urban Dictionary: "Per my previous email." Available at:
    https://www.urbandictionary.com/define.php?term=per%20my%20previous%20email
[4] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. Describes
    URL encoding methods. Available at:
    https://www.rfc-editor.org/rfc/rfc3986