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 E5448130E19 for ; Sat, 4 Aug 2018 15:26:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GnYzUwDGTpdf for ; Sat, 4 Aug 2018 15:26:45 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 382F5130E14 for ; Sat, 4 Aug 2018 15:26:45 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id l16-v6so3971920ybk.11 for ; Sat, 04 Aug 2018 15:26:45 -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:in-reply-to :references; bh=BEkA7zT2hmqo/ztFqnhyhsuaaP2Msgw0K8/FblxTyh0=; b=AmPxrKaFJ/cnOCrUgjMUFxxHpl7t+Ya1GWSJuvViXraxujnLjiECZfpdGvuAUZiz8b GzivTm89UnV7irrb8awnE+UvCdjbzS/AdaddpH1OvM75UchP7I86MOLRyWnl03n3ZKGu wPcFbzZ99txKECFmgHHId5ZqiirnvXBv+SJA2EE2mSTDYgiN5LtXjdRA1ZDJ8bPl/wD1 ql4PW1qaAswd3v2J4RlWWsG3h7Aqdvj9pRJR+Qj+InFLPzu22xeWk2cQsY8N245nbKX+ TQmTXXr3DNh0YkGG+4m3us29rbxtYTE/fG2DMAtZZ6Ah153roxTJvAPxTJB0HTVn6xNB 5aSw== 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:in-reply-to:references; bh=BEkA7zT2hmqo/ztFqnhyhsuaaP2Msgw0K8/FblxTyh0=; b=a8CCqaYn5EX09Hg447bPKt+0SRy+h++AzT9ORdLceh53pYpykvFN35RYjLkz3j9Wjk KtBXbgMjiI6WAAzcwQ5K5NMA6/QtFEVcM1h0Y7f+1zEDLhH3BvLqD1dPl5W52ks0NpuW BOfVgUI/yeLdqIf5UYlzM39r9pmN/xS7OjIBMhTZMPh6AOzPSCj5RjCVXJ2NctgHIi+s rVa4mD0RhxpMtysllbdYv8AxruXL+Ic0ooVUXpa5c736DprDJnEm1HcKqhmDK0husCu0 pFqdk6Ne9sKKSSBS3jp8ckNHGhKS0kQYaO4qXMHXxPXG/NOKvucKiDQ5xi7r4Za3UBdO wAEQ== X-Gm-Message-State: AOUpUlFtLFuvLQiuWUlAKvi8ESfhQiwXSOeJAQmH6Qm66BiKfXSSEaCv RLtRwyG+x7HgM5mPksYe4yA= X-Google-Smtp-Source: AAOMgpfcbR3FajKVJe4F5TPxxNq+UwG3l9MOWGph9fuZiTDg82oF4yjGTwp+SarkQfR3B2xuIqr4tA== X-Received: by 2002:a25:774f:: with SMTP id s76-v6mr4937975ybc.192.1533421604351; Sat, 04 Aug 2018 15:26:44 -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 m82-v6sm10918589ywm.19.2018.08.04.15.26.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Aug 2018 15:26:43 -0700 (PDT) Message-ID: <5b662823.1c69fb81.5ce4c.ac8c@mx.google.com> MIME-Version: 1.0 To: John C Klensin , "art@ietf.org" From: Peter Occil Date: Sat, 4 Aug 2018 18:26:45 -0400 Importance: normal X-Priority: 3 In-Reply-To: <1873BA2AE452113B85FCE6B5@PSB> References: <5b65f20f.1c69fb81.999ab.7c05@mx.google.com> <1D41FD4024188A6AFE2AE060@PSB> <5b6600d6.1c69fb81.9ff3a.333d@mx.google.com> <1873BA2AE452113B85FCE6B5@PSB> Content-Type: multipart/alternative; boundary="_63883EF7-5D9B-4D23-BEBA-86F45E490105_" Archived-At: Subject: Re: [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 22:26:47 -0000 --_63883EF7-5D9B-4D23-BEBA-86F45E490105_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 R= FC 6068 (which I don't imply will happen soon). In that sense, those obser= vations are currently "for your information". --Peter From: John C Klensin Sent: Saturday, August 4, 2018 5:07 PM To: Peter Occil; art@ietf.org Subject: RE: [art] Comments on RFC 6068 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 wrote: > The two sections I made are, rather, largely requests for > clarification. I abridge my previous message to give just > those requests: >=20 > I. Use of "quoted-string" in mailto URIs >=20 > 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 ) 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. =20 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:poccil14@gmail.com?Subject=3D"RE:CommentsonRFC6068" rather that allowing MAILTO:poccil14@gmail.com?Subject=3D"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 --_63883EF7-5D9B-4D23-BEBA-86F45E490105_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

My previous two messages are withdra= wn, except that the observations I made about header fields may be useful w= hen work begins on a future update to RFC 6068 (which I don't imply will ha= ppen soon).=C2=A0 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; art@ietf.org
Subject: RE: [art] Comments on RFC 6068

=

 

Peter,=

 

Your cla= rification doesn't really change my answer.=C2=A0 Unless you

can convince people that the text that you believe requires

clarification are simple and obvious errors, responses f= rom this

list are not going to do you a lot of good= .=C2=A0 Let me take just

your first case/request as= an example...

 

--On Saturday, August 4, 2018 15:39 -0400 Peter Occil

<poccil14@gmail.com> wrote:

&nb= sp;

> The two sections I made are, rather,= largely requests for

> clarification.=C2=A0 I a= bridge my previous message to give just

> those = requests:

>

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

> <= /p>

> Is "quoted-string" in mailto URIs (a= fter percent decoding)

> intended to allow white= space within the quotation marks or the

> obsole= te 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 s= ensible (I personally believe that whitespace has

c= aused enough problems in actual mailbox names (what RFC 5322

and 6068 call <addr-spec>) and=C2=A0 that, despite its havi= ng 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 ab= out guarantee that some people, possibly for

histor= ical reasons, have chosen to allow it and that others,

perhaps by accident or by conformance to 822 or 2822, have

chosen not to.=C2=A0

 

Here, despite the efforts of at least some IAB me= mbers to do

away with it (see draft-thomson-postel-= was-wrong) is where the

robustness principle comes = in.=C2=A0 If someone is responsible for

specifying = mailbox names that might have to be encoded in a

MA= ILTO URI, allowing whitespace in the local-part is probably

just looking for trouble.=C2=A0 By contrast, if one is validating = a

MAILTO URI or passing the information it contains= into the mail

system, one needs to accept these th= ing 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 protoc= ols, notably RFC 5322,

because forcing

 

MAILTO:poccil14@gma= il.com?Subject=3D"RE:CommentsonRFC6068"

<= o:p> 

rather that allowing

 

MAILTO:poccil14@gma= il.com?Subject=3D"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

clarific= ation 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 a= ny good because we just

don't clarify, or formally = interpret, standards track

specifications that way.= =C2=A0 Instead, we issue new documents that

remove = the perceived ambiguity.=C2=A0 And that takes my back to the

suggestion that you generate an Internet Draft in my earlier

<= p class=3DMsoNormal>note.

 

=C2=A0=C2=A0=C2=A0 best,

=C2=A0=C2= =A0=C2=A0=C2=A0 john

 

 

 

= --_63883EF7-5D9B-4D23-BEBA-86F45E490105_--