Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677B7130DC5 for ; Sat, 4 Aug 2018 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLEsJxOSxUs9 for ; Sat, 4 Aug 2018 11:36:01 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382351274D0 for ; Sat, 4 Aug 2018 11:36:01 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id r3-v6so2209002ywc.5 for ; Sat, 04 Aug 2018 11:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=drFdGU8DyK4xJS3EiPFnWIseuIzEvXNK6GGpiq70TS0=; b=vefk3mIw5tCzLF/0bB2ej6ImfKIMVm1lvLM5Sesmv1vqQB0bjE4teahJC6YImohzGM AO7aJWuB3F2R4tKs+N5YOiBiSmYtj1dWeJp+K5DDlJ3Bfwd3jvYYToAN6bzkqVG9QYUD HHMPHbhopMEY0JjS19agGXnDpBQb6dJOyjo7jambb6Gfi6BR1ED2llnkMsOtN9T/9Gro y1zRSlwTewCxr01/f51DvaswpsZFSu1frqgDqGbzhv4fHU1xGVFYB4xrymFg737JGaT4 aV5Qbt4pS3MtVTWRVFuAvAaQGcoRWa4tRBuH+cbl1/rSL0VBq/aq/E/wN9rMjLyCoMde QnjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=drFdGU8DyK4xJS3EiPFnWIseuIzEvXNK6GGpiq70TS0=; b=R+7Ez3eiXq1cqvZ77owm6tGu1vkt0DiVg2GvJLUVxdQTgY1C76fmeJtcAwej3Kpe1o 3qs3KrFdPvrVlRbI98aRj1g8Z/u5unC+m3U8YRb/WOhnECKDj/TN6svTjaMuxo8PqK/+ JqKGeC06weRNBj1oK4NObIaAU9xJY/vx4sRQgzT33bJqXg4UgtP7Et9xfMj3Lw+sSqq1 7+KJH7cBc6YaN1KWTGJLYrWkwu3VLooJhcugHZmd53HeX1DKfnZIi/QlmO1pAwKrKHes Vm/ev5L3MovlIOn8KJFmMl4WIINP30UMGXz+yLQUD7KSmsC6fOlI1PlieRZVhnnWJRhx hWcg== X-Gm-Message-State: AOUpUlH1cK7WRAlaw3FJMCHZtmfis8MvrB7Vfy0dAvEmajXKkA+rayjw Y7W6l49M3Jfn+yypVVwtHsoV8hVO X-Google-Smtp-Source: AAOMgpdLKUJOF7zzn6bsUGcem56pgFIxPaLSJf3yzjsKrSCzWjjqhfk6lVzVkELjAoNZx47A5kRXbA== X-Received: by 2002:a0d:f1c7:: with SMTP id a190-v6mr4841870ywf.321.1533407760138; Sat, 04 Aug 2018 11:36:00 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by smtp.gmail.com with ESMTPSA id k200-v6sm7876321ywe.1.2018.08.04.11.35.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Aug 2018 11:35:59 -0700 (PDT) Message-ID: <5b65f20f.1c69fb81.999ab.7c05@mx.google.com> MIME-Version: 1.0 To: "art@ietf.org" From: Peter Occil Date: Sat, 4 Aug 2018 14:36:01 -0400 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_407F0360-66D7-4AC3-ADF6-63A0C36FDEC5_" Archived-At: Subject: [art] Comments on RFC 6068 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 18:36:05 -0000 --_407F0360-66D7-4AC3-ADF6-63A0C36FDEC5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The following are comments on RFC 6068, the mailto URI specification. I. Use of "quoted-string" in mailto URIs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Although RFC6068 inherits the production "quoted-string" from RFC 5322, the= probable intent of that import is not to use any obsolete syntax, whitespa= ce, or comments allowed in that production. For example: 1. Section 2, point 2 refers to "". An existing erratum change= d it to "". 2. "quoted-string" contains WSP inside the quotes. A reported erratum see= ks 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 d= iscussion on whether that change is worthwhile for the local part is needed= . In any case, local parts with whitespace are extremely rare, if they exi= st at all. 3. "quoted-string" contains "obs-qp" which allows %d0, CR, LF, to follow t= he backslash. Although CR and LF are whitespace, it's hard to call %d0 whi= tespace too. I think a future update to RFC 6068 should disallow "= " in addition to "" and "". II. Exact listing of ignored header fields =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 thi= s 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-Re= port-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, Li= st-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 hea= der 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 sup= port internationalized email; therefore I consider these to be fields "rela= ted to routing") Downgraded-Bcc, Downgraded-Cc, Downgraded-Disposition-Notification, Downgra= ded-Final-Recipient, Downgraded-From, Downgraded-In-Reply-To, Downgraded-Ma= il-From, Downgraded-Message-Id, Downgraded-Original-Recipient, Downgraded-Rcpt-To, D= owngraded-References, Downgraded-Reply-To, Downgraded-Resent-Bcc, Downgrade= d-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, Incom= plete-Copy, Message-Type, Discarded-X400-IPMS-Extensions, Language, Content= -Identifier, X400-Content-Identifier, Conversion, Conversion-With-Loss, Del= ivery-Date, Discarded-X400-MTS-Extensions, DL-Expansion-History, Message-Ty= pe, X400-Content-Type, X400-MTS-Identifier, X400-Recipients D. Instructions for recipients to follow, or hints to recipients or transpo= rt agents Sensitivity (used in MIXER and RFC 3801), VBR-Info, Require-Recipient-Valid= -Since, Disposition-Notification-To, Disposition-Notification-Options, Soli= citation, Accept-Language, EDIINT-Features, X-Trasporto, X-TipoRicevuta, Fo= rm-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-Recipien= ts, X400-Content-Return, Generate-Delivery-Report, Prevent-NonDelivery-Repo= rt F. Miscellaneous MT-Priority, Original-Message-ID 3. Trace fields Received, Return-Path, Received-Spf, Authentication-Results, Arc-Authentica= tion-Results, Dkim-Signature, Arc-Seal, Arc-Message-Signature, Errors-To, S= IO-Label-History A. MIXER trace fields X400-Received, X400-Trace, Deferred-Delivery, Latest-Delivery-Time, X400-MT= S-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 regi= stry) 5. Not specifically covered in categories 1-4, but related to those categor= ies. 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 an= d/or a body and is not sent automatically) X-VerificaSicurezza, X-Riferimento-Message-ID, X-Ricevuta (Italian PEC head= er fields -- mostly fields added by servers, not user agents) ---------------------------------------------- Which leaves a relatively small selection of header fields that I have cate= gorized 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 Referen= ces 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, Pr= ivicon, Eesst-Version (Especially Importance is one setting that at least one mail user agent I h= ave seen allows users to set on messages they compose. Encrypted doesn't qu= ite fit categories 1 to 5, but is definitely a "suspect" header field. Mes= sage context and Encrypted are relatively useless because the disallowance = of MIME header fields means that mailto messages can be plain text only.) --------------- --Peter --_407F0360-66D7-4AC3-ADF6-63A0C36FDEC5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

