[art] Comments on RFC 6068
Peter Occil <poccil14@gmail.com> Sat, 04 August 2018 18:36 UTC
Return-Path: <poccil14@gmail.com>
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 <art@ietfa.amsl.com>; 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 <art@ietfa.amsl.com>; 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 <art@ietf.org>; Sat, 4 Aug 2018 11:36:01 -0700 (PDT)
Received: by mail-yw1-xc29.google.com with SMTP id r3-v6so2209002ywc.5 for <art@ietf.org>; 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 <art@ietf.org> (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" <art@ietf.org>
From: Peter Occil <poccil14@gmail.com>
Date: Sat, 04 Aug 2018 14:36:01 -0400
Importance: normal
X-Priority: 3
Content-Type: multipart/alternative; boundary="_407F0360-66D7-4AC3-ADF6-63A0C36FDEC5_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/NgqIpE63Z1GHfnFtg43wBMruJe8>
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 <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Aug 2018 18:36:05 -0000
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
- [art] Comments on RFC 6068 Peter Occil
- Re: [art] Comments on RFC 6068 John C Klensin
- Re: [art] Comments on RFC 6068 Peter Occil
- Re: [art] Comments on RFC 6068 John C Klensin
- Re: [art] Comments on RFC 6068 Peter Occil