Re: [art] Comments on RFC 6068

[John C Klensin <[e-mail]>]

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
<[e-mail]> wrote:

> 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