Subject: [art] Comments on RFC 6068

From: Peter Occil <[email-masked]>
Date: Sat, 4 Aug 2018 14:36:01 -0400

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Aug 2018 14:57:43 -0400

Peter,

What you appear to be proposing here is not a clarification or
questions about RFC 6068, but a rather extensive revision/
replacement.  Without getting into how I feel about the various
changes you have suggested other than to say that I'm more
enthused about some than others, I don't think you are going to
get a useful discussion of this, much less the sort of evidence
of consensus that would taken it anywhere, when the ideas are
presented in the form of an email message.  Consequently, please
take the next step and prepare an Internet-Draft that either
updates or replaces RFC 6068 and let's see if people want to
engage with that.

In thinking about that, please have a look at RFC 6530ff (the
SMTPUTF8, aka "EAI", specs).  It is not clear to me whether a
6068 revision should be undertaken without addressing non-ASCII
addresses and headers.  If you think it should, you might want
to save time by explaining why in your I-D.

best,
   john

--On Saturday, August 4, 2018 14:36 -0400 Peter Occil
<[email-masked]> wrote:

> 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:
> 
> 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>".
> 
> 
>   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
> 
> List-Archive, List-Help, List-ID, List-Owner, List-Post,
> List-Subscribe, List-Unsubscribe, List-Unsubscribe-Post
> 
> - 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.
> 
> 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
> 
> 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
> 
> 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
> 
> X400-Content-Return, Content-Return, Alternate-Recipient,
> Disclose-Recipients, X400-Content-Return,
> Generate-Delivery-Report, Prevent-NonDelivery-Report
> 
> F. Miscellaneous
> 
> 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
> 
> 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)
> 
> (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.
> 
> (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

---

From: Peter Occil <[email-masked]>
Date: Sat, 4 Aug 2018 15:39:04 -0400

The two sections I made are, rather, largely requests for clarification.  I abridge my previous message to give just those requests:

Is "quoted-string" in mailto URIs (after percent decoding) intended to allow whitespace within the quotation marks or the obsolete syntax in the "obs-qp" production?

In the cited text of section 3, exactly which header fields are considered "originator fields"?  What is a "fiel[d] related to routing", exactly?  My previous message gave one interpretation; is that interpretation consistent with the intended scope of those phrases?

--Peter

From: John C Klensin
Sent: Saturday, August 4, 2018 2:57 PM
To: Peter Occil; [email-masked]
Subject: Re: [art] Comments on RFC 6068

Peter,

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Aug 2018 17:07:04 -0400

Peter,

Your clarification doesn't really change my answer.  Unless you
can convince people that the text that you believe requires
clarification are simple and obvious errors, responses from this
list are not going to do you a lot of good.  Let me take just
your first case/request as an example...

--On Saturday, August 4, 2018 15:39 -0400 Peter Occil
<[email-masked]> wrote:

> The two sections I made are, rather, largely requests for
> clarification.  I abridge my previous message to give just
> those requests:
> 
> Is "quoted-string" in mailto URIs (after percent decoding)
> intended to allow whitespace within the quotation marks or the
> obsolete syntax in the "obs-qp" production?

As far as addresses in that context are concerned, you may get
responses from the list as to whether including whitespace in
that way is sensible (I personally believe that whitespace has
caused enough problems in actual mailbox names (what RFC 5322
and 6068 call <addr-spec>) and  that, despite its having some
legitimate uses, we should have deprecated it long ago and it is
clear to me that Section 4.4 of RFC 5322 attempts to do that),
but I can just about guarantee that some people, possibly for
historical reasons, have chosen to allow it and that others,
perhaps by accident or by conformance to 822 or 2822, have
chosen not to.  

Here, despite the efforts of at least some IAB members to do
away with it (see draft-thomson-postel-was-wrong) is where the
robustness principle comes in.  If someone is responsible for
specifying mailbox names that might have to be encoded in a
MAILTO URI, allowing whitespace in the local-part is probably
just looking for trouble.  By contrast, if one is validating a
MAILTO URI or passing the information it contains into the mail
system, one needs to accept these thing because they are valid
(in the mail system) and not accepting them is a recipe for
angry calls and complaints from users.

Of course, if your question also applies to hfvalue elements,
the logical answer is rather more clear if looked at from the
standpoint of the relevant mail protocols, notably RFC 5322,
because forcing

 MAILTO:[email-masked]?Subject="RE:CommentsonRFC6068"

rather that allowing

 MAILTO:[email-masked]?Subject="RE:%20Comments%20on%20RFC%2060
68"

would probably not make anyone happy, but, as I read it, the
prose part of Section 2 of 6068 is rather clear about that.

It seems to me that, if any of the above really needs
clarification sufficient for you to point to the standards-track
RFCs and say, with great confidence "I am justified in doing (or
not doing) XYZ", then no amount of agreement on this or any
other IETF list is going to do you any good because we just
don't clarify, or formally interpret, standards track
specifications that way.  Instead, we issue new documents that
remove the perceived ambiguity.  And that takes my back to the
suggestion that you generate an Internet Draft in my earlier
note.

    best,
     john

---

From: Peter Occil <[email-masked]>
Date: Sat, 4 Aug 2018 18:26:45 -0400

My previous two messages are withdrawn, except that the observations I made about header fields may be useful when work begins on a future update to RFC 6068 (which I don't imply will happen soon).  In that sense, those observations are currently "for your information".

--Peter

From: John C Klensin
Sent: Saturday, August 4, 2018 5:07 PM
To: Peter Occil; [email-masked]
Subject: RE: [art] Comments on RFC 6068

Peter,

rather that allowing

    best,
     john