Subject: [art] Comments on RFC 6068
From: Peter Occil <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sat, 4 Aug 2018 14:36:01 -0400
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>

The following are comments on RFC 6068, the mailto URI specification.

I. Use of "quoted-string" in mailto URIs
==============

Although RFC6068 inherits the production "quoted-string" from RFC 5322, the probable intent of that import is not to use any obsolete syntax, whitespace, or comments allowed in that production.  For example:

1.  Section 2, point 2 refers to "<NO-WS-CTL>".  An existing erratum changed it to "<obs-NO-WS-CTL>".

2.  "quoted-string" contains WSP inside the quotes.  A reported erratum seeks to change point 3 to allow that whitespace, but that report hasn't been resolved yet.  I don't agree with that erratum for the domain part, but a discussion on whether that change is worthwhile for the local part is needed.  In any case, local parts with whitespace are extremely rare, if they exist at all.

3.  "quoted-string" contains "obs-qp" which allows %d0, CR, LF, to follow the backslash.  Although CR and LF are whitespace, it's hard to call %d0 whitespace too.  I think a future update to RFC 6068 should disallow "<obs-qp>" in addition to "<obs-local-part>" and "<obs-NO-WS-CTL>".

II. Exact listing of ignored header fields
============

Section 3 says:

  Originator fields like From and Date, fields related to routing
  (Apparently-To, Resent-*, etc.), trace fields, and MIME header fields
  (MIME-Version, Content-*), when present in the URI, MUST be ignored.

To make this more precise, I have categorized all header fields meeting this definition (and have the protocol "mail" or "MIME" in the message headers registry) as follows.

1. "Originator fields"

From, Date, Sender, Reply-To, X400-Originator, TLS-Report-Submitter, TLS-Report-Domain, Originator-Return-Address, Jabber-ID, X-Mittente, Organization

A. List fields (serve to identify a mailing list)

List-Archive, List-Help, List-ID, List-Owner, List-Post, List-Subscribe, List-Unsubscribe, List-Unsubscribe-Post

MAYBE: Archived-At, X-Archived-At

2. "Fields related to routing"

This is a relatively vague category.  I interpret this category to mean header fields--

- that are added by a sender as instructions for recipients to follow, or
- that identify that a message is being reintroduced, or
- that are byproducts of message conversion by a gateway.

A. Specifically identified as such

Resent-To, Resent-Sender, Resent-Reply-To, Resent-Message-ID, Resent-From, Resent-Date, Resent-Cc, Resent-Bcc, Apparently-To

B. Downgraded header fields (to accommodate POP/IMAP clients that don't support internationalized email; therefore I consider these to be fields "related to routing")

Downgraded-Bcc, Downgraded-Cc, Downgraded-Disposition-Notification, Downgraded-Final-Recipient, Downgraded-From, Downgraded-In-Reply-To, Downgraded-Mail-From,
Downgraded-Message-Id, Downgraded-Original-Recipient, Downgraded-Rcpt-To, Downgraded-References, Downgraded-Reply-To, Downgraded-Resent-Bcc, Downgraded-Resent-Cc, Downgraded-Resent-From, Downgraded-Resent-Reply-To, Downgraded-Sender, Downgraded-Resent-Sender, Downgraded-Resent-To, Downgraded-Return-Path, Downgraded-Sender, Downgraded-To

C. MIXER Conversion fields (for converting X.400 messages to MIME messages):

Supersedes, Obsoletes, Expires, Expiry-Date, Reply-By, Autoforwarded, Incomplete-Copy, Message-Type, Discarded-X400-IPMS-Extensions, Language, Content-Identifier, X400-Content-Identifier, Conversion, Conversion-With-Loss, Delivery-Date, Discarded-X400-MTS-Extensions, DL-Expansion-History, Message-Type, X400-Content-Type, X400-MTS-Identifier, X400-Recipients

D. Instructions for recipients to follow, or hints to recipients or transport agents

Sensitivity (used in MIXER and RFC 3801), VBR-Info, Require-Recipient-Valid-Since, Disposition-Notification-To, Disposition-Notification-Options, Solicitation, Accept-Language, EDIINT-Features, X-Trasporto, X-TipoRicevuta, Form-Sub

E. Sieve message replacement

Original-From, Original-Subject

F. MMHS header fields (all starting with "MMHS-")

G. Extensions for RFC 822 to X.400 (see also RFC 2156 section 3):

X400-Content-Return, Content-Return, Alternate-Recipient, Disclose-Recipients, X400-Content-Return, Generate-Delivery-Report, Prevent-NonDelivery-Report

F. Miscellaneous

MT-Priority, Original-Message-ID

3. Trace fields

Received, Return-Path, Received-Spf, Authentication-Results, Arc-Authentication-Results, Dkim-Signature, Arc-Seal, Arc-Message-Signature, Errors-To, SIO-Label-History

A. MIXER trace fields

X400-Received, X400-Trace, Deferred-Delivery, Latest-Delivery-Time, X400-MTS-Identifier, X400-Recipients, Original-Encoded-Information-Types

B. Only used in delivery status and disposition notifications

Original-Recipient

4. MIME fields (All fields with protocol "MIME" in the message headers registry)

5. Not specifically covered in categories 1-4, but related to those categories.

Encoding (Similar to Content-Type or Content-Transfer-Encoding)
Auto-Submitted, Autosubmitted (Not relevant to current practice involving "mailto" URIs, where a message is prepopulated with certain header fields and/or a body and is not sent automatically)
X-VerificaSicurezza, X-Riferimento-Message-ID, X-Ricevuta (Italian PEC header fields -- mostly fields added by servers, not user agents)

----------------------------------------------

Which leaves a relatively small selection of header fields that I have categorized as follows:

6. Destination fields.

To, Cc, Bcc

7. Information fields.

Subject, Comments, Keywords

8. Identification fields.

Message-ID, In-Reply-To, References

(All three may be useless for mailto URIs.  Namely, In-Reply-To and References rely on importing header fields from existing messages, and Message-ID needs to be newly generated for each message.)

9. Miscellaneous.

PICS-Label, Importance, Priority, Encrypted, Message-Context, SIO-Label, Privicon, Eesst-Version

(Especially Importance is one setting that at least one mail user agent I have seen allows users to set on messages they compose. Encrypted doesn't quite fit categories 1 to 5, but is definitely a "suspect" header field.  Message context and Encrypted are relatively useless because the disallowance of MIME header fields means that mailto messages can be plain text only.)

---------------

--Peter