The following are comments on RFC 60= 68, the mailto URI specification.

 =

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

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

 

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

&nbs= p;

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

 

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

 

 

II. Exact listing of ignored header fields

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Section 3 says:

=  

=C2=A0 Originator fields like Fro= m and Date, fields related to routing

=C2=A0 (Appar= ently-To, Resent-*, etc.), trace fields, and MIME header fields

=C2=A0 (MIME-Version, Content-*), when present in the URI, MUS= T be ignored.

 

To make this more precise, I have categorized all header fields meetin= g this definition (and have the protocol "mail" or "MIME&quo= t; 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 (serv= e to identify a mailing list)

 

=

List-Archive, List-Help, List-ID, List-Owner, List-Pos= t, List-Subscribe, List-Unsubscribe, List-Unsubscribe-Post

 

MAYBE: Archived-At, X-Arc= hived-At

 

= 2. "Fields related to routing"

 = ;

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

<= o:p> 

- that are added by a sender as in= structions for recipients to follow, or

- that iden= tify that a message is being reintroduced, or

- tha= t are byproducts of message conversion by a gateway.

 

A. Specifically identified as s= uch

 

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

&= nbsp;

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

 

Downgraded-Bcc, Down= graded-Cc, Downgraded-Disposition-Notification, Downgraded-Final-Recipient,= Downgraded-From, Downgraded-In-Reply-To, Downgraded-Mail-From,

Downgraded-Message-Id, Downgraded-Original-Recipient, Downgrad= ed-Rcpt-To, Downgraded-References, Downgraded-Reply-To, Downgraded-Resent-B= cc, Downgraded-Resent-Cc, Downgraded-Resent-From, Downgraded-Resent-Reply-T= o, Downgraded-Sender, Downgraded-Resent-Sender, Downgraded-Resent-To, Downg= raded-Return-Path, Downgraded-Sender, Downgraded-To

 

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

&= nbsp;

Supersedes, Obsoletes, Expires, Expiry-= Date, Reply-By, Autoforwarded, Incomplete-Copy, Message-Type, Discarded-X40= 0-IPMS-Extensions, Language, Content-Identifier, X400-Content-Identifier, C= onversion, Conversion-With-Loss, Delivery-Date, Discarded-X400-MTS-Extensio= ns, DL-Expansion-History, Message-Type, X400-Content-Type, X400-MTS-Identif= ier, X400-Recipients

 

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

 

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

 

E. Sieve message replacement

&nbs= p;

Original-From, Original-Subject

 

F. MMHS header fiel= ds (all starting with "MMHS-")

 = ;

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

 

X400-Content-Return, Content-Return, Alternate-Recipient, Dis= close-Recipients, X400-Content-Return, Generate-Delivery-Report, Prevent-No= nDelivery-Report

 

F. Miscellaneous

 

MT-Priority, Original-Message-ID

 

3. Trace fields

 

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

 

A. MIXER trace field= s

 

X400-Re= ceived, X400-Trace, Deferred-Delivery, Latest-Delivery-Time, X400-MTS-Ident= ifier, X400-Recipients, Original-Encoded-Information-Types

 

B. Only used in delivery = status and disposition notifications

 

Original-Recipient

 

4. MIME fields (All fields with proto= col "MIME" in the message headers registry)

 

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

<= o:p> 

Encoding (Similar to Content-Type = or Content-Transfer-Encoding)

Auto-Submitted, Autos= ubmitted (Not relevant to current practice involving "mailto" URI= s, 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)

&nb= sp;

-----------------------------------------= -----

 

Whi= ch leaves a relatively small selection of header fields that I have categor= ized 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.=C2=A0= Namely, In-Reply-To and References rely on importing header fields from ex= isting messages, and Message-ID needs to be newly generated for each messag= e.)

 

9. Mi= scellaneous.

 

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

 

(Especially Importance is one setting that at least one ma= il user agent I have seen allows users to set on messages they compose. Enc= rypted doesn't quite fit categories 1 to 5, but is definitely a "suspe= ct" header field.=C2=A0 Message context and Encrypted are relatively u= seless because the disallowance of MIME header fields means that mailto mes= sages can be plain text only.)

 

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

 

--Peter

= --_407F0360-66D7-4AC3-ADF6-63A0C36FDEC5_--