From nobody Sat May 3 09:52:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7671A00ED for ; Sat, 3 May 2014 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 YNJIqQKGdhIO for ; Sat, 3 May 2014 09:52:10 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E91A00E4 for ; Sat, 3 May 2014 09:52:09 -0700 (PDT) Received: from [192.168.2.107] (p57BC5AE5.dip0.t-ipconnect.de [87.188.90.229]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LpeUg-1XJn8N2O18-00fVcq; Sat, 03 May 2014 18:52:05 +0200 From: Jan Algermissen Content-Type: multipart/alternative; boundary="Apple-Mail=_9DDA3A8A-7012-4183-8252-8829AAFE95F1" Message-Id: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> Date: Sat, 3 May 2014 18:52:03 +0200 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Provags-ID: V02:K0:iQ+AymIwhtagqQfXz/0a2i/gKe4fxmO+VDuwQGe/Llu M40MaZgpR4vCjPl8QwYR2kZc/Hfm49TTqN5/i8UcI++CPeJm/l pok3cFB1HRP0LuVuPnt8ZPZ85M5+U0VDnKCq7JHKAYRHJtzGeM 3LDkIHApHMVD4fTvIuYr5WRmIBZIgFEDRoi/r31tKvBCV1wa5N O41LHrA2+J+616VYoGofmYXZHFu2GurCmL+r0qaUWgrrY429zM dZ2fZVumFnTgDYthy6oLTlvZhI6nLL3vgcRVIcvsPpBRbXxMlh jXLaLWW6G2Hc/f2FBVpvBD9w/TgcK6P4YasjiqJiyqw11OGGBQ xhLbVAAPfMGnfW9HVrYMjPOqV+m+96UIiCQKMqFBi3gzWFQ7oR 9leUsGX/iz40g== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3aFQtxAE8dl4puyHrdK1FCh9TJg Subject: [apps-discuss] RelaxNG for JSON? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 16:52:11 -0000 --Apple-Mail=_9DDA3A8A-7012-4183-8252-8829AAFE95F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, is there an adaption of RelaxNG for JSON? This seems such an obvious thing to do, I was shocked that searches = yield no really good answers. All I found so far: = https://www.ibm.com/developerworks/community/blogs/jasnell/entry/relax_ng_= compact_for_json29?lang=3Den https://github.com/eteeselink/relax-json Jan= --Apple-Mail=_9DDA3A8A-7012-4183-8252-8829AAFE95F1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

is there an adaption of RelaxNG for JSON?

This seems such an obvious thing to do, I was shocked that searches yield no really good answers.


All I found so far:


Jan
--Apple-Mail=_9DDA3A8A-7012-4183-8252-8829AAFE95F1-- From nobody Sat May 3 11:40:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F81A010E for ; Sat, 3 May 2014 11:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nF3WhE8dnHYQ for ; Sat, 3 May 2014 11:40:28 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2161A00F1 for ; Sat, 3 May 2014 11:40:28 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so3817277wib.10 for ; Sat, 03 May 2014 11:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ygD5Z4XZnFvLWrySUFiNwRVPoN0DY5a+eHeBblP4DWY=; b=LH2e4wmC+hXwj5lf3NMvS67gYuVrVrTsGKP6Eq28T0kydizpY07Qqc+9LGl1cwC+tN lYfZbrLrO7e/QFhovog/WOpw7KDKOX8Pn1yw5hFU8xnafpP4sOKR/9+Sjy0RAUsemyCi kbVmoiyabUno6sXCfXJC9MYox5nkv6IRo0LRvwIggQRg9lR2G7A3ZILMFOua98iToRK1 DYPrGqnjKp8gNddPCxWgf6sGYIEFuFuwjFyswWItMo0C0MnEh+wKXVmnzCegDvDw+Wt5 NzrldFMkTXyyRTRJ6yswiqk3s2W8tlrxZxqH+laskeE/KpZ2KdmSpbpk5ULV/oljkX8H YFtw== MIME-Version: 1.0 X-Received: by 10.180.94.37 with SMTP id cz5mr8535772wib.19.1399142425182; Sat, 03 May 2014 11:40:25 -0700 (PDT) Received: by 10.216.223.68 with HTTP; Sat, 3 May 2014 11:40:25 -0700 (PDT) Received: by 10.216.223.68 with HTTP; Sat, 3 May 2014 11:40:25 -0700 (PDT) In-Reply-To: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> References: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> Date: Sat, 3 May 2014 11:40:25 -0700 Message-ID: From: James M Snell To: Jan Algermissen Content-Type: multipart/alternative; boundary=f46d04426c2c3e4b0204f8833b91 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xj_sToEAcRffSxzWA8Z07_odVE8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RelaxNG for JSON? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 18:40:30 -0000 --f46d04426c2c3e4b0204f8833b91 Content-Type: text/plain; charset=UTF-8 Would love to get something going on this but never saw any interest. On May 3, 2014 9:52 AM, "Jan Algermissen" wrote: > Hi, > > is there an adaption of RelaxNG for JSON? > > This seems such an obvious thing to do, I was shocked that searches yield > no really good answers. > > > All I found so far: > > > https://www.ibm.com/developerworks/community/blogs/jasnell/entry/relax_ng_compact_for_json29?lang=en > https://github.com/eteeselink/relax-json > > Jan > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04426c2c3e4b0204f8833b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Would love to get something going on this but never saw any = interest.

On May 3, 2014 9:52 AM, "Jan Algermissen&qu= ot; <jan.algermissen@nords= c.com> wrote:
Hi,

is there an adap= tion of RelaxNG for JSON?

This seems such an obvio= us thing to do, I was shocked that searches yield no really good answers.


All I found so far:

=

Jan<= /div>

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04426c2c3e4b0204f8833b91-- From nobody Sat May 3 12:00:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B91A0173 for ; Sat, 3 May 2014 12:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no 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 QxocxrsD5UYh for ; Sat, 3 May 2014 12:00:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 15E931A015A for ; Sat, 3 May 2014 12:00:24 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E01BE13FA79; Sat, 3 May 2014 21:00:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399143621; bh=tRSpXKJ5bfNjPRVkUH2ACG3aKclZ+1I28ezpc5ixwvk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=na2o8aOD3LRGBHi7dyMgBsmC6oXUKpezT993HP63oe4fzbcvOdiN+kbb1Q5anPsNf hKP/8+7j9uzqtWXnfuRUM8jNJqyTUvLAd2/GTo09JE+NpTvqRIkTNdHw9IljgxjQfM DspZ5XeicCR+HJFpBKyE08+439K8WXH3i43DrfnU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> Date: Sat, 3 May 2014 21:00:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9EBC0F7E-0F17-4E0C-B2BD-ABAFD85A6182@nic.cz> References: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XiX1IhmMTTEHfQh-bY9ALf2GL9Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RelaxNG for JSON? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 19:00:26 -0000 On 03 May 2014, at 18:52, Jan Algermissen = wrote: > Hi, >=20 > is there an adaption of RelaxNG for JSON? >=20 > This seems such an obvious thing to do, I was shocked that searches = yield no really good answers. FWIW, NETMOD WG is working towards using YANG for modelling = configurations and state data expressed in JSON - see = draft-ietf-netmod-yang-json-00. Lada >=20 >=20 > All I found so far: >=20 > = https://www.ibm.com/developerworks/community/blogs/jasnell/entry/relax_ng_= compact_for_json29?lang=3Den > https://github.com/eteeselink/relax-json >=20 > Jan > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun May 4 02:44:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2841A004D for ; Sun, 4 May 2014 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 va9qaZpr4YdA for ; Sun, 4 May 2014 02:44:02 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF591A004C for ; Sun, 4 May 2014 02:44:02 -0700 (PDT) Received: from [192.168.2.107] (p57BC5AE5.dip0.t-ipconnect.de [87.188.90.229]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0MY20C-1WL0Un48A4-00UsHT; Sun, 04 May 2014 11:43:58 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_C345837B-8759-4504-9CAF-DC33C0ABC673" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jan Algermissen In-Reply-To: Date: Sun, 4 May 2014 11:43:26 +0200 Message-Id: <422AD850-7048-4187-B00D-F24394A23A92@nordsc.com> References: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> To: James M Snell X-Mailer: Apple Mail (2.1874) X-Provags-ID: V02:K0:CtbPjusRMypzn9Qqqc7caHZaIGJRIquJI/jmuHYFzA2 G+Y5/msu7sEv3vNfl3pHXsOATn4MLhI6x4OevDKnG6ZQFxzErm zmpF3P0LNzH5UAHmSrELT0R8q7kycz1+QCW1HLh71lOqLBdRUI pYd+CgvBhNtDWJ77Loxs+DcECGkIrXQeHUT49ymX792HydZKps eo04ud3yZ6i48zZuhsmfaEc8cD7jIgrGcQoGXejHckNBEN4y8Q sEMGy1XhMeII9zIU3cMIeae35Lp3AkujSeK0KSzW8Yu7cbR3ri YWQZhOrTLntWoS0b0HhuZ54X0w3QCWeBnfSdN7gmjKtFuvnHA/ XVjVVG8+bVujQyVxnIsfw/zPSYK8O3/UgXl20QMUte03oMVZcC gNWgv2ZLO5MTQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JJ7mGUA6jLVFaROEzWjKx7hGOIs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RelaxNG for JSON? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 09:44:04 -0000 --Apple-Mail=_C345837B-8759-4504-9CAF-DC33C0ABC673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 03 May 2014, at 20:40, James M Snell wrote: > Would love to get something going on this but never saw any interest. >=20 I used to just describe the JSON in my media types, but now I am facing = a larger one and hence feel the need. I am mostly interested in a stable model/syntax for documentation = purposes, validation tools would be second on my list. I=92ll dig through your posting and come back with ideas/comments and = hopefully it won=92t be long to throw together an initial version. Have you seen: https://github.com/eteeselink/relax-json I found that pretty slick on first glance. Thanks, Jan > On May 3, 2014 9:52 AM, "Jan Algermissen" = wrote: > Hi, >=20 > is there an adaption of RelaxNG for JSON? >=20 > This seems such an obvious thing to do, I was shocked that searches = yield no really good answers. >=20 >=20 > All I found so far: >=20 > = https://www.ibm.com/developerworks/community/blogs/jasnell/entry/relax_ng_= compact_for_json29?lang=3Den > https://github.com/eteeselink/relax-json >=20 > Jan >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_C345837B-8759-4504-9CAF-DC33C0ABC673 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 03 May 2014, at = 20:40, James M Snell <jasnell@gmail.com> = wrote:

Would love to get something going on this = but never saw any interest.

I used to just = describe the JSON in my media types, but now I am facing a larger one = and hence feel the need.

I am mostly interested = in a stable model/syntax for documentation purposes, validation tools = would be second on my list.

I=92ll dig through = your posting and come back with ideas/comments and hopefully it won=92t = be long to throw together an initial = version.


I found that pretty slick = on first = glance.

Thanks,

Jan




On May 3, 2014 9:52 AM, "Jan Algermissen" = <jan.algermissen@nordsc.com&= gt; wrote:
Hi,

is there an = adaption of RelaxNG for JSON?

This seems such = an obvious thing to do, I was shocked that searches yield no really good = answers.


All I found so = far:

<= br>
Jan

_________________________________________= ______
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_C345837B-8759-4504-9CAF-DC33C0ABC673-- From nobody Sun May 4 08:37:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB11A00D5 for ; Sun, 4 May 2014 08:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 VNJW4sKjiCL8 for ; Sun, 4 May 2014 08:37:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD131A00A8 for ; Sun, 4 May 2014 08:37:12 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s44Fb6VY088256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 May 2014 08:37:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <422AD850-7048-4187-B00D-F24394A23A92@nordsc.com> Date: Sun, 4 May 2014 08:37:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BEF3D24-37E6-4E56-A3F6-D48E42FB3F2B@vpnc.org> References: <6DF30B07-9276-45D1-AFAD-D52B612215D1@nordsc.com> <422AD850-7048-4187-B00D-F24394A23A92@nordsc.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ShtHEo_vdFbZz1roGfb5kYcNQms Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RelaxNG for JSON? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 15:37:12 -0000 This has been discussed off and on in the JSON WG. There was general = agreement that it might be somewhat useful to have one or more schema = languages for describing JSON in protocols, particularly if the schema = language doesn't try to be complete but instead relies on prose for edge = cases. If you have a draft of a schema language for JSON, feel free to discuss = it in the JSON WG. Such things can be published as Informational RFCs = and used for describing future protocols. --Paul Hoffman= From nobody Mon May 5 16:03:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB311A6FB4; Fri, 2 May 2014 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 2FtR4P2LWEhU; Fri, 2 May 2014 08:06:55 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 308C31A6F27; Fri, 2 May 2014 08:06:54 -0700 (PDT) Received: from webmail-4.mappi.helsinki.fi (webmail-4.mappi.helsinki.fi [128.214.20.218]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s42F6gje022186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 May 2014 18:06:43 +0300 Received: from a88-114-107-213.elisa-laajakaista.fi (a88-114-107-213.elisa-laajakaista.fi [88.114.107.213]) by webmail.helsinki.fi (Horde Framework) with HTTP; Fri, 02 May 2014 18:06:42 +0300 Date: Fri, 02 May 2014 18:06:42 +0300 Message-ID: <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: John C Klensin References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> In-Reply-To: <952E89C207E59D25CD5953D6@JCK-EEE10> User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cjVvdTRWKTo1K2AIuwHMShLPCx0 X-Mailman-Approved-At: Mon, 05 May 2014 16:03:08 -0700 Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 15:06:58 -0000 Hello, Quoting John C Klensin : > Hi. > ... one very quick observation in response to part of > Larry's note... > > --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter > wrote: > >> The only thing that makes something a name 'persistsent' is >> the existence of a name resolution service or method which >> persists. The syntax or namespace is irrelevant. 'persistent' >> isn't binary, it's just "how long". Everything has a life-time. >> >> http://masinter.blogspot.com/2010/03/ozymandias-uri.html > > I think the above largely misses the point and that, in a sense, > your blog posting illustrates the point although not in the way > you probably intend. "Persistent identifier" entered the IETF > vocabulary a long time ago but may not be very look terminology. > > Some objects -- like stone statues if one doesn't care whether > they remain intact and standing-- have very long life > expectancies. Others, like people, have shorter ones. The library point of view to this is that Shelley's Ozymandias has an extremely long life expectancy as a work. It will exist at least as long as there is at least one copy left of it, in some physical (printed or digital) form. In principle the work itself may survive even longer, if 1-n people have memorized it before the last copy vanishes (which will inevitably happen). Persistence of works, their manifestations and identifiers assigned to them is primarily an organizational issue. For instance, publications will survive a long time because national libraries look after them. Some of us are also busy harvesting web pages, using the same technologies as the Internet Archive. Likewise archives and museums will keep some materials for hundreds of years. This is the community which needs persistent identifiers and is already actively using them (and understands pretty well how to do it). Now, in order to identify Ozymandias, the following steps are needed: 1. Give an identifier to the (immaterial) work, and provide metadata about the poem. 2. Give identifier to a manifestation of the work. The identifier system used can be an ISBN, if Ozymandias is published in a collection of Shelley's poems. Once the identifier has been assigned, provide metadata about the book. If the resource is not a book, use other identifier system such as NBN. 3. If the resource is digital, provide a link (using the existing identifier) from the metadata record to the resource. Traditional identifiers can be made actionable in the Internet as URNs, but other PID systems such as DOI, Handle, ARK et cetera can also be used. As an aside, new features which URNbis has built are not in conflict with other PIDs; on the contrary, they can use them as well. The only slightly problematic case is ARK since it has its own established practice for using query. The essential difference between this PID-driven approach and that of some people on this list is that for me, URLs like this http://www.poemhunter.com/poem/ozymandias/ or even this http://ozymandias.perm are not identifiers, first and foremost because their assignment process is not managed. One may argue that sometimes there are no proper identifier system to use but this is not true; Handles, DOIs and URNs can be applied to anything out there). Second, there is a problem that URLs are not persistent, since they are technology dependent. Even if they had the same organizational support than the URN-based link supported by the national library (which is very unlikely) it may become very difficult to support these URLs long before reading the resources requires digital archaeology. Some people on this list have argued that http://urn.fi/URN:ISBN:978-952-10-9658-7 or other PID with embedded resolver address is no different from e.g. http://ozymandias.perm. But in this case the syntactical similarity is deceptive; URN and other PIDs must be resolved before the current URL (URLs) of the resource is found, so all kinds of interesting stuff can be done in the resolution process before the result is passed to HTTP. And once Resolver Discovery Service is in place, it will be possible to drop the resolver URL from the URN string, and make the difference between URLs and URNs more clear. But URIs > (with or within including URNs) aren't objects, they are object > reference that, like most good references, involve some degree > of abstraction. Now, "Ozymandias" is a very long-persistent > reference. It isn't the object. It is a somewhat ambiguous > reference because it can refer to the statue, the poem, your > blog posting, and probably several other things, but has a long > duration, perhaps one that is long enough to survive the objects > it references (just like titles of long-lost books). But, as a > reference, it is that persistent because it is not bound to a > retrieval mechanism that has its own persistence properties. References to immaterial objects (works and expressions, the latter meaning for instance translations of works) are persistent, but they do require metadata since otherwise they may be ambiguous. For instance, we are talking about Shelley's poem, first published in The Examiner, 11 January 1818, along with Hymn to intellectual beauty. There is also book by Thomas Monteleone which has the same name. > > Whatever its other properties, > http://masinter.blogspot.com/2010/03/ozymandias-uri.html > is lousy as a persistent identifier. URLs really should not be called identifiers. There is a fundamental difference between assigning a persistent identifier using a managed process (which includes creation of descriptive metadata about the resource) and getting a URL to a web page. One problem I and others have with the concept of URI is that it blurs what should be a clear difference between locations and proper identifiers. Anyone should be allowed to give the former, but identifier assignment for resources that are to be kept for centuries is not something anyone is allowed do. Of course even people assigning proper identifiers such as ISBNs and ISSNs make mistakes, and there are pressures to use these systems in less than optimal manner, but that is not the key issue here. What is important is that any digital resource that will be preserved for future generations will require a persistent identifier. Millions and millions of them - Handles, DOIs, URNs, ARKs) have been assigned already by libraries, publishers, universities, archives and museums. In order to optimize the tools used for generating and resolving URNs and other PIDs, we need some new functionalities such as the possibility of using fragments and queries. It depends on the > availability of "http" (or something called that) as a retrieval > mechanism. It depends on there being a DNS, on there being a > TLD named "com" an SLD named "blogspot", and both of them having > certain properties of which HTTP can take advantage. It seems that the extent to which URLs are dependent on underlying technologies and the impact this will have on URLs in the long run (after, say, a few decades) is not properly understood yet even by those communities which must preserve things for extended periods. It might be useful to explain where the problems are, and make a guesstimate of when each of these issues might emerge. > "Ozymandias", and even the potential URN > urn:poems:Shelley/Ozymandias are more persistent because they > represent a higher level of abstraction and are not tied to > either a location or a retrieval/access method. Use of a > hypothetical ISPN (International Standard Poem Identifier) in > the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or > might not be more persistent: it would be an exact identifier of > something and makes equivalence comparison more feasible and > less ambiguous, but it is probably tied to a database to > actually identify an object and such databases may be more or > less available and persistent than access methods and/or the DNS > (which is, after all, just another database). In practice there will be ISTC (International Standard Text Code) assigned to the poem. ISTC can be expressed as URN (urn:istc:xxxx-xxxx-xxxx-xxxx). Library databases all over the world will have work metadata about the poem (once one library has catalogued it, it can be copied to the OPAC of every other library in the world). From the work record there will be persistent links to manifestation records, which in turn will contain the locations of the manifestations - physical shelf locations for printed stuff, and links using persistent identifiers to electronic resources. When thousands of library OPACs have the same metadata record, it is important to have just persistent identifier -based links in them; resolving these URNs / Handles / etc. to URLs must be centralized. Then it is not necessary to modify every OPAC when URLs change. Naming / identification has at times been discussed on this list in a very abstract level. For most resources that will be preserved for long term, things are not that complex. There are guidebooks for using ISTCs, ISBNs, ISSNs, NBNs and so on. In those namespaces at least it is not necessary to be familiar with Heidegger in order to be able to assign identifiers for things. On the other hand, it is these existing practices which are in conflict with some of the principles expressed in RFC 3986. If fragment were to identify something (instead of just pinpointing a location within the identified resource) the new URN syntax would not be OK of most identifiers used in libraries and publishing sector. The same applies for query. Juha > > Regardless of what one calls them, I suggest that > access-method-dependent identifiers (http:..., > NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?" > represents one or more carefully-chosen delimiters that may not > have RFC 3986 semantics), ...) are different kinds of creatures > than either the objects to which they refer or names of those > objects that are not, in the sense of the above, method or > location-model dependent. > > More soon. > > john > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon May 5 19:38:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E681A0207 for ; Mon, 5 May 2014 19:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TeVXYrs6fKb0 for ; Mon, 5 May 2014 19:38:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 45C1F1A0114 for ; Mon, 5 May 2014 19:38:50 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.73.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5E477509B5; Mon, 5 May 2014 22:38:43 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C4386D5@MX15A.corp.emc.com> Date: Tue, 6 May 2014 12:38:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <90446EFE-6CE6-4D4D-AF52-6BCC75782DA1@mnot.net> References: <8D3D17ACE214DC429325B2B98F3AE712076C4386D4@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C4386D5@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qo6b5uwSNp-7gA3qUORl_8-plH0 Cc: Apps Discuss Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 02:38:52 -0000 Hi David, Thanks. Responses below. On 5 May 2014, at 1:16 pm, Black, David wrote: > I have reviewed this document as part of the Operational directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These comments=20 > were written primarily for the benefit of the operational area = directors. =20 > Document editors and WG chairs should treat these comments just like = any other=20 > last call comments. >=20 > Document: draft-ietf-appsawg-uri-get-off-my-lawn-04 > Reviewer: David L. Black > Review Date: May 4, 2014 > IETF LC End Date: May 7, 2014 > IESG Telechat Date: May 15, 2014 >=20 > Summary: Ready with nits >=20 > This draft provides Best Current Practices for specifying (well, = mostly not > specifying) substructure in URIs. As the author of a URI scheme spec, > RFC 4088 for SNMP URIs, I can definitely envision some of the problems > that this draft's recommendations seek to avoid. Overall, this is a = clear > and well-written draft=20 Thank you. > The author did include operational Difficulty as a rationale for the > recommendations, thank you. Glad to oblige :) > OTOH, the questions in Appendix A of RFC 5706 > are generally inapplicable to this draft, although I do have a couple = of > minor editorial comments: >=20 > [1] The Operational Difficulty paragraph in Section 1 implies that all = URIs > can be represented in filesystems: >=20 > o Operational Difficulty - Supporting some URI conventions can be > difficult in some implementations. For example, specifying that = a > particular query parameter be used precludes the use of Web > servers that serve the response from a filesystem. >=20 > I might add the text "if the URI scheme is otherwise appropriate for > serving of stored responses from a filesystem.=94 How about making the example more specific: =93=94=94 For example, specifying that a particular query parameter be used with = "HTTP" URIs precludes the use of Web servers that serve the response from a = filesystem. =93=94" ? > [2] Section 2.1 seems somewhat cavalier in suggesting modifications > to RFC 4935: >=20 > A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]. >=20 > I might add "Note that modification of [RFC4935] is NOT RECOMMENDED." = and > add "NOT RECOMMENDED" to the list of RFC 2119 terms used in Section = 1.2. If someone wants to modify that spec (we=92re going to reference BCP115, = not RFC4395, BTW), they=92ll need to go through the appropriate process; = if they=92re being unwise about it, hopefully we=92ll catch that=85 Cheers and thanks again, -- Mark Nottingham http://www.mnot.net/ From nobody Tue May 6 17:14:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECEE1A06C4 for ; Tue, 6 May 2014 17:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 hynfKMDO59mB for ; Tue, 6 May 2014 17:14:19 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 305641A068C for ; Tue, 6 May 2014 17:14:19 -0700 (PDT) Received: from airbears-136-152-6-104.airbears.berkeley.edu ([136.152.6.104] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WhpV0-0000Kn-LT; Tue, 06 May 2014 17:14:15 -0700 Message-ID: <53697AD6.2030504@berkeley.edu> Date: Tue, 06 May 2014 17:14:14 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DcZWkSfc2X6wvOIr7S2ALWYWIiQ Cc: John Arwe , Steve K Speicher , Arnaud Le Hors Subject: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:14:21 -0000 hello. http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data Platform") is a current W3C document in last call WD status, and it introduces/uses the Accept-Post header field proposed in a current draft: http://tools.ietf.org/html/draft-wilde-accept-post we have publicized this proposed header field on this list, and the latest draft also includes a list of known implementations of this header field: http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 after making the specification available for a while, and listing known implementations, we are wondering about next steps. what it would take to get this draft moving towards an experimental RFC (apart from some references that will need to be updated). thanks a lot and kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue May 6 17:45:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9151A02F9 for ; Tue, 6 May 2014 17:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 I_Htm3MM9gNt for ; Tue, 6 May 2014 17:45:54 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7233B1A02AD for ; Tue, 6 May 2014 17:45:54 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4F5B332E55B; Wed, 7 May 2014 09:45:48 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 22ba_3932_15625677_4ca8_4d6c_be81_638eba445b9a; Wed, 07 May 2014 09:45:47 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D8B8EBF4D0; Wed, 7 May 2014 09:45:47 +0900 (JST) Message-ID: <5369822F.3080401@it.aoyama.ac.jp> Date: Wed, 07 May 2014 09:45:35 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erik Wilde , "apps-discuss@ietf.org application-layer protocols" References: <53697AD6.2030504@berkeley.edu> In-Reply-To: <53697AD6.2030504@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o7MOZleXMvw6ly_Ljx2TN7eAr34 Cc: Steve K Speicher , John Arwe , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 00:45:56 -0000 Hello Erik, On 2014/05/07 09:14, Erik Wilde wrote: > hello. > > http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data > Platform") is a current W3C document in last call WD status, and it > introduces/uses the Accept-Post header field proposed in a current draft: > > http://tools.ietf.org/html/draft-wilde-accept-post > > we have publicized this proposed header field on this list, and the > latest draft also includes a list of known implementations of this > header field: > > http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 What's the intent behind "Feature at Risk" box? I can see two reasons for this: a) trying to be really good citizens, and not going ahead with something that's not properly registered; and b) not being confident that this is a good idea. If it's the former, than see below. > after making the specification available for a while, and listing known > implementations, we are wondering about next steps. what it would take > to get this draft moving towards an experimental RFC (apart from some > references that will need to be updated). Why experimental? Why not standards track? An alternative would be to do a provisional registration, because this doesn't need an RFC. That would give you some slack for moving ahead with the Linked Data Platform spec without being at the mercy of a potentially low level of interest in the IETF. With respect to the draft itself, I don't see a registration template. Regards, Martin. From nobody Tue May 6 18:56:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8285F1A0522 for ; Tue, 6 May 2014 18:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 w1f2-ZTU_uQI for ; Tue, 6 May 2014 18:56:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A00531A04A7 for ; Tue, 6 May 2014 18:56:08 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.73.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 91C4950A85; Tue, 6 May 2014 21:55:54 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <20140506180037.BA26218000E@rfc-editor.org> Date: Wed, 7 May 2014 11:55:51 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E224DDD-ED1D-4472-B982-D9B21973E6DC@mnot.net> References: <20140506180037.BA26218000E@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EmxQufoTqegz6VioRg0rxM_U_B0 Cc: apps-discuss@ietf.org, david@acz.org, presnick@qti.qualcomm.com, kris@sitepen.com, barryleiba@computer.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6901 (3981) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 01:56:10 -0000 Hi David, This seems like a request for a change to the RFC, not an errata. Therefore, I think it should be rejected. That said, I=92ve been talking with a few people in the background about = a possible revision to the spec (or a new format based upon it), and = would love to have your input for that. Cheers, On 7 May 2014, at 4:00 am, RFC Errata System = wrote: > The following errata report has been submitted for RFC6901, > "JavaScript Object Notation (JSON) Pointer". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6901&eid=3D3981 >=20 > -------------------------------------- > Type: Technical > Reported by: David Phillips >=20 > Section: 3 >=20 > Original Text > ------------- > See Notes >=20 > Corrected Text > -------------- > The following two examples from section 5 are different: >=20 > Original: "/a~1b" > Proposed: "/a//b" >=20 > Original: "/m~0n" > Proposed: "/m~n" >=20 > The other examples are the same. >=20 > Notes > ----- > The escape syntax seems weird and confusing. Rather than ~0 and ~1, = why not use a repeated (double) slash to escape a slash? This is similar = to how SQL escapes single quotes in string literals by using the single = quote twice. >=20 > We have JSON functions in Presto (prestodb.io) that could benefit from = an improved syntax (they currently use JSONPath), but I can't see = understanding ~0 and ~1. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6901 (draft-ietf-appsawg-json-pointer-09) > -------------------------------------- > Title : JavaScript Object Notation (JSON) Pointer > Publication Date : April 2013 > Author(s) : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed. > Category : PROPOSED STANDARD > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG -- Mark Nottingham http://www.mnot.net/ From nobody Tue May 6 19:11:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7D1A03BE for ; Tue, 6 May 2014 19:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 vYzodH1ijVEU for ; Tue, 6 May 2014 19:11:28 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id EA4521A0304 for ; Tue, 6 May 2014 19:11:27 -0700 (PDT) Received: from dilithium.local (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 130A66649; Wed, 7 May 2014 02:11:22 +0000 (UTC) Message-ID: <1399428681.17221.6.camel@dilithium> From: "Paul C. Bryan" To: Mark Nottingham Date: Tue, 06 May 2014 19:11:21 -0700 In-Reply-To: <1E224DDD-ED1D-4472-B982-D9B21973E6DC@mnot.net> References: <20140506180037.BA26218000E@rfc-editor.org> <1E224DDD-ED1D-4472-B982-D9B21973E6DC@mnot.net> Content-Type: multipart/alternative; boundary="=-/a+QkN4c66F/fztbZ4Nc" X-Mailer: Evolution 3.12.1-1 Mime-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EefYBPw-TJqbkM737qSWJlNn76k Cc: apps-discuss@ietf.org, david@acz.org, presnick@qti.qualcomm.com, kris@sitepen.com, barryleiba@computer.org, RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6901 (3981) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:11:35 -0000 --=-/a+QkN4c66F/fztbZ4Nc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I concur with Mark. This is a substantive, breaking change. Therefore, I also think it should be rejected. It should be considered in any future revisions. Paul On Wed, 2014-05-07 at 11:55 +1000, Mark Nottingham wrote: > Hi David, > > This seems like a request for a change to the RFC, not an errata. > > Therefore, I think it should be rejected. > > That said, I’ve been talking with a few people in the background about a possible revision to the spec (or a new format based upon it), and would love to have your input for that. > > Cheers, > > > > On 7 May 2014, at 4:00 am, RFC Errata System wrote: > > > The following errata report has been submitted for RFC6901, > > "JavaScript Object Notation (JSON) Pointer". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6901&eid=3981 > > > > -------------------------------------- > > Type: Technical > > Reported by: David Phillips > > > > Section: 3 > > > > Original Text > > ------------- > > See Notes > > > > Corrected Text > > -------------- > > The following two examples from section 5 are different: > > > > Original: "/a~1b" > > Proposed: "/a//b" > > > > Original: "/m~0n" > > Proposed: "/m~n" > > > > The other examples are the same. > > > > Notes > > ----- > > The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice. > > > > We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6901 (draft-ietf-appsawg-json-pointer-09) > > -------------------------------------- > > Title : JavaScript Object Notation (JSON) Pointer > > Publication Date : April 2013 > > Author(s) : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed. > > Category : PROPOSED STANDARD > > Source : Applications Area Working Group > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > > -- > Mark Nottingham http://www.mnot.net/ > > > --=-/a+QkN4c66F/fztbZ4Nc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I concur with Mark. This is a substantive, breaking change. Therefore, I also think it should be rejected. It should be considered in any future revisions.

Paul

On Wed, 2014-05-07 at 11:55 +1000, Mark Nottingham wrote:
Hi David,

This seems like a request for a change to the RFC, not an errata.

Therefore, I think it should be rejected.

That said, I’ve been talking with a few people in the background about a possible revision to the spec (or a new format based upon it), and would love to have your input for that.

Cheers,



On 7 May 2014, at 4:00 am, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6901,
> "JavaScript Object Notation (JSON) Pointer".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6901&eid=3981
> 
> --------------------------------------
> Type: Technical
> Reported by: David Phillips <david@acz.org>
> 
> Section: 3
> 
> Original Text
> -------------
> See Notes
> 
> Corrected Text
> --------------
> The following two examples from section 5 are different:
> 
> Original: "/a~1b"
> Proposed: "/a//b"
> 
> Original: "/m~0n"
> Proposed: "/m~n"
> 
> The other examples are the same.
> 
> Notes
> -----
> The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice.
> 
> We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6901 (draft-ietf-appsawg-json-pointer-09)
> --------------------------------------
> Title               : JavaScript Object Notation (JSON) Pointer
> Publication Date    : April 2013
> Author(s)           : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.
> Category            : PROPOSED STANDARD
> Source              : Applications Area Working Group
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

--
Mark Nottingham   http://www.mnot.net/




--=-/a+QkN4c66F/fztbZ4Nc-- From nobody Tue May 6 19:12:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAE1A04BA for ; Tue, 6 May 2014 19:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 04e_BHY2-I6A for ; Tue, 6 May 2014 19:12:06 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1D1A0304 for ; Tue, 6 May 2014 19:12:06 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66] helo=[192.168.1.76]) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WhrKx-0007uS-Iu; Tue, 06 May 2014 19:12:01 -0700 Message-ID: <5369966C.2000408@berkeley.edu> Date: Tue, 06 May 2014 19:11:56 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "apps-discuss@ietf.org application-layer protocols" References: <53697AD6.2030504@berkeley.edu> <5369822F.3080401@it.aoyama.ac.jp> In-Reply-To: <5369822F.3080401@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0ixTBJUi-oq_2hlB_oznNXZsOQY Cc: Steve K Speicher , John Arwe , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:12:11 -0000 hello martin. thanks a lot for the feedback! On 2014-05-06, 17:45 , "Martin J. Dürst" wrote: >> we have publicized this proposed header field on this list, and the >> latest draft also includes a list of known implementations of this >> header field: >> http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 > What's the intent behind "Feature at Risk" box? I can see two reasons > for this: a) trying to be really good citizens, and not going ahead with > something that's not properly registered; and b) not being confident > that this is a good idea. > If it's the former, than see below. it's a), because of the timing issues involved with working on these two documents in W3C- and IETF-land. >> after making the specification available for a while, and listing known >> implementations, we are wondering about next steps. what it would take >> to get this draft moving towards an experimental RFC (apart from some >> references that will need to be updated). > Why experimental? Why not standards track? it could be either way, i don't think we have a strong opinion about that. it seems to me that there are different opinions when to use what, but if standards track is a better fit, that's fine with us. > An alternative would be to do a provisional registration, because this > doesn't need an RFC. That would give you some slack for moving ahead > with the Linked Data Platform spec without being at the mercy of a > potentially low level of interest in the IETF. thanks for pointing that out. i guess if we are not making progress with the draft, then that would be a way to go for us. for now, maybe there is enough interest to move forward with the current approach. > With respect to the draft itself, I don't see a registration template. that would be a template according to RFC 3864? good point, i will add that to https://github.com/dret/I-D/blob/master/accept-post/draft-wilde-accept-post-03.xml thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue May 6 19:38:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15B1A0415 for ; Tue, 6 May 2014 19:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1zAXSuOx6DRM for ; Tue, 6 May 2014 19:38:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F16001A02E3 for ; Tue, 6 May 2014 19:38:31 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.73.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EA03750A73; Tue, 6 May 2014 22:38:20 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <5369822F.3080401@it.aoyama.ac.jp> Date: Wed, 7 May 2014 12:38:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCF3427-3AAB-4C94-BBA0-82D02A87F421@mnot.net> References: <53697AD6.2030504@berkeley.edu> <5369822F.3080401@it.aoyama.ac.jp> To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BKl0nXPXva1n5fF-CIr0PEPpGwU Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:38:33 -0000 Without looking at the draft (recently)... On 7 May 2014, at 10:45 am, Martin J. D=FCrst = wrote: > Why experimental? Why not standards track? +1. =93experimental=94 is for process experiments, e.g., when we can=92t = come to consensus; not =93I=92m not sure if people will be using this.=94 Go ahead and go standards-track.=20 -- Mark Nottingham http://www.mnot.net/ From nobody Tue May 6 23:03:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA541A0645 for ; Tue, 6 May 2014 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 U4nMtb2yzgDL for ; Tue, 6 May 2014 23:03:52 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 496201A0231 for ; Tue, 6 May 2014 23:03:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1001,1389704400"; d="scan'208";a="11346798" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 May 2014 15:53:27 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7430"; a="221451606" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 May 2014 16:03:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 7 May 2014 16:03:23 +1000 From: "Manger, James" To: Mark Nottingham , RFC Errata System Date: Wed, 7 May 2014 16:03:23 +1000 Thread-Topic: [apps-discuss] [Technical Errata Reported] RFC6901 (3981) Thread-Index: Ac9pl4cJNTOw/OwzQOynwawoOD+RYwAIOTGw Message-ID: <255B9BB34FB7D647A506DC292726F6E11545BD2A4B@WSMSG3153V.srv.dir.telstra.com> References: <20140506180037.BA26218000E@rfc-editor.org> <1E224DDD-ED1D-4472-B982-D9B21973E6DC@mnot.net> In-Reply-To: <1E224DDD-ED1D-4472-B982-D9B21973E6DC@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FUsqBNiVCqzL4oNIOfDLwRIctT8 Cc: "david@acz.org" , "presnick@qti.qualcomm.com" , "barryleiba@computer.org" , "kris@sitepen.com" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC6901 (3981) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:03:54 -0000 Tm90IG9ubHkgaXMgdGhlIHN1Z2dlc3Rpb24gYSBjaGFuZ2UsIG5vdCBhbiBlcnJhdGEsIGJ1dCBp dCB3b3VsZG7igJl0IGV2ZW4gd29yay4NCg0KQ29uc2lkZXIgdGhlIGZvbGxvd2luZyB2YWxpZCBK U09OIHZhbHVlOg0KICB7ICJhIjp7IiI6eyJiIjoxfX0sICAiYS9iIjoyIH0NCldpdGggdGhlIHN1 Z2dlc3Rpb24sICIvYS8vYiIgd291bGQgYmUgYSBKU09OIHBvaW50ZXIgZm9yIHRoZSB2YWx1ZXMg MSBhbmQgMiENCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgTm90dGluZ2hhbQ0KU2VudDogV2VkbmVzZGF5LCA3IE1h eSAyMDE0IDExOjU2IEFNDQpUbzogUkZDIEVycmF0YSBTeXN0ZW0NCkNjOiBhcHBzLWRpc2N1c3NA aWV0Zi5vcmc7IGRhdmlkQGFjei5vcmc7IHByZXNuaWNrQHF0aS5xdWFsY29tbS5jb207IGtyaXNA c2l0ZXBlbi5jb207IGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnDQpTdWJqZWN0OiBSZTogW2FwcHMt ZGlzY3Vzc10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY5MDEgKDM5ODEpDQoNCkhp IERhdmlkLA0KDQpUaGlzIHNlZW1zIGxpa2UgYSByZXF1ZXN0IGZvciBhIGNoYW5nZSB0byB0aGUg UkZDLCBub3QgYW4gZXJyYXRhLg0KDQpUaGVyZWZvcmUsIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHJl amVjdGVkLg0KDQpUaGF0IHNhaWQsIEnigJl2ZSBiZWVuIHRhbGtpbmcgd2l0aCBhIGZldyBwZW9w bGUgaW4gdGhlIGJhY2tncm91bmQgYWJvdXQgYSBwb3NzaWJsZSByZXZpc2lvbiB0byB0aGUgc3Bl YyAob3IgYSBuZXcgZm9ybWF0IGJhc2VkIHVwb24gaXQpLCBhbmQgd291bGQgbG92ZSB0byBoYXZl IHlvdXIgaW5wdXQgZm9yIHRoYXQuDQoNCkNoZWVycywNCg0KDQoNCk9uIDcgTWF5IDIwMTQsIGF0 IDQ6MDAgYW0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiB3 cm90ZToNCg0KPiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVk IGZvciBSRkM2OTAxLA0KPiAiSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pIFBvaW50 ZXIiLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWW91 IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+IGh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTY5MDEmZWlkPTM5ODENCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFR5cGU6IFRlY2huaWNhbA0KPiBS ZXBvcnRlZCBieTogRGF2aWQgUGhpbGxpcHMgPGRhdmlkQGFjei5vcmc+DQo+IA0KPiBTZWN0aW9u OiAzDQo+IA0KPiBPcmlnaW5hbCBUZXh0DQo+IC0tLS0tLS0tLS0tLS0NCj4gU2VlIE5vdGVzDQo+ IA0KPiBDb3JyZWN0ZWQgVGV4dA0KPiAtLS0tLS0tLS0tLS0tLQ0KPiBUaGUgZm9sbG93aW5nIHR3 byBleGFtcGxlcyBmcm9tIHNlY3Rpb24gNSBhcmUgZGlmZmVyZW50Og0KPiANCj4gT3JpZ2luYWw6 ICIvYX4xYiINCj4gUHJvcG9zZWQ6ICIvYS8vYiINCj4gDQo+IE9yaWdpbmFsOiAiL21+MG4iDQo+ IFByb3Bvc2VkOiAiL21+biINCj4gDQo+IFRoZSBvdGhlciBleGFtcGxlcyBhcmUgdGhlIHNhbWUu DQo+IA0KPiBOb3Rlcw0KPiAtLS0tLQ0KPiBUaGUgZXNjYXBlIHN5bnRheCBzZWVtcyB3ZWlyZCBh bmQgY29uZnVzaW5nLiBSYXRoZXIgdGhhbiB+MCBhbmQgfjEsIHdoeSBub3QgdXNlIGEgcmVwZWF0 ZWQgKGRvdWJsZSkgc2xhc2ggdG8gZXNjYXBlIGEgc2xhc2g/IFRoaXMgaXMgc2ltaWxhciB0byBo b3cgU1FMIGVzY2FwZXMgc2luZ2xlIHF1b3RlcyBpbiBzdHJpbmcgbGl0ZXJhbHMgYnkgdXNpbmcg dGhlIHNpbmdsZSBxdW90ZSB0d2ljZS4NCj4gDQo+IFdlIGhhdmUgSlNPTiBmdW5jdGlvbnMgaW4g UHJlc3RvIChwcmVzdG9kYi5pbykgdGhhdCBjb3VsZCBiZW5lZml0IGZyb20gYW4gaW1wcm92ZWQg c3ludGF4ICh0aGV5IGN1cnJlbnRseSB1c2UgSlNPTlBhdGgpLCBidXQgSSBjYW4ndCBzZWUgdW5k ZXJzdGFuZGluZyB+MCBhbmQgfjEuDQo+IA0KPiBJbnN0cnVjdGlvbnM6DQo+IC0tLS0tLS0tLS0t LS0NCj4gVGhpcyBlcnJhdGEgaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBu ZWNlc3NhcnksIHBsZWFzZQ0KPiB1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJl YWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpDQo+IGNhbiBsb2cgaW4gdG8gY2hhbmdl IHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJGQzY5MDEgKGRyYWZ0LWll dGYtYXBwc2F3Zy1qc29uLXBvaW50ZXItMDkpDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAgICAgICAgOiBKYXZhU2NyaXB0IE9iamVjdCBO b3RhdGlvbiAoSlNPTikgUG9pbnRlcg0KPiBQdWJsaWNhdGlvbiBEYXRlICAgIDogQXByaWwgMjAx Mw0KPiBBdXRob3IocykgICAgICAgICAgIDogUC4gQnJ5YW4sIEVkLiwgSy4gWnlwLCBNLiBOb3R0 aW5naGFtLCBFZC4NCj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQo+ IFNvdXJjZSAgICAgICAgICAgICAgOiBBcHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwDQo+ IEFyZWEgICAgICAgICAgICAgICAgOiBBcHBsaWNhdGlvbnMNCj4gU3RyZWFtICAgICAgICAgICAg ICA6IElFVEYNCj4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCg0KLS0NCk1hcmsgTm90dGlu Z2hhbSAgIGh0dHA6Ly93d3cubW5vdC5uZXQvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KYXBw cy1kaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FwcHMtZGlzY3Vzcw0K From nobody Wed May 7 09:39:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899141A0791; Wed, 7 May 2014 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 UXOwwdOe4rho; Wed, 7 May 2014 09:39:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 213881A035A; Wed, 7 May 2014 09:39:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4E4FE180014; Wed, 7 May 2014 09:38:54 -0700 (PDT) To: david@acz.org, pbryan@anode.ca, kris@sitepen.com, mnot@mnot.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140507163854.4E4FE180014@rfc-editor.org> Date: Wed, 7 May 2014 09:38:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xr3DPYJxrfkMwSjxqbSmov4QaNM Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Rejected] RFC6901 (3981) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:39:34 -0000 The following errata report has been rejected for RFC6901, "JavaScript Object Notation (JSON) Pointer". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6901&eid=3981 -------------------------------------- Status: Rejected Type: Technical Reported by: David Phillips Date Reported: 2014-05-06 Rejected by: Barry Leiba (IESG) Section: 3 Original Text ------------- See Notes Corrected Text -------------- The following two examples from section 5 are different: Original: "/a~1b" Proposed: "/a//b" Original: "/m~0n" Proposed: "/m~n" The other examples are the same. Notes ----- The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice. We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1. --VERIFIER NOTES-- This is a change request, not an errata report. The suggested change isn't directly acceptable, but could well be useful input into a new version of the specification. In any case, it's not addressing an error, but a feature change. -------------------------------------- RFC6901 (draft-ietf-appsawg-json-pointer-09) -------------------------------------- Title : JavaScript Object Notation (JSON) Pointer Publication Date : April 2013 Author(s) : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed May 7 11:33:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3AA1A02F6 for ; Tue, 6 May 2014 11:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 92ljahOLuACr for ; Tue, 6 May 2014 11:01:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA21A02F1 for ; Tue, 6 May 2014 11:01:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BA26218000E; Tue, 6 May 2014 11:00:37 -0700 (PDT) To: pbryan@anode.ca, kris@sitepen.com, mnot@mnot.net, barryleiba@computer.org, presnick@qti.qualcomm.com, superuser@gmail.com, Salvatore.Loreto@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140506180037.BA26218000E@rfc-editor.org> Date: Tue, 6 May 2014 11:00:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RGgLtXufSaBJkIGWzmib2slV1Jw X-Mailman-Approved-At: Wed, 07 May 2014 11:33:06 -0700 Cc: david@acz.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6901 (3981) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 18:01:14 -0000 The following errata report has been submitted for RFC6901, "JavaScript Object Notation (JSON) Pointer". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6901&eid=3981 -------------------------------------- Type: Technical Reported by: David Phillips Section: 3 Original Text ------------- See Notes Corrected Text -------------- The following two examples from section 5 are different: Original: "/a~1b" Proposed: "/a//b" Original: "/m~0n" Proposed: "/m~n" The other examples are the same. Notes ----- The escape syntax seems weird and confusing. Rather than ~0 and ~1, why not use a repeated (double) slash to escape a slash? This is similar to how SQL escapes single quotes in string literals by using the single quote twice. We have JSON functions in Presto (prestodb.io) that could benefit from an improved syntax (they currently use JSONPath), but I can't see understanding ~0 and ~1. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6901 (draft-ietf-appsawg-json-pointer-09) -------------------------------------- Title : JavaScript Object Notation (JSON) Pointer Publication Date : April 2013 Author(s) : P. Bryan, Ed., K. Zyp, M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed May 7 11:33:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA681A04C2 for ; Tue, 6 May 2014 19:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 wF4DISLSgsyg for ; Tue, 6 May 2014 19:30:47 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 94B191A01FD for ; Tue, 6 May 2014 19:30:47 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s472UeD9009120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 22:30:42 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s472UeD9009120 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1399429842; bh=mUUQZzJZPg1mKJoMRrr9c57UVdQ=; h=From:To:CC:Date:Subject:Message-ID:In-Reply-To:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PZwJ/Cwi7wAb8JrHEuj1bWL/4cpfMqC86d+0cJRp3Wmr8pJljbHLVg8IKdoQV2zV/ QAFtu3SZDDsgUJSFnDlgBahQ8JFuhjgn2I0JBkVzll4Q0Z7h2Js4t0hao98i/wwPVb /sFiAtLEPjaRRqDSPF7J4bzbH6llcEdLAk0DoAeA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s472UeD9009120 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 6 May 2014 19:30:26 -0700 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s472UPdB022046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 22:30:26 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Tue, 6 May 2014 22:30:25 -0400 From: "Black, David" To: "'mnot@mnot.net'" Date: Tue, 6 May 2014 22:30:24 -0400 Thread-Topic: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 Thread-Index: Ac9o1FF5RsO8bOFMQNyAZP5EOm545gAx/uiQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> In-Reply-To: <90446EFE-6CE6-4D4D-AF52-6BCC75782DA1@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4R15hXOfh7lMjV2vinSaZjHg5X0 X-Mailman-Approved-At: Wed, 07 May 2014 11:33:06 -0700 Cc: "Black, David" , "'apps-discuss@ietf.org'" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:30:50 -0000 SGkgTWFyaywNCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuDQoNCkZvciBbMV0sIHlv dXIgcHJvcG9zZWQgdGV4dCBpcyBmaW5lIGFuZCBiZXR0ZXIgdGhhbiB3aGF0IEkgc3VnZ2VzdGVk Lg0KDQpGb3IgWzJdLCB3aGlsZSBJJ20gc3VyZSB0aGF0IHlvdSdyZSBjb3JyZWN0IHRoYXQgYW55 IHVud2lzZSBhdHRlbXB0IHRvIG1vZGlmeSB0aGF0IEJDUC9SRkMgd291bGQgYmUgY2F1Z2h0LCBJ TUhPLCBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGFkZCBzb21lIHRleHQgdG8gd2FybiB0aGUgdW53 aXNlIGVhcmxpZXIsIGJlZm9yZSB0aGV5IGludmVzdCBhbnkgc2lnbmlmaWNhbnQgdGltZS9lZmZv cnQgaW4gcHVyc3VpbmcgdGhhdCBzb3J0IG9mIG1vZGlmaWNhdGlvbi4gIEkgZG9uJ3QgcGFydGlj dWxhcmx5IGNhcmUgd2hldGhlciBhbiBSRkMgMjExOSBrZXl3b3JkIGlzIHVzZWQsIGJ1dCBJIHdv dWxkIGxpa2UgdG8gc2VlIHNvbWUgc29ydCBvZiBjbHVlIG9mZmVyZWQgOy0pLg0KDQpUaGFua3Ms IC0tRGF2aWQgKysrU2VudCBmcm9tIEJsYWNrYmVycnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogTWFyayBOb3R0aW5naGFtIFttYWlsdG86bW5vdEBtbm90Lm5ldF0NClNl bnQ6IE1vbmRheSwgTWF5IDA1LCAyMDE0IDEwOjM4IFBNClRvOiBCbGFjaywgRGF2aWQNCkNjOiBB cHBzIERpc2N1c3MgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBPUFMtRGly IHJldmlldyBvZiBkcmFmdC1pZXRmLWFwcHNhd2ctdXJpLWdldC1vZmYtbXktbGF3bi0wNA0KDQpI aSBEYXZpZCwNCg0KVGhhbmtzLiBSZXNwb25zZXMgYmVsb3cuDQoNCk9uIDUgTWF5IDIwMTQsIGF0 IDE6MTYgcG0sIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQoNCj4g SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwg ZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIA0KPiB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgb3BlcmF0aW9uYWwgYXJl YSBkaXJlY3RvcnMuICANCj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIA0KPiBsYXN0IGNhbGwgY29t bWVudHMuDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1nZXQtb2ZmLW15 LWxhd24tMDQNCj4gUmV2aWV3ZXI6IERhdmlkIEwuIEJsYWNrDQo+IFJldmlldyBEYXRlOiBNYXkg NCwgMjAxNA0KPiBJRVRGIExDIEVuZCBEYXRlOiBNYXkgNywgMjAxNA0KPiBJRVNHIFRlbGVjaGF0 IERhdGU6IE1heSAxNSwgMjAxNA0KPiANCj4gU3VtbWFyeTogUmVhZHkgd2l0aCBuaXRzDQo+IA0K PiBUaGlzIGRyYWZ0IHByb3ZpZGVzIEJlc3QgQ3VycmVudCBQcmFjdGljZXMgZm9yIHNwZWNpZnlp bmcgKHdlbGwsIG1vc3RseSBub3QNCj4gc3BlY2lmeWluZykgc3Vic3RydWN0dXJlIGluIFVSSXMu ICBBcyB0aGUgYXV0aG9yIG9mIGEgVVJJIHNjaGVtZSBzcGVjLA0KPiBSRkMgNDA4OCBmb3IgU05N UCBVUklzLCBJIGNhbiBkZWZpbml0ZWx5IGVudmlzaW9uIHNvbWUgb2YgdGhlIHByb2JsZW1zDQo+ IHRoYXQgdGhpcyBkcmFmdCdzIHJlY29tbWVuZGF0aW9ucyBzZWVrIHRvIGF2b2lkLiAgT3ZlcmFs bCwgdGhpcyBpcyBhIGNsZWFyDQo+IGFuZCB3ZWxsLXdyaXR0ZW4gZHJhZnQgDQoNClRoYW5rIHlv dS4NCg0KPiBUaGUgYXV0aG9yIGRpZCBpbmNsdWRlIG9wZXJhdGlvbmFsIERpZmZpY3VsdHkgYXMg YSByYXRpb25hbGUgZm9yIHRoZQ0KPiByZWNvbW1lbmRhdGlvbnMsIHRoYW5rIHlvdS4NCg0KR2xh ZCB0byBvYmxpZ2UgOikNCg0KPiBPVE9ILCB0aGUgcXVlc3Rpb25zIGluIEFwcGVuZGl4IEEgb2Yg UkZDIDU3MDYNCj4gYXJlIGdlbmVyYWxseSBpbmFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYWx0 aG91Z2ggSSBkbyBoYXZlIGEgY291cGxlIG9mDQo+IG1pbm9yIGVkaXRvcmlhbCBjb21tZW50czoN Cj4gDQo+IFsxXSBUaGUgT3BlcmF0aW9uYWwgRGlmZmljdWx0eSBwYXJhZ3JhcGggaW4gU2VjdGlv biAxIGltcGxpZXMgdGhhdCBhbGwgVVJJcw0KPiBjYW4gYmUgcmVwcmVzZW50ZWQgaW4gZmlsZXN5 c3RlbXM6DQo+IA0KPiAgIG8gIE9wZXJhdGlvbmFsIERpZmZpY3VsdHkgLSBTdXBwb3J0aW5nIHNv bWUgVVJJIGNvbnZlbnRpb25zIGNhbiBiZQ0KPiAgICAgIGRpZmZpY3VsdCBpbiBzb21lIGltcGxl bWVudGF0aW9ucy4gIEZvciBleGFtcGxlLCBzcGVjaWZ5aW5nIHRoYXQgYQ0KPiAgICAgIHBhcnRp Y3VsYXIgcXVlcnkgcGFyYW1ldGVyIGJlIHVzZWQgcHJlY2x1ZGVzIHRoZSB1c2Ugb2YgV2ViDQo+ ICAgICAgc2VydmVycyB0aGF0IHNlcnZlIHRoZSByZXNwb25zZSBmcm9tIGEgZmlsZXN5c3RlbS4N Cj4gDQo+IEkgbWlnaHQgYWRkIHRoZSB0ZXh0ICJpZiB0aGUgVVJJIHNjaGVtZSBpcyBvdGhlcndp c2UgYXBwcm9wcmlhdGUgZm9yDQo+IHNlcnZpbmcgb2Ygc3RvcmVkIHJlc3BvbnNlcyBmcm9tIGEg ZmlsZXN5c3RlbS7igJ0NCg0KSG93IGFib3V0IG1ha2luZyB0aGUgZXhhbXBsZSBtb3JlIHNwZWNp ZmljOg0KDQrigJzigJ3igJ0NCkZvciBleGFtcGxlLCBzcGVjaWZ5aW5nIHRoYXQgYSBwYXJ0aWN1 bGFyIHF1ZXJ5IHBhcmFtZXRlciBiZSB1c2VkIHdpdGggIkhUVFAiDQogIFVSSXMgcHJlY2x1ZGVz IHRoZSB1c2Ugb2YgV2ViIHNlcnZlcnMgdGhhdCBzZXJ2ZSB0aGUgcmVzcG9uc2UgZnJvbSBhIGZp bGVzeXN0ZW0uDQrigJzigJ0iDQoNCj8NCg0KPiBbMl0gU2VjdGlvbiAyLjEgc2VlbXMgc29tZXdo YXQgY2F2YWxpZXIgaW4gc3VnZ2VzdGluZyBtb2RpZmljYXRpb25zDQo+IHRvIFJGQyA0OTM1Og0K PiANCj4gICBBIHNwZWNpZmljYXRpb24gdGhhdCBkZWZpbmVzIHN1YnN0cnVjdHVyZSB3aXRoaW4g YSBVUkkgc2NoZW1lIE1VU1QgZG8NCj4gICBzbyBpbiB0aGUgZGVmaW5pbmcgZG9jdW1lbnQgZm9y IHRoYXQgVVJJIHNjaGVtZSwgb3IgYnkgbW9kaWZ5aW5nDQo+ICAgW1JGQzQzOTVdLg0KPiANCj4g SSBtaWdodCBhZGQgIk5vdGUgdGhhdCBtb2RpZmljYXRpb24gb2YgW1JGQzQ5MzVdIGlzIE5PVCBS RUNPTU1FTkRFRC4iIGFuZA0KPiBhZGQgIk5PVCBSRUNPTU1FTkRFRCIgdG8gdGhlIGxpc3Qgb2Yg UkZDIDIxMTkgdGVybXMgdXNlZCBpbiBTZWN0aW9uIDEuMi4NCg0KSWYgc29tZW9uZSB3YW50cyB0 byBtb2RpZnkgdGhhdCBzcGVjICh3ZeKAmXJlIGdvaW5nIHRvIHJlZmVyZW5jZSBCQ1AxMTUsIG5v dCBSRkM0Mzk1LCBCVFcpLCB0aGV54oCZbGwgbmVlZCB0byBnbyB0aHJvdWdoIHRoZSBhcHByb3By aWF0ZSBwcm9jZXNzOyBpZiB0aGV54oCZcmUgYmVpbmcgdW53aXNlIGFib3V0IGl0LCBob3BlZnVs bHkgd2XigJlsbCBjYXRjaCB0aGF04oCmDQoNCkNoZWVycyBhbmQgdGhhbmtzIGFnYWluLA0KDQoN Ci0tDQpNYXJrIE5vdHRpbmdoYW0gICBodHRwOi8vd3d3Lm1ub3QubmV0Lw0KDQoNCg0KDQo= From nobody Wed May 7 12:08:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0AA1A07C0 for ; Wed, 7 May 2014 12:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 WZSS1Kf_ZvDp for ; Wed, 7 May 2014 12:08:35 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 905361A07B2 for ; Wed, 7 May 2014 12:08:35 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so1928593vcb.1 for ; Wed, 07 May 2014 12:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QZVyzceIGIbVPyuTedR81M4QOX9b29zpwZwm8W/1aPQ=; b=twtoyArJJ9qIIdcSrVi4d4Wa4OB1kZ30Xf/bilnqsCj3hIPE8S44hzOxwQ58Y76r2o 6pMapG7rat+3R7oHtHnbsBg/kSKLdFWJeLZnTs2FShAch7et0fqSHymHyMMzB9pH4bsc RdLyzbO6H6/Pc7k+3k5YiY2BvGM3yJEWQnZisydlZrojyUuiLs6hC3KHtYjj4fVJ1wRg 7/0jzJQizIeML0UisJTvLJYA6njRPhMhRb34vLI/x9YTO9W8Xkmv933Gj+VuFggnmCoO 6TP58xBNwwmWqVA8GZi6WXY9U9xDgQEg/eD2P2Qj9GCsca5XAh0EHxvzFlJ2j0Iu/OBR YPgg== MIME-Version: 1.0 X-Received: by 10.58.66.195 with SMTP id h3mr2373845vet.57.1399489711174; Wed, 07 May 2014 12:08:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Wed, 7 May 2014 12:08:31 -0700 (PDT) In-Reply-To: <7BCF3427-3AAB-4C94-BBA0-82D02A87F421@mnot.net> References: <53697AD6.2030504@berkeley.edu> <5369822F.3080401@it.aoyama.ac.jp> <7BCF3427-3AAB-4C94-BBA0-82D02A87F421@mnot.net> Date: Wed, 7 May 2014 15:08:31 -0400 X-Google-Sender-Auth: pdMojE7rFDPflxBo4FQO5UCqxk0 Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DxU_U1Rq3DdIXAbCib72hEofi3M Cc: Steve K Speicher , John Arwe , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:08:36 -0000 > =E2=80=9Cexperimental=E2=80=9D is for process experiments, e.g., when we = can=E2=80=99t > come to consensus; not =E2=80=9CI=E2=80=99m not sure if people will be us= ing this.=E2=80=9D > > Go ahead and go standards-track. I'll quibble with that: Experimental is for protocol experiments as well. "We're not sure that we got some of this right, and we want to document it and have people try it and see before we say it's a proposed standard." That said, I don't disagree with the last thing Mark said: If you think the protocol needs experimentation, make it Experimental. If you're reasonably confident that the protocol is right, but you're just not sure how much deployment it'll get, make it Proposed Standard. Barry, Applications AD From nobody Wed May 7 14:32:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41F1A03B5; Wed, 7 May 2014 14:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5TXB52qEJet7; Wed, 7 May 2014 14:32:20 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 68F031A03AE; Wed, 7 May 2014 14:32:20 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so2102645wib.6 for ; Wed, 07 May 2014 14:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D+16ESSLtturwhlQonumrJqxtFfujBqA6QvXPZgk3MQ=; b=a8InQASQZCSLselkDvY9RxkgTplj5f61nhV1iAQSJL+IArbeESKwStawonqeSL4VrC wv2a2nPVXiOPOFA5UG3N1YrHhydUg9tIQhWLcyo1Fmqo9lLc6zrkHsDk4dWxHUNi2gyv VVrUj5FIzURWd51uAXppegjXLXVwcuKknbtc9dU4eUl1G6sU0jTAFgCMtN2JM+fwgy/J 0MUxZ1GUe5edw0OM4gz5Szcs0JDrlxt1Lp07VXEUdHJfixTPAzYO5BRBKfs9e7Rivjc6 zdsT9FGhQ536focoz7iFblrLbg9/2dNsFgmWcC6sO/eDeuEMcp0Jly1iVUTu+P7hVPs/ /BQw== MIME-Version: 1.0 X-Received: by 10.180.218.35 with SMTP id pd3mr9674669wic.26.1399498335692; Wed, 07 May 2014 14:32:15 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 7 May 2014 14:32:15 -0700 (PDT) Date: Wed, 7 May 2014 14:32:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: ietf-smtp , IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a113467fc29ae9b04f8d6194e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_CaciNh2ipS1J_RB7n7B64ZG3gs Subject: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 21:32:22 -0000 --001a113467fc29ae9b04f8d6194e Content-Type: text/plain; charset=UTF-8 A while ago I did this short draft: https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/ ...and then promptly forgot about it. Given that email authentication is front-and-center these days, is it worth updating it and then pushing it through? Given its size, does anyone have thoughts about processing it through APPSAWG? -MSK, not in any particular role this time --001a113467fc29ae9b04f8d6194e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
...and then promptly forgot about it.=C2=A0 Given that email authenti= cation is front-and-center these days, is it worth updating it and then pus= hing it through?=C2=A0 Given its size, does anyone have thoughts about proc= essing it through APPSAWG?

-MSK, not in any particular role this time
--001a113467fc29ae9b04f8d6194e-- From nobody Wed May 7 15:08:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4829D1A03DC; Wed, 7 May 2014 15:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zLvfMQwMVIjs; Wed, 7 May 2014 15:08:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90B1A03A6; Wed, 7 May 2014 15:08:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7J7H5CICG001QU6@mauve.mrochek.com>; Wed, 7 May 2014 15:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399500217; bh=N1xUo0hZCVeSxRqlRapsECAUE4a2tDBNJGmYt23mcg4=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=GZmsuz4NoLUEk/JaAHEs1R+rhAk2Et/5usMG8gb61fSbKLDuTDSGdvJWsHnN3+k3C oSBezgo3vYxqLpc9TRd1wj65jXRDM1IKB4CZ3RQNyBULgOH8eUesRuxFFGUzq5CEwi nji4szA8Ap/Cy6gn6dsuQ0meyadqS5wk+EzIwyNo= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7EXXVVVA8000052@mauve.mrochek.com>; Wed, 07 May 2014 15:03:34 -0700 (PDT) Message-id: <01P7J7H3JV12000052@mauve.mrochek.com> Date: Wed, 07 May 2014 15:01:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 07 May 2014 14:32:15 -0700" References: To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X6d7nQyaeFMj8y_JCirAKBZjpCQ Cc: ietf-smtp , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:08:46 -0000 > A while ago I did this short draft: > https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/ > ...and then promptly forgot about it. Given that email authentication is > front-and-center these days, is it worth updating it and then pushing it > through? Given its size, does anyone have thoughts about processing it > through APPSAWG? First, there needs to be a discussion about whether DKIM-specific or DMARC-specific codes are what's called for. I can argue this either way Second, regardless of the outcome of that discussion, this needs to be at least referenced by the DMARC specification, if not incorporated into it. Third, doing this in appsawg seems like as good a place as any. Ned From nobody Wed May 7 15:26:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4298D1A0404; Wed, 7 May 2014 15:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Mw57-q_F1oyt; Wed, 7 May 2014 15:26:38 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 625371A0402; Wed, 7 May 2014 15:26:38 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so2158374wiv.3 for ; Wed, 07 May 2014 15:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DSsHK8gsnO47iAnwL+NpurnaNx4uZ8Rv0Gwx40WnQYs=; b=pJjQK0z6swvFASIlzmlu5sDQdDSbYu1dT+DrISCw2tfiM1ouSymc6DRzpkzRTKi69g +nV7a3YvPHxPTQHtBh8YgGeN1uUDZ67Cl8wigJobQTxumSKgISC2P/gRFvL45H7dXS4Q erBRiVBk/dGCe+MJYWL+SZ0izNYQg51z8v0CIEw6dnaiWnWvsgzOq2vNUENqTWPFTKhN vVR/H9V5N4Qzpos/E71ezlIE19r5ANsZS3humkXfiwJcA7ercvAj6jsh4miID80omC2i ABV9uEr4SkHK/fu3g+FONZVXtlI2Sk6hExWmDhSbOWtTTY8X2y9GxGEhM7Ik3BrdRzXj 9mfw== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr396654wic.5.1399501593677; Wed, 07 May 2014 15:26:33 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 7 May 2014 15:26:33 -0700 (PDT) In-Reply-To: <01P7J7H3JV12000052@mauve.mrochek.com> References: <01P7J7H3JV12000052@mauve.mrochek.com> Date: Wed, 7 May 2014 15:26:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=001a11c26ab45a954004f8d6dbc7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iTJ3YJ-mG2ORNjdsuyXJq3Bq77A Cc: ietf-smtp , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:26:40 -0000 --001a11c26ab45a954004f8d6dbc7 Content-Type: text/plain; charset=UTF-8 On Wed, May 7, 2014 at 3:01 PM, Ned Freed wrote: > > First, there needs to be a discussion about whether DKIM-specific or > DMARC-specific codes are what's called for. I can argue this either way > I was thinking the DMARC draft, since it's active, could be adjusted to include such a definition rather than doing that here. This one can then proceed while the DMARC debate resolves. > Second, regardless of the outcome of that discussion, this needs to be at > least > referenced by the DMARC specification, if not incorporated into it. > Sure. > Third, doing this in appsawg seems like as good a place as any. > Thanks. -MSK --001a11c26ab45a954004f8d6dbc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 7, 2014 at 3:01 PM, Ned Freed <ned.freed@= mrochek.com> wrote:

First, there needs to be a discussion about whether DKIM-specific or<= br> DMARC-specific codes are what's called for. I can argue this either way=

I was thinking the DMARC draft, since = it's active, could be adjusted to include such a definition rather than= doing that here.=C2=A0 This one can then proceed while the DMARC debate re= solves.
=C2=A0
Second, regardless of the outcome of that discussion, this needs to be at l= east
referenced by the DMARC specification, if not incorporated into it.

Sure.
=C2=A0
Third, doing this in appsawg seems like as good a place as any.

Thanks.

-MSK
--001a11c26ab45a954004f8d6dbc7-- From nobody Wed May 7 16:35:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF91A043F for ; Wed, 7 May 2014 16:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 zKV0rJv43eLi for ; Wed, 7 May 2014 16:35:15 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8B11A0435 for ; Wed, 7 May 2014 16:35:15 -0700 (PDT) Received: from airbears-136-152-7-243.airbears.berkeley.edu ([136.152.7.243] helo=dretpro.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WiBMg-00021F-FG; Wed, 07 May 2014 16:35:08 -0700 Message-ID: <536AC32A.60207@berkeley.edu> Date: Wed, 07 May 2014 16:35:06 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Barry Leiba , Mark Nottingham References: <53697AD6.2030504@berkeley.edu> <5369822F.3080401@it.aoyama.ac.jp> <7BCF3427-3AAB-4C94-BBA0-82D02A87F421@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fR5CtCMPfgptZo84TzNrUoGWKsI Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:35:18 -0000 hello barry. thanks for the feedback. On 2014-05-07, 12:08 , Barry Leiba wrote: > I'll quibble with that: > Experimental is for protocol experiments as well. "We're not sure > that we got some of this right, and we want to document it and have > people try it and see before we say it's a proposed standard." the proposal is rather simple and similar to what has been done with the existing Accept-Patch header field. because of this, i think we're fairly confident that it does not contain major issues. we also do have existing implementations using it already. > That said, I don't disagree with the last thing Mark said: If you > think the protocol needs experimentation, make it Experimental. If > you're reasonably confident that the protocol is right, but you're > just not sure how much deployment it'll get, make it Proposed > Standard. ok, i guess in this case we'll stick to the standard route. i have added a proper registration template as suggested by martin, and i am wondering if there are any other issues i should look at before publishing an updated version of the draft. thanks and cheers, dret. ps: https://github.com/dret/I-D/blob/master/accept-post/draft-wilde-accept-post-03.txt is where the currently unpublished -03 lives -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Wed May 7 18:58:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE211A047C for ; Wed, 7 May 2014 18:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 y0cFBCZaOq5r for ; Wed, 7 May 2014 18:58:25 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B71211A0473 for ; Wed, 7 May 2014 18:58:25 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.73.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B328D509B6; Wed, 7 May 2014 21:58:18 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> Date: Thu, 8 May 2014 11:58:15 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mM4OHeg0ZLAww7b10Hhp5PEH6KI Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 01:58:27 -0000 On 7 May 2014, at 12:30 pm, Black, David wrote: > For [2], while I'm sure that you're correct that any unwise attempt to = modify that BCP/RFC would be caught, IMHO, it would be helpful to add = some text to warn the unwise earlier, before they invest any significant = time/effort in pursuing that sort of modification. I don't particularly = care whether an RFC 2119 keyword is used, but I would like to see some = sort of clue offered ;-). I=92m struggling to come up with appropriate text here. Do we really = need to caution people that the process needs to be followed, and that = might be difficult if you want to do something controversial?=20 E.g. we could say that modifying BCP115 is =93unusual=94 =97 but = considering that there=92s a modification of it underway right now, for = the second time in eight years, that=92s not strictly true. What target audience are you thinking of? Anyone who has a passing = familiarity with the IETF must realise that modifying a Best Current = Practice isn=92t something you can do unilaterally? Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed May 7 20:13:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371CB1A02B8 for ; Wed, 7 May 2014 20:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 SR2Qcrq2yH8T for ; Wed, 7 May 2014 20:13:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B94541A01F9 for ; Wed, 7 May 2014 20:13:04 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 120ECD0461E; Wed, 7 May 2014 23:13:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1399518780; bh=txb/PDiOdTG3L+tYVmNj7+yHWrDy2EtXCEXNR02onDY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W8hmeBylvrVfInpXM960f7jJR6Yopt15KrbKHotw5up79c8YnibbwC2PaNDPb7UJ5 jkGP2/hyb7wMxTO6nKYrwcatQrq5YBbYpNbqIb1EuePSH6Q4hwr7OWx5fqHdjDUAMn KyRuVZBbRBJk4dv0sd2TOwL7ovVVrdVz4/ODVCjk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CDE42D04246; Wed, 7 May 2014 23:12:59 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Wed, 07 May 2014 23:12:58 -0400 Message-ID: <2275177.rIJVeTRPdD@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <01P7J7H3JV12000052@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/18dDJS2s-OwY0pYnasg7ZQUdvhI Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 03:13:07 -0000 On Wednesday, May 07, 2014 15:26:33 Murray S. Kucherawy wrote: > On Wed, May 7, 2014 at 3:01 PM, Ned Freed wrote: > > First, there needs to be a discussion about whether DKIM-specific or > > DMARC-specific codes are what's called for. I can argue this either way > > I was thinking the DMARC draft, since it's active, could be adjusted to > include such a definition rather than doing that here. This one can then > proceed while the DMARC debate resolves. > > > Second, regardless of the outcome of that discussion, this needs to be at > > least > > referenced by the DMARC specification, if not incorporated into it. > > Sure. > > > Third, doing this in appsawg seems like as good a place as any. > > Thanks. Does anyone have information on how MTAs handle unknown result codes? For RFC 4408/7208 we stayed with existing ones. Scott K From nobody Wed May 7 21:38:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FF61A046C for ; Wed, 7 May 2014 21:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 WD-ZlFnOlKXO for ; Wed, 7 May 2014 21:38:45 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC621A03BF for ; Wed, 7 May 2014 21:38:44 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so1990389wes.10 for ; Wed, 07 May 2014 21:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7TxZ3oaqkfoGYfYLtg5wEfkEr7qhjEvvc0W8VHyVZcE=; b=CDg8+w1lBtuLZuaTLNvqUJn4EVtdt7XZKwJbDHhMeY+tS+RhNIL3qCbGZJ6cB37LM0 EPOoj5Au3+to9C3ryJ/2QiuyhjxlLYZjMFcVF//EIdTMIYvLDb5vzZrqIuq1abbN5G0I FwfO8wE1re/Q9PetF0kSXpmFIHy642q8xxvhT0j8lZyxaPZyv9WD6yfYMexrk19BW6Cg iiBZiIo8R5NQItq8i6eiI58xEvchK3kxalfCRiPmrC2n8U7eTNH2NUmc9VXHeDch3/aB nw4JszD6fgXABAqnXWla3G6ybW9H6dNvc62viWhDNCMqGLDDMaXnaWQN1PjQnMK7FYtI OWMg== MIME-Version: 1.0 X-Received: by 10.180.219.75 with SMTP id pm11mr1524252wic.8.1399523920193; Wed, 07 May 2014 21:38:40 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 7 May 2014 21:38:40 -0700 (PDT) In-Reply-To: <2275177.rIJVeTRPdD@scott-latitude-e6320> References: <01P7J7H3JV12000052@mauve.mrochek.com> <2275177.rIJVeTRPdD@scott-latitude-e6320> Date: Wed, 7 May 2014 21:38:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11347bc21e2d6404f8dc0e66 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/j__7RkjNbuWYB55baMQdBKUF1Dk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 04:38:46 -0000 --001a11347bc21e2d6404f8dc0e66 Content-Type: text/plain; charset=UTF-8 On Wed, May 7, 2014 at 8:12 PM, Scott Kitterman wrote: > > Does anyone have information on how MTAs handle unknown result codes? For > RFC > 4408/7208 we stayed with existing ones. > > Are there any that pay attention to them at all, other than to present them in DSNs and logs? For example, I don't think there's much difference between 554 and 554 with a status code in terms of what an MTA is likely to do with the message. -MSK --001a11347bc21e2d6404f8dc0e66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 7, 2014 at 8:12 PM, Scott Kitterman <scott= @kitterman.com> wrote:

Does anyone have information on how MTAs handle unknown result = codes? =C2=A0For RFC
4408/7208 we stayed with existing ones.


Are there any that pay attention to th= em at all, other than to present them in DSNs and logs? =C2=A0 For example,= I don't think there's much difference between 554 and 554 with a s= tatus code in terms of what an MTA is likely to do with the message.

-MSK
--001a11347bc21e2d6404f8dc0e66-- From nobody Thu May 8 00:14:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7DB1A010A for ; Thu, 8 May 2014 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 xsAIYKvWw0os for ; Thu, 8 May 2014 00:14:31 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2920F1A0032 for ; Thu, 8 May 2014 00:14:31 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WiIXB-0004SJ-d7; Thu, 08 May 2014 08:14:25 +0100 Received: from 94.197.120.224.threembb.co.uk ([94.197.120.224] helo=[192.168.43.120]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WiIXA-0002qo-8j; Thu, 08 May 2014 08:14:25 +0100 Message-ID: <536B2ECA.4050804@ninebynine.org> Date: Thu, 08 May 2014 08:14:18 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Erik Wilde References: <53697AD6.2030504@berkeley.edu> In-Reply-To: <53697AD6.2030504@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8exGHsRkLsWbSo47qhlKsnmgnwg Cc: Steve K Speicher , John Arwe , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 07:14:33 -0000 Eric, If the W3C spec is published on REC track, that would be sufficient to allow permanent registration in the header field registry (W3C being a "recognized standards organization" for this purpose). Until it gets to REC track publication, I'd suggest going for an interim provisional registration. Assuming this is a REC track specification, my suggestion would be, rather than going the RFC publication route, to include the registration template in an IANA consideration section in the W3C spec, and cite that in a request to IANA when the document is W3C-approved for CR/PR/REC publication. Also, notify the IANA header field discussion list (and maybe IETF apps-discuss) when the document goes to last call at the W3C. #g -- On 07/05/2014 01:14, Erik Wilde wrote: > hello. > > http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data Platform") is a > current W3C document in last call WD status, and it introduces/uses the > Accept-Post header field proposed in a current draft: > > http://tools.ietf.org/html/draft-wilde-accept-post > > we have publicized this proposed header field on this list, and the latest draft > also includes a list of known implementations of this header field: > > http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 > > after making the specification available for a while, and listing known > implementations, we are wondering about next steps. what it would take to get > this draft moving towards an experimental RFC (apart from some references that > will need to be updated). > > thanks a lot and kind regards, > > dret. > From nobody Thu May 8 01:38:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7531A0293 for ; Thu, 8 May 2014 01:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DizOOvfyBMxG for ; Thu, 8 May 2014 01:38:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id E87691A022F for ; Thu, 8 May 2014 01:38:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTGBZSLS001MTP@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 8 May 2014 01:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399537973; bh=ulWvvgp+RPsCK3CYH7rshZR326dCDCPeiHzjM+0ldFA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=tH/pLA/SFn6U3RGc1pg1x94TDqZQvKn8IgTJkROFjqeslHZnIf/HAUB33JUrLXDHo BYystrM818QuQyfOqNZjjhxN3h+dgGG+eR3jkm9ZZTyqFT6jsk0STi3sz+KRvTKz3z HWfTYXr/Sh8qQ5VJ79OBhaPJgsncvX9Uzp51pQ/g= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7EXXVVVA8000052@mauve.mrochek.com>; Thu, 08 May 2014 01:32:51 -0700 (PDT) Message-id: <01P7JTGAGYIE000052@mauve.mrochek.com> Date: Thu, 08 May 2014 01:27:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 07 May 2014 21:38:40 -0700" References: <01P7J7H3JV12000052@mauve.mrochek.com> <2275177.rIJVeTRPdD@scott-latitude-e6320> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xmBboyNnAiIvNFuBw7jIGvUVpTY Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:38:03 -0000 > On Wed, May 7, 2014 at 8:12 PM, Scott Kitterman wrote: > > > > Does anyone have information on how MTAs handle unknown result codes? For > > RFC > > 4408/7208 we stayed with existing ones. > > > > > Are there any that pay attention to them at all, other than to present them > in DSNs and logs? For example, I don't think there's much difference > between 554 and 554 with a status code in terms of what an MTA is likely to > do with the message. First, mailing list managers most certainly do parse DSNs and pay attention to the codes they find in them. Second, this is getting to be seriously annoying. You can't on the one hand claim mailing list managers are unwilling to change things while failing to provide the information that would, you know make it worth their while to actually make some changes. Ned From nobody Thu May 8 01:42:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630901A04A3 for ; Thu, 8 May 2014 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 g7pWotMddqDz for ; Thu, 8 May 2014 01:42:00 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93A1A0265 for ; Thu, 8 May 2014 01:42:00 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 30A65F8C001; Thu, 8 May 2014 08:41:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1399538514-28427-28427/12/32; Thu, 8 May 2014 08:41:54 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 8 May 2014 10:41:53 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <60f26b51-3b7b-4975-a371-5c5eefde1780@gulbrandsen.priv.no> In-Reply-To: <01P7JTGAGYIE000052@mauve.mrochek.com> References: <01P7J7H3JV12000052@mauve.mrochek.com> <2275177.rIJVeTRPdD@scott-latitude-e6320> <01P7JTGAGYIE000052@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0vlX_V_yp4CmlFKovFII7Lv8gcI Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:42:02 -0000 On Thursday, May 8, 2014 10:27:18 AM CEST, Ned Freed wrote: > Second, this is getting to be seriously annoying. You can't on the one hand > claim mailing list managers are unwilling to change things while failing to > provide the information that would, you know make it worth their while to > actually make some changes. +1 Publish, please. Arnt From nobody Thu May 8 06:26:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60FA1A02BC for ; Thu, 8 May 2014 06:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ADYxT039Dyda for ; Thu, 8 May 2014 06:26:27 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 65FCB1A02AA for ; Thu, 8 May 2014 06:26:27 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so2560853wes.10 for ; Thu, 08 May 2014 06:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QdZfyQHGRGV4Y8CJqHdV0HUaoJkv568asUsysw7/vOk=; b=Ysc6h07yoRFLS3mqT+OBQqUqEzsbtBBMM2BsfeBzsOLwaS1hfWfyPj6hUTYEMO9XHI d39gexGKCwc0SPGquX8DtQRI5fVU8fzpb/QqJNgTdw4e7yYeox2UlUkbLj5K8AAzd3ph wFvUsxmX9Y47WPhBTfKXeMGXhkJOjUWfDUCagMMxpUfchtf8XpbQdxURxangpnMcZE/5 n6Xd+ERh/tBnIIte9ZpKn7rLuO9AcVdUCjIdsotEoZltmyvnWJtpRxLq0cDXGWa4dJ24 q1X+ag6ApTSQ6kkccCsn5lgaMuMewKaCIXbVUKm/5+sonmMkvI6QGfz/uXONSwAQ84ha ijDw== MIME-Version: 1.0 X-Received: by 10.180.219.75 with SMTP id pm11mr3578839wic.8.1399555582487; Thu, 08 May 2014 06:26:22 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 8 May 2014 06:26:22 -0700 (PDT) In-Reply-To: <01P7JTGAGYIE000052@mauve.mrochek.com> References: <01P7J7H3JV12000052@mauve.mrochek.com> <2275177.rIJVeTRPdD@scott-latitude-e6320> <01P7JTGAGYIE000052@mauve.mrochek.com> Date: Thu, 8 May 2014 06:26:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=001a11347bc256728f04f8e36da9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KphwqHxj6TsF_2piqzEmKQfnQnU Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 13:26:29 -0000 --001a11347bc256728f04f8e36da9 Content-Type: text/plain; charset=UTF-8 On Thu, May 8, 2014 at 1:27 AM, Ned Freed wrote: > First, mailing list managers most certainly do parse DSNs and pay > attention to > the codes they find in them. > Maybe, and that's good to hear if so, but the question Scott asked was about MTAs, not MLMs. I don't remember any code in sendmail, for example, that acted on enhanced status codes specifically. That was the nature of my question. > Second, this is getting to be seriously annoying. You can't on the one hand > claim mailing list managers are unwilling to change things while failing to > provide the information that would, you know make it worth their while to > actually make some changes. > As far as I know, I ever claimed that MLMs are unwilling to change. In fact, I was the one who challenged their immutability. I'm also the one offering to do the work on both documents to make these codes available. So really, what's the problem here? -MSK --001a11347bc256728f04f8e36da9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 8, 2014 at 1:27 AM, Ned Freed <ned.freed@= mrochek.com> wrote:
Firs= t, mailing list managers most certainly do parse DSNs and pay attention to<= br>
the codes they find in them.

Maybe, and= that's good to hear if so, but the question Scott asked was about MTAs= , not MLMs.=C2=A0 I don't remember any code in sendmail, for example, t= hat acted on enhanced status codes specifically.=C2=A0 That was the nature = of my question.
=C2=A0
Second, this is getting to be seriously annoying. You can't on the one = hand
claim mailing list managers are unwilling to change things while failing to=
provide the information that would, you know make it worth their while to actually make some changes.

As far as I = know, I ever claimed that MLMs are unwilling to change.=C2=A0 In fact, I wa= s the one who challenged their immutability.=C2=A0 I'm also the one off= ering to do the work on both documents to make these codes available.=C2=A0= So really, what's the problem here?

-MSK
--001a11347bc256728f04f8e36da9-- From nobody Thu May 8 13:31:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7E1A0146 for ; Thu, 8 May 2014 13:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no 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 qAJFwILIUMJ6 for ; Thu, 8 May 2014 13:31:37 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBB1A0144 for ; Thu, 8 May 2014 13:31:36 -0700 (PDT) Received: (qmail 17547 invoked from network); 8 May 2014 20:31:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 May 2014 20:31:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed7.536be9a3.k1405; i=johnl@user.iecc.com; bh=lmlyRTs75RUJTQnf5MgNvA76rGI59i2tUgdE9pAhRQc=; b=J+6rASV8NfsR4/54dq6RYuNtN7v0vziyDAlR3h6fRBQHaNaRKbgDWtNsSz4LS9W0OQ9cbmMZM4H/Bu6bZr7Q6Pj3ne3FCEkqXSkD0q+vj9w3+kGKTa9diA2jBixFenM9eBgntk3cs+RTbEz5ai1C0DUsFuAo6tXQrL5aEoiYiL4UaV8FqP3P61z0KYsEJ6Lm4GN1JX4stPz//xN4PsbJDwnwstdlBAEOu0IynSjiIMVFIgs7Va5Z/AFDvEngQg5X DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed7.536be9a3.k1405; olt=johnl@user.iecc.com; bh=lmlyRTs75RUJTQnf5MgNvA76rGI59i2tUgdE9pAhRQc=; b=akpYPgojAfSIbExqB3v0W9Bl8mRUYJklrH+GFH+E5GiaeP2BiV8dce4eO+loNh5teEXJ5cVjoERzcvlZG5EkjkcBpjR1z0toEljVcuexpv/PJy+hX5BNHRuHqv1FVj54YxZF/488cKrGkmi0EixLl5P3C51F/eUhyAicWT9Lu3bvYF3dSr4gSFlV2TYWamAxIGpWccYJQ3pCsvXbwsnbe8wd8ER8n1ZfZxUdNaVUIDGKc8rvyl4+QaA9msElhEd3 Date: 8 May 2014 20:31:09 -0000 Message-ID: <20140508203109.3798.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YxymROciwwEf_Lz2_6xXLvKB2b0 Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:31:38 -0000 >Are there any that pay attention to them at all, other than to present them >in DSNs and logs? For example, I don't think there's much difference >between 554 and 554 with a status code in terms of what an MTA is likely to >do with the message. The conventional MTAs I know do little beyond looking at the first digit. ESPs, on the other hand, do all sorts of mind reading games with status codes and messages to try and guess whether the bounce was a "real" one. R's, John From nobody Thu May 8 15:26:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA41A0183 for ; Thu, 8 May 2014 15:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 n0TqLygeOpz8 for ; Thu, 8 May 2014 15:26:50 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2on0638.outbound.o365filtering.com [IPv6:2a01:111:f400:fc04::638]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBCD1A0173 for ; Thu, 8 May 2014 15:26:50 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.949.7; Thu, 8 May 2014 22:26:23 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.126]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.126]) with mapi id 15.00.0949.001; Thu, 8 May 2014 22:26:23 +0000 From: Terry Zink To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures Thread-Index: AQHPakDxVEb+g88pSkKBZ0aFZaVtIJs1skqAgABQBgCAABfyAIABCh+AgAAfa+A= Date: Thu, 8 May 2014 22:26:22 +0000 Message-ID: <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140508203109.3798.qmail@joyce.lan> In-Reply-To: <20140508203109.3798.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.51] x-exchange-antispam-report-test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(50944004)(377454003)(13464003)(189002)(199002)(101416001)(74662001)(95416001)(92566001)(31966008)(46102001)(83322001)(19580405001)(81542001)(81342001)(85306002)(87936001)(15975445006)(19580395003)(74502001)(76482001)(81816001)(2656002)(87266001)(81686001)(83072002)(99396002)(80022001)(50986002)(74876001)(74706001)(94316002)(90146001)(64706001)(65816002)(63696004)(56816006)(59766002)(54356002)(47446003)(53806002)(47976003)(54316003)(49866002)(56776002)(51856002)(47736002)(98676001)(66066001)(95666003)(33646001)(93516002)(74366001)(94946001)(85852003)(97336001)(93136001)(77982001)(97186001)(79102001)(69226001)(20776003)(4396001)(77096001)(76786001)(76796001)(21056001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/x9fVmjLzFqsJP_1Te7nMUlq1W6g Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 22:26:53 -0000 Could we include the following: Code: X.7.22 Sample Text: SPF validation failed and DKIM validation failed Associated basic status code: 5 Description: This status code is returned when a message failed an SPF check, and also failed to validate = DKIM for any reason, contrary to local policy requirem= ents. The reason for this is that there are some policy requirements (e.g., sendi= ng email over IPv6) that require both conditions, and none of the codes in = the existing draft say that both are required. Without it, it could give an= incomplete message back to the sender. -- Terry -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John= Levine Sent: Thursday, May 8, 2014 1:31 PM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for = authentication failures >Are there any that pay attention to them at all, other than to present the= m >in DSNs and logs? For example, I don't think there's much difference >between 554 and 554 with a status code in terms of what an MTA is likely t= o >do with the message. The conventional MTAs I know do little beyond looking at the first digit. ESPs, on the other hand, do all sorts of mind reading games with status codes and messages to try and guess whether the bounce was a "real" one. R's, John _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu May 8 16:48:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6834E1A01FF for ; Thu, 8 May 2014 16:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 xhNzwUmcUtPQ for ; Thu, 8 May 2014 16:48:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 95AA21A01FA for ; Thu, 8 May 2014 16:48:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7KP9J8D3K001WOF@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 8 May 2014 16:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399592619; bh=KsyMxbshe/GgTx25ki1o4iG+O79XnWYa3vptKWpw7rE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=WcqeWJi80bBNcO7ejgnPUuJEdO1/USw35xqs8e1Q2/KZ73ZyD1q+/OAPMEuGS53Ss KL+FXGMab3mPsSJss5rb1t5YnSinyZykZckTUnkdUCwPyX/nZdEhSt5OZG+RXUKRNJ FtvPfY4akiBVXL8/FIy1A4wMeEY3IrbgvpSSwNGQ= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTJWRLO0000052@mauve.mrochek.com>; Thu, 08 May 2014 16:43:37 -0700 (PDT) Message-id: <01P7KP9HHMKQ000052@mauve.mrochek.com> Date: Thu, 08 May 2014 09:52:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 May 2014 06:26:22 -0700" References: <01P7J7H3JV12000052@mauve.mrochek.com> <2275177.rIJVeTRPdD@scott-latitude-e6320> <01P7JTGAGYIE000052@mauve.mrochek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kdDl8kPGSeEoRwRUSL0Aoc7J0tU Cc: Scott Kitterman , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 23:48:48 -0000 > On Thu, May 8, 2014 at 1:27 AM, Ned Freed wrote: > > First, mailing list managers most certainly do parse DSNs and pay > > attention to > > the codes they find in them. > > > Maybe, and that's good to hear if so, but the question Scott asked was > about MTAs, not MLMs. Our MTA includes extensive MLM and gateway functionality, some of which pays attention to enhanced status code values. (And it handles unknown codes just fine.) More generally, there's a big difference between the MTA abstration and actual MTA implementations. And I assume Scott was talking about the latter, not the former. If he was talking about the former, then the question is essentially vacuous since the abstract model is defined by the standards and essentially says that (1) MTAs only act on the first digit of the primary status code and (2) Any agent looking at an extended status code is supposed to fall back to the more general part of the code if it doesn't recognize a specific value. > I don't remember any code in sendmail, for example, > that acted on enhanced status codes specifically. That was the nature of > my question. > > Second, this is getting to be seriously annoying. You can't on the one hand > > claim mailing list managers are unwilling to change things while failing to > > provide the information that would, you know make it worth their while to > > actually make some changes. > > > As far as I know, I ever claimed that MLMs are unwilling to change. In > fact, I was the one who challenged their immutability. I'm also the one > offering to do the work on both documents to make these codes available. > So really, what's the problem here? I ended up conflating a more general, and much more pernicious issue into this discussion. Let me try again. My issue is the implied double standard. SPF and DMARC have harmed existing deployed agents despite the fact that that those agents, are, AFAICT, operate entirely within the scope of what our standards allow and even condone. And we allowed one of these to be published as an RFC and it seems the other is about to be. Now we're considering defining a couple of error codes with the express purpose of trying and mitigate a bit of the damage that's been done. And this is being done in a way which, as I noted above, is not only allowed, an agent would have to incompliant to have an issue. Yet now we seem to be asking, "Do such incompliant agents exist", with the clear implication that it would be a problem for this proposal if they do. Ned From nobody Thu May 8 20:46:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637E1A01BB for ; Thu, 8 May 2014 20:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 IJtGyOKvX_VU for ; Thu, 8 May 2014 20:46:22 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 118AA1A01C3 for ; Thu, 8 May 2014 20:46:21 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so3305429wes.7 for ; Thu, 08 May 2014 20:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gml2VbRr0i79rwGtmhH04FgThNoapM6GszUcT4h+qEc=; b=djH2f+bd3JgpxiQZGrHT7VF4QNZ5Xp9Yzpf/GrFhH4PZ7U+p5jub5mvGgHh1LXb98I jv2QmvWz68jGGG1EfSn+6nuBGhgnmXsIQHKy1pg22bUBf13HmjjebRrjxw5Y4b3kECi3 WodrHtr8OBff6K45wHexO44SMPgif+IWFqxbPdH1hnvKWhss8IkttfWIZDiVC5Z6GEqF dP6LKVnVrTiVjVlwhJGqFdSwHDdSqRVQVN4JdN3D9SrPR3TOEu51n4ZgP5a9KlmC1jhL GnLWU6eqQ/butBufhu4Q5hEPtqb46VhFtlF3mSBq6tXmHZ5yVwBfY3nHJ6RB3tC1knZY BVKw== MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr1227394wiw.5.1399607176871; Thu, 08 May 2014 20:46:16 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 8 May 2014 20:46:16 -0700 (PDT) In-Reply-To: <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Thu, 8 May 2014 20:46:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=f46d043c82469a47e704f8ef70b1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t7FWPa8Z2Yd0n1DbJOx5hcfXe6o Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 03:46:24 -0000 --f46d043c82469a47e704f8ef70b1 Content-Type: text/plain; charset=UTF-8 On Thu, May 8, 2014 at 3:26 PM, Terry Zink wrote: > Could we include the following: > > Code: X.7.22 > Sample Text: SPF validation failed and DKIM validation failed > Associated basic status code: 5 > Description: This status code is returned when a message > failed an SPF check, and also failed to validate > DKIM > for any reason, contrary to local policy > requirements. > > The reason for this is that there are some policy requirements (e.g., > sending email over IPv6) that require both conditions, and none of the > codes in the existing draft say that both are required. Without it, it > could give an incomplete message back to the sender. This seems slippery slope-ish to me. When DKIM comes out, do we also need to register a set for each of the possible {SPF, DKIM, DMARC} combinations? Seems to me you should pick the most serious or comprehensive one, or worst case pick any one that applies, and return that. -MSK --f46d043c82469a47e704f8ef70b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 8, 2014 at 3:26 PM, Terry Zink <tz= ink@exchange.microsoft.com> wrote:
Could we include the following:

=C2=A0 =C2=A0 =C2=A0 Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= X.7.22
=C2=A0 =C2=A0 =C2=A0 Sample Text: =C2=A0 =C2=A0 =C2=A0 =C2=A0SPF validation= failed and DKIM validation failed
=C2=A0 =C2=A0 =C2=A0 Associated basic status code: =C2=A05
=C2=A0 =C2=A0 =C2=A0 Description: =C2=A0 =C2=A0 =C2=A0 =C2=A0This status co= de is returned when a message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 failed an SPF check, and also failed to validate DKIM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 for any reason, contrary to local policy requirements.
The reason for this is that there are some policy requirements (e.g., sendi= ng email over IPv6) that require both conditions, and none of the codes in = the existing draft say that both are required. Without it, it could give an= incomplete message back to the sender.

This seems slippery slope-ish to me.=C2=A0 When DKIM co= mes out, do we also need to register a set for each of the possible {SPF, D= KIM, DMARC} combinations?

Seems to me you should pick the= most serious or comprehensive one, or worst case pick any one that applies= , and return that.

-MSK
--f46d043c82469a47e704f8ef70b1-- From nobody Thu May 8 21:54:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8541A01D3 for ; Thu, 8 May 2014 21:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 G-wRobn4J17n for ; Thu, 8 May 2014 21:54:31 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0820D1A01C7 for ; Thu, 8 May 2014 21:54:31 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id EAE179560EA; Fri, 9 May 2014 00:54:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1399611266; bh=YcoYoVjK/+1+7IKXQLk7WtQSw8qmQCgdJvx8uWvWCBg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vVS6UYfFADQMeH5AToH7IvWJeHIyCgcFPGhTM7JIHsDU8KEmwd2a3XNkmF7DGzDfv LWWVk7SjGWySEJUomA0IedW3Wevs5ObU7jbJnuRzggBcL38b6TNDTqF3olTP4JSgoD I/3TdXQhhMcO7bTPyC5UnxHpOV+1h2h1P6o0QuBM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A8A56956098; Fri, 9 May 2014 00:54:25 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 09 May 2014 00:54:23 -0400 Message-ID: <2395728.0u9x6ECSfO@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <01P7KP9HHMKQ000052@mauve.mrochek.com> References: <01P7KP9HHMKQ000052@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/34T4-vGDT1XTbOapvdzYouyx7CY Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 04:54:32 -0000 On Thursday, May 08, 2014 09:52:13 Ned Freed wrote: > > On Thu, May 8, 2014 at 1:27 AM, Ned Freed wrote: > > > First, mailing list managers most certainly do parse DSNs and pay > > > attention to > > > the codes they find in them. > > > > Maybe, and that's good to hear if so, but the question Scott asked was > > about MTAs, not MLMs. > > Our MTA includes extensive MLM and gateway functionality, some of which pays > attention to enhanced status code values. (And it handles unknown codes > just fine.) > > More generally, there's a big difference between the MTA abstration and > actual MTA implementations. > > And I assume Scott was talking about the latter, not the former. If he was > talking about the former, then the question is essentially vacuous since the > abstract model is defined by the standards and essentially says that (1) > MTAs only act on the first digit of the primary status code and (2) Any > agent looking at an extended status code is supposed to fall back to the > more general part of the code if it doesn't recognize a specific value. > > > I don't remember any code in sendmail, for example, > > that acted on enhanced status codes specifically. That was the nature of > > my question. > > > > > Second, this is getting to be seriously annoying. You can't on the one > > > hand > > > claim mailing list managers are unwilling to change things while failing > > > to > > > provide the information that would, you know make it worth their while > > > to > > > actually make some changes. > > > > As far as I know, I ever claimed that MLMs are unwilling to change. In > > fact, I was the one who challenged their immutability. I'm also the one > > offering to do the work on both documents to make these codes available. > > So really, what's the problem here? > > I ended up conflating a more general, and much more pernicious issue into > this discussion. Let me try again. > > My issue is the implied double standard. SPF and DMARC have harmed existing > deployed agents despite the fact that that those agents, are, AFAICT, > operate entirely within the scope of what our standards allow and even > condone. And we allowed one of these to be published as an RFC and it seems > the other is about to be. > > Now we're considering defining a couple of error codes with the express > purpose of trying and mitigate a bit of the damage that's been done. And > this is being done in a way which, as I noted above, is not only allowed, > an agent would have to incompliant to have an issue. Yet now we seem to be > asking, "Do such incompliant agents exist", with the clear implication that > it would be a problem for this proposal if they do. My question was nothing so nefarious. This is the first time I've run across adding new codes, so I didn't know how it would work out. I'm not familiar with what the standards say about new/unknown codes. If it shouldn't be an issue, then that's great. It would have been nice to have this conversation before RFC 7208 was finished, but you can't have everything. Scott K From nobody Thu May 8 22:02:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DA41A01D3 for ; Thu, 8 May 2014 22:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no 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 iFGo0tTawxuq for ; Thu, 8 May 2014 22:02:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id A17601A01C7 for ; Thu, 8 May 2014 22:02:46 -0700 (PDT) Received: (qmail 88738 invoked from network); 9 May 2014 05:02:41 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 May 2014 05:02:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=164f.536c6171.k1405; i=johnl@user.iecc.com; bh=8yt7gQKWz/r43sBVBP0fUr88D7ZceSCc7btT1PoiAhs=; b=kebyTafzBCEts4wqZ7/6YmTRpF1NymXGe/0xD5xqfPzbLeT0oTkGSA56BrpED5/Xq9yBsVClubY6MMWBGo2tQn1OYESGVE2QJOCReJXGmBdsbfC1QzsUWgNILmJo2d9axkOBkEq+XvC+luyEnW/RxieyklnswGTJycYDdE4UUpc2KPxkxJanEk+phG+FOJBgRpbDV/etoMzGecuEFnKtNG5D5jl2SztK/6Q3TyYFKH4R6COutGoOCkVcLjtTVacY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=164f.536c6171.k1405; olt=johnl@user.iecc.com; bh=8yt7gQKWz/r43sBVBP0fUr88D7ZceSCc7btT1PoiAhs=; b=fEC0X/pDe814SLpFcn7llfflEpIAeCKuRfX4jGGDD1w5EIX5InrZQ4/mhMMkSDpGJI+Wcpdnvc+sCy+NPdamE/jp9MkzHVqW04822C2OAIdpusU6UKDQQPgTFP+ueBPf/rJhZE43lTOx4jOu1PJ/sfKvyVTtFvpACBnRdAsCzEuqVFYP4I56oXNkxhVszt13EjCBTy3iiRQ9Vf+XPqEfemWVnWbIdAZqDuekH9Qs94khjlDO4HigJN31jWIGL20A Date: 9 May 2014 05:02:18 -0000 Message-ID: <20140509050218.5710.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I1QOuJIEqPgy72V-JrRipmxUdyc Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 05:02:48 -0000 >This seems slippery slope-ish to me. When DKIM comes out, do we also need >to register a set for each of the possible {SPF, DKIM, DMARC} combinations? I'm not at all sure this is a rathole we want to go down, but if we do it seems to me it would be more useful to describe the failures at a policy rather than mechanism level, e.g. "not enough authentication for channel" or "not enough authentication for sender policy." The details can be in the text, but the point of carving it up this way is that the former tells the MTA that it might be worthwhile to send it a different way, while the latter says there's something wrong with the message (from the receiver's point of view.) From nobody Thu May 8 23:09:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9D1A01D5 for ; Thu, 8 May 2014 23:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Pg11U62w6qcj for ; Thu, 8 May 2014 23:09:16 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C92661A00FC for ; Thu, 8 May 2014 23:09:15 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-62-536c71053e27 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.9E.04714.5017C635; Fri, 9 May 2014 08:09:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 9 May 2014 08:09:09 +0200 From: Salvatore Loreto To: "apps-discuss@ietf.org" Thread-Topic: Call for Adoption: draft-kucherawy-email-auth-codes Thread-Index: AQHPa00w+1E1yuH5kkGb5gl8Nbu/rw== Date: Fri, 9 May 2014 06:09:09 +0000 Message-ID: <703AE153-B44D-4753-A672-23A8031E2A68@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_703AE153B44D4753A67223A8031E2A68ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjS5rYU6wwYs3NharX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsyuGcwFbcoVK3Y8YWtg7JPtYuTkkBAwkVjVc58RwhaTuHBv PVsXIxeHkMBRRolz55YwQjiLGCXa+5Yzg1SxCZhJPH+4BcwWETCWmLR5CRuILSxgI9F38hw7 RNxRomvaS6YuRg4gW09i9ppEkDCLgIrE/r47rCA2r4C9xIKl35hAbEagxd9PrQGzmQXEJW49 mc8EcZCAxJI955khbFGJl4//sULYShKLbn+Gqk+W2PFsHjvETEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxVK+1xIQlz9mR1Sxg5FjFKFqcWlycm25krJdalJlc XJyfp5eXWrKJERgrB7f81t3BuPq14yFGAQ5GJR5ehWPZwUKsiWXFlbmHGKU5WJTEedvuegcL CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBR/XBTE6LzvwuGYVnu5ve89Jz2YNzVDr0bkWdjL mqD7plyWRU72vZtDxXIu6AtuvLL191vBZXPNjpi+3b0vmf9p8eSPTEf2nbmzZDHbp8+fLiqw vvfcqlkWGb9fNLt5vqvTXGvVs13nY90r7W1nHNIL/xsjVyYgeqJu3fJjEbG5p6b8eNG9U0KJ pTgj0VCLuag4EQBKD8ixdgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PNdQutiL-7x7NgAHk9Nb0AauTT4 Subject: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 06:09:18 -0000 --_000_703AE153B44D4753A67223A8031E2A68ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a formal call for adoption of draft-kucherawy-email-auth-codes into= APPSAWG. The call will close on May 23, 2014. The chairs note that there has already been some _expression_ of interest f= or adoption in a recent thread; however more feedback is requested to make sure appsawg is the right venue = for this draft Please submit comments, concerns, support, etc. for this document's handlin= g by APPSAWG in reply to this thread by May 23, 2014. Note that this is not an indication of support for the document as-is, only= for APPSAWG adopting it for further development. As for the APPSAWG process you will find the mini-charter for the draft at = the end of this message. in order to adopt the draft we also need to secure a minimal set of reviewe= rs and supporters for the document. If you'd like to be added to that list, please say so in your reply. cheers /Salvatore The "email-auth-codes" Mini-Charter ---------------------------------------------- The adoption of SPF and DKIM as emerging email authentication technologies = has been significant. Absent from these, an oversight at the time, is a way to indicate to an SMT= P client the fact that a message is being rejected specifically because one= of these mechanisms failed to authenticate the message. Without these, on= ly generic authentication error codes can be returned. This short document registers new Email Enhanced Status Codes (see RFC 3643= and RFC 5248) so that this can be clearly indicated by SMTP servers. No other work is proposed for this document The following have committed to work on the document through to publication= : Reviewers: (please volunteer!) --_000_703AE153B44D4753A67223A8031E2A68ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


This is a formal call for adoption of draft-kucherawy-email-auth-codes into= APPSAWG.  
The call will close on May 23, 2014.  

The chairs note that there has already been some _expression_ of inter= est for adoption in a recent thread; 
however more feedback is requested to make sure appsawg is the right v= enue for this draft

Please submit comments, concerns, support, etc. for this document's handlin= g by APPSAWG in reply to this thread by May 23, 2014. 
Note that this is not an indication of support for the document as-is,= only for APPSAWG adopting it for further development.

As for the APPSAWG process you will find the mini-charter for the= draft at the end of this message.
in order to adopt the draft we also need to secure a minimal set of re= viewers and supporters for the document.
If you'd like to be added to that list, please say so in your reply.

cheers
/Salvatore



The "email-auth-codes" Mini-Charter
----------------------------------------------

The adoption of SPF and DKIM as emerging email authentication technologi= es has been significant.  
Absent from these, an oversight at the time, is a way to indicate to an SMT= P client the fact that a message is being rejected specifically because one= of these mechanisms failed to authenticate the message.  Without thes= e, only generic authentication error codes can be returned.

This short document registers new Email Enhanced Status Codes (see RFC 3= 643 and RFC 5248) so that this can be clearly indicated by SMTP servers. No other work is proposed for this document

The following have committed to work on the document through to publication= :

Reviewers: (please volunteer!)

--_000_703AE153B44D4753A67223A8031E2A68ericssoncom_-- From nobody Thu May 8 23:27:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39601A01E7 for ; Thu, 8 May 2014 23:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham 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 cV-bAihmz1B2 for ; Thu, 8 May 2014 23:27:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D361A01E5 for ; Thu, 8 May 2014 23:27:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.129.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s496Qh5u010955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 May 2014 23:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399616815; bh=UowgtQ0aHOOl9ArVU6FH5octg/R0PGgFbDCKMALdDO8=; h=Date:To:From:Subject:In-Reply-To:References; b=ueXJN19J/ZzII5JAPov84Ou8yGP3N1bLdSnikILW4ky13tf8O16u+8rHRdhNWfRiC Yo00cTSO2m+26pSD3WTDYKtN7wUuTr8H0WZq+5JzuUCer3wDuXkhLT1147hlNO2KxY uexjdwJxGE4ispiqS+zU6acMh5Ezln9x3b+DVROc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399616815; i=@elandsys.com; bh=UowgtQ0aHOOl9ArVU6FH5octg/R0PGgFbDCKMALdDO8=; h=Date:To:From:Subject:In-Reply-To:References; b=MCcEp1Dry5y8aiCp+Xt3hgS8VgeQ26k610hYwGLfGIRd1n6azyq8VHtzbaGTY8INj e+mdyaZNwLyZE5xdRrlYUwxGIII3m0hTHf682zvmHmB7Ah680DdiQ8iDuKJZ4fWAuv 7jDbPSIk+hSI9Qhnzr9y6PL6eArNLR1QbwN2iezc= Message-Id: <6.2.5.6.2.20140508225357.0b9ce158@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 May 2014 23:03:28 -0700 To: Terry Zink , apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf .exchangelabs.com> References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PMXdnbAqQAlLYIN6qtIWx_x2EmE Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 06:27:05 -0000 Hi Terry, At 15:26 08-05-2014, Terry Zink wrote: >Could we include the following: > > Code: X.7.22 > Sample Text: SPF validation failed and DKIM validation failed > Associated basic status code: 5 > Description: This status code is returned when a message > failed an SPF check, and also failed to > validate DKIM > for any reason, contrary to local policy > requirements. > >The reason for this is that there are some policy requirements >(e.g., sending email over IPv6) that require both conditions, and >none of the codes in the existing draft say that both are required. >Without it, it could give an incomplete message back to the sender. The above suggestion looks practical. The downside is that it is a path leading to a list of codes to describe local policy requirements. There is a combination of two IETF technologies. It looks odd to express the failure through one code. Regards, S. Moonesamy From nobody Fri May 9 02:10:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87541A0232 for ; Fri, 9 May 2014 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 R00iiIyrQqRs for ; Fri, 9 May 2014 02:10:04 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id D3F261A022E for ; Fri, 9 May 2014 02:10:03 -0700 (PDT) Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 09:09:57 +0000 Message-ID: <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Terry Zink References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Fri, 9 May 2014 10:07:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA0032.eurprd07.prod.outlook.com (10.141.45.160) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(189002)(199002)(377454003)(13464003)(50944004)(76176999)(62236002)(19580405001)(79102001)(44736004)(50226001)(50466002)(20776003)(99396002)(81686999)(66066001)(50986999)(4396001)(101416001)(74502001)(93916002)(19580395003)(42186004)(1511001)(31966008)(87976001)(76482001)(86362001)(44716002)(92726001)(83322001)(46102001)(33646001)(77982001)(81342001)(61296002)(92566001)(47776003)(85852003)(81816999)(62966002)(80022001)(83072002)(74662001)(87286001)(89996001)(64706001)(14496001)(23676002)(81542001)(77156001)(21056001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Mfj2ZLm80IPBgjqrezbHFAy7TGM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:10:07 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "Terry Zink" Cc: Sent: Friday, May 09, 2014 4:46 AM > On Thu, May 8, 2014 at 3:26 PM, Terry Zink wrote: > > > Could we include the following: > > > > Code: X.7.22 > > Sample Text: SPF validation failed and DKIM validation failed > > Associated basic status code: 5 > > Description: This status code is returned when a message > > failed an SPF check, and also failed to validate > > DKIM > > for any reason, contrary to local policy > > requirements. > > > > The reason for this is that there are some policy requirements (e.g., > > sending email over IPv6) that require both conditions, and none of the > > codes in the existing draft say that both are required. Without it, it > > could give an incomplete message back to the sender. > > > This seems slippery slope-ish to me. When DKIM comes out, do we also need > to register a set for each of the possible {SPF, DKIM, DMARC} combinations? No, we just use the traditional programmer's technique of coding it in binary, 1 for SPF, 2 for DKIM, 4 for DMARC, 8 for the next iteration in what is, has been and looks likely to remain a major issue in Internet traffic. If needed, you can add these values to a base, to lift them out of any existing range. And we are talking of fairly substantial protocols, SPF, DKIM, worth treating as distinct. Tom Petch > > Seems to me you should pick the most serious or comprehensive one, or worst > case pick any one that applies, and return that. > > -MSK > From nobody Fri May 9 02:32:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7C1A0243 for ; Fri, 9 May 2014 02:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6] autolearn=no 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 3qyrhdEh29xA for ; Fri, 9 May 2014 02:32:47 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA11A0238 for ; Fri, 9 May 2014 02:32:46 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 47A9BFA032D; Fri, 9 May 2014 09:32:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1399627960-3291-3291/11/1; Fri, 9 May 2014 09:32:40 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Fri, 9 May 2014 11:32:39 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> In-Reply-To: <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vDT5MLbNTYbwN9ByLXPstLCOLRY Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:32:48 -0000 There's always been cases where several status codes were possible, e.g. 5.2.x+5.4.y. AFAICT servers generally report whichever issue they notice first, which is perhaps not perfect but has been good enough for a long time. Why does SPF+DKIM warrant more protocol treatment? Arnt From nobody Fri May 9 02:48:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97521A0238 for ; Fri, 9 May 2014 02:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 UrSqix8u44lA for ; Fri, 9 May 2014 02:48:56 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D92C41A0237 for ; Fri, 9 May 2014 02:48:55 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id gq1so4382582obb.36 for ; Fri, 09 May 2014 02:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=941ozI/jhLdMSWlob5qkT0F4n1mTejCdhz/GrAHLrPA=; b=ZwknlNPUCnX5Ln5DMOjNKripTglhGlxqnjTNNNpp44ueiGP+E0LYg9z6jmd/W2ezzl PHfVvQfJbhmc2gq9rogiAZ1p1NWb+nPPv5+IluE0CBBq+yuLAiXhRh98YSxZgxtdXZx6 GufBDLbFpbsTfEEGCUQ0Wkj5kDoO7T0cJTnDA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=941ozI/jhLdMSWlob5qkT0F4n1mTejCdhz/GrAHLrPA=; b=FdyouAm85vHnRRXtjafdw3Op0tRHuBZ86Cdo/sKtknP12NTQXZzPOf4OAyVcDJqoo3 Pebb5DsRGHcj1vzt9rq5xjPjIQkLR/XcItQqkpICQgtnckWt3PaVNP6uEwgPg0IfZFYK fJxlsWU4Uve/7+7y9dEdZA62yCW8y7dZ3Bn+kfrzi2sVqAnDGxWIpMQiDND4THccgUPC wB/8B8OmxJgxkWlr58YlcQWQrYJnWAfHiyn2T2jLJeIMkse7w+1MVFgKN05MCCAOf1sQ bl+1zjMy75oSYi3RlBYQPqsQ01CwVRrhvaSq/5xf8WhDa6BJ5RHsttrsNGV1g/VHXspN LGrg== X-Gm-Message-State: ALoCoQmWXb6fqPjKgnbxGamgAEUie/ENecMWb0YOrD7gYwnVwTPxXVmJn2OdmVUda5Hvp7DrkRkK MIME-Version: 1.0 X-Received: by 10.182.49.135 with SMTP id u7mr10786889obn.73.1399628930827; Fri, 09 May 2014 02:48:50 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Fri, 9 May 2014 02:48:50 -0700 (PDT) In-Reply-To: <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> Date: Fri, 9 May 2014 10:48:50 +0100 Message-ID: From: Dave Cridland To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=047d7b5d8c893d5b8e04f8f48124 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F7JZn5I-d5ARHctZ04rVy_tFIY8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:48:56 -0000 --047d7b5d8c893d5b8e04f8f48124 Content-Type: text/plain; charset=UTF-8 On 9 May 2014 10:32, Arnt Gulbrandsen wrote: > There's always been cases where several status codes were possible, I wonder if it's worthwhile allowing multiple codes to be reported? Should be trivial to specify. --047d7b5d8c893d5b8e04f8f48124 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 9 May 2014 10:32, Arnt Gulbrandsen <arnt@gulbrandsen.pri= v.no> wrote:
There's always been cases where several = status codes were possible,

I wonder if it&= #39;s worthwhile allowing multiple codes to be reported? Should be trivial = to specify.
--047d7b5d8c893d5b8e04f8f48124-- From nobody Fri May 9 05:07:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A821A028A for ; Fri, 9 May 2014 05:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 VwSm-hazeEHx for ; Fri, 9 May 2014 05:06:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 621471A028C for ; Fri, 9 May 2014 05:06:55 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LzLJR-1Ww3Ou3d1l-014SW9; Fri, 09 May 2014 14:06:45 +0200 Message-ID: <536CC4D2.4000709@gmx.de> Date: Fri, 09 May 2014 14:06:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erik Wilde , "apps-discuss@ietf.org application-layer protocols" References: <53697AD6.2030504@berkeley.edu> In-Reply-To: <53697AD6.2030504@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gDwqCO48anT573KoPfs9TYrBYqJqemjKgidMklTNjh0lLGvcpI8 1fu6YesqIZ0R6zGtZ/MVgOLWimh4rlvMI29vpOkfKc1+WR8LpFaVqb2WV0rNyqizwbTQ/I2 dDt58LtOMOGDtpNfqSM4NNGuWBb+9oJ3SeyIMJIuZ1ts5F8tjSDe+CKZc764kNtHRQwELj7 Fs32+DRmHo/2HwwWrKupw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1-Fz2R1OwWdFplcaJfbQXb-BHds Cc: Steve K Speicher , John Arwe , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:06:59 -0000 On 2014-05-07 02:14, Erik Wilde wrote: > hello. > > http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data > Platform") is a current W3C document in last call WD status, and it > introduces/uses the Accept-Post header field proposed in a current draft: > > http://tools.ietf.org/html/draft-wilde-accept-post > > we have publicized this proposed header field on this list, and the > latest draft also includes a list of known implementations of this > header field: > > http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 > > after making the specification available for a while, and listing known > implementations, we are wondering about next steps. what it would take > to get this draft moving towards an experimental RFC (apart from some > references that will need to be updated). > > thanks a lot and kind regards, > > dret. Editorial question: The app:accept element is similar to the HTTP Accept request header field [RFC2616]. Media type parameters are allowed within Accept- Post, but Accept-Post has no notion of preference - "accept-params" or "q" arguments, as specified in Section 14.1 of [RFC2616], are not significant. What is "app:accept"? Furthermore: the fact that we'd have both Accept-Patch and Accept-Post kind of implies that maybe something more generic is needed. Wouldn't it make more sense to allow "Accept" as a response header field? Best regards, Julian From nobody Fri May 9 05:35:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545301A0298 for ; Fri, 9 May 2014 05:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 RFzYC8P4dMIq for ; Fri, 9 May 2014 05:35:26 -0700 (PDT) Received: from nm24-vm9.bullet.mail.ir2.yahoo.com (nm24-vm9.bullet.mail.ir2.yahoo.com [212.82.97.33]) by ietfa.amsl.com (Postfix) with ESMTP id B20371A0297 for ; Fri, 9 May 2014 05:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=gcom1024; t=1399638920; bh=iTsb2NCos74erFYTHxkyuSXlHYUcBZjfRjmy8Avib6c=; h=Received:Received:Received:X-Yahoo-Newman-Id:Received:DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=FTmK9EHDjovrSYivtuS8G3H9Sk1biVoGcQVwCRanMXuk+L4D2weRobkxgBA0YR80gVTZ3Jal2uvTPz31SmgFCThNEsON4bIhhJKabtJYc4NELNN8hDdkf8LPIMtwdvPiANhSfLEcIfZuwvsQX3eBb16DICilvPx3LPoOZBc4X1A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=gcom1024; d=yahoo.com; b=RropCRJ4T5VEEKjgP/HbOfgVIwxvSfTWTT2zeEvdU9cqrGnootYgz19xyCr3TjOF2nWypC51Uuhq73SGoFJqASeJkP1HEFSHvaoCB8Ap/Fnjrk3KK/2V/RSAzwseQDAmxA2gbXcFwQFrU3CCGTr7NA9L8rpVp/srO4beIGLFhRE=; Received: from [212.82.98.127] by nm24.bullet.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:35:20 -0000 Received: from [212.82.98.66] by tm20.bullet.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:35:20 -0000 Received: from [127.0.0.1] by omp1003.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:35:20 -0000 X-Yahoo-Newman-Id: 7300.29074.bm@omp1003.mail.ir2.yahoo.com Received: (qmail 39447 invoked from network); 9 May 2014 12:35:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399638919; bh=iTsb2NCos74erFYTHxkyuSXlHYUcBZjfRjmy8Avib6c=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=tANls/x28MrCMilmdAd1PbFP6ybvwVyT+/GWmxZiEJu2saeeU7so2qHg2NSY0iBt8kZ64LccDs9l45BTMAMkcZ0nF945CiSTbaciPRajEwkuabFWnMm9gyQHvYoRUY/hixMo5ckEwaVqDSLZgUMaEtLnGlxM8Jn8IUYglUydisM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KtXc7G8VM1kqQX5IpNR6r_WJ2drRdVBKbhpuOA13b0.uNkq GNgHO6uY7g3QEaB2Kh7fTjRxqknvHaCKaEbXh3feUKMTFRe.xbKz6rs7cG33 yVRKat5SbeXZnA5dLlJ45ogRarHlr_OlnwJcoczCxnZBvH.uW2Su4MkZv00q aoyl4GS9yLHRkDHCIZOIjZnCRHrVRX32n3K9x7nKuy2s0IDjY.fi2QoNA6mu Y3Bb2AAq18TMXpGd05XuG8C3ZQIWK20ztT8VEaAu_LAeeGpX74q8Pov8wSbo 4kYv_yFDICQbjkiZkYhB9H0uO5j4vX74RiKmAgmKYYx98SSUFL.iGRIsUlBO MnUo9TW_vveWdY00a3GnWCvncPG82a_7DMYySBZ6z8x5CbkWpx0F3Mr_LrMU lkT5qEeFmX90mPSXtbVI2I2wl2J2tkAT7dcqxHbb5nbSCM495dPqaqlvkGFe 8d9Sizrr0hVmkdnKorg62bm9Vge8zTDgqr4OTFvJHo22IxGYSRUYja.bAIAi Pwj_XUIX89VaU0_8Pau1qSOikreCwcRtl5JhfHPi8O8f.0SaoJfuIuoL5bFY ht7AjfXiNEM9O6aS7c5qZvQpS9SNJkNvqi8TzP3PILFWO.iaoB0aNeqflNEj ogUlBIcW9a6BOCSEucMVZCZBucolpYBCrxf2IGiRq.5yB.JZ8QLawcSPTTWG QcbeGvDmOWM5ZFzDFKLijZ2yrvqc_pYaKasw.slfjBmPxgnQ8ex.wiKn5UUp dRY365_WQB8ywvwgLm9JeMy6.2y1jD5r6nmnbR8DNxiG4ss0GUQkg_Czp6y_ IepDWQRA6Lw1LpdtgjRuDMWSxDWpTtdvZsGw3ZPnU8Y3Ifc9SsQ-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- X-Rocket-Received: from mail-we0-f182.google.com (mamund@74.125.82.182 with plain [188.125.68.56]) by smtp107.mail.ir2.yahoo.com with SMTP; 09 May 2014 12:35:19 +0000 UTC Received: by mail-we0-f182.google.com with SMTP id t60so3836433wes.41 for ; Fri, 09 May 2014 05:35:18 -0700 (PDT) X-Gm-Message-State: ALoCoQl7kdNfkzWRKg8HYmGF0zFjSiNE2KFgcJAfOM3CXg88tIKqyIvkZQYh9y+yGcmYLDYrZaED X-Received: by 10.194.78.4 with SMTP id x4mr2178223wjw.58.1399638918858; Fri, 09 May 2014 05:35:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.79.169 with HTTP; Fri, 9 May 2014 05:34:58 -0700 (PDT) In-Reply-To: <536CC4D2.4000709@gmx.de> References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> From: mike amundsen Date: Fri, 9 May 2014 08:34:58 -0400 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7bfcf9149291d604f8f6d48a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1yN_YRAFo9n0frpM959ZApX9SQQ Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:35:27 -0000 --047d7bfcf9149291d604f8f6d48a Content-Type: text/plain; charset=UTF-8 +1 on an "Acceptable" header to match "Allow" for OPTIONS and HTTP 406. been doing something similar for quite a while (old blog post here:[1]). [1] http://www.amundsen.com/blog/archives/716 mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, May 9, 2014 at 8:06 AM, Julian Reschke wrote: > On 2014-05-07 02:14, Erik Wilde wrote: > >> hello. >> >> http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data >> Platform") is a current W3C document in last call WD status, and it >> introduces/uses the Accept-Post header field proposed in a current draft: >> >> http://tools.ietf.org/html/draft-wilde-accept-post >> >> we have publicized this proposed header field on this list, and the >> latest draft also includes a list of known implementations of this >> header field: >> >> http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6 >> >> after making the specification available for a while, and listing known >> implementations, we are wondering about next steps. what it would take >> to get this draft moving towards an experimental RFC (apart from some >> references that will need to be updated). >> >> thanks a lot and kind regards, >> >> dret. >> > > Editorial question: > > The app:accept element is similar to the HTTP Accept request header > field [RFC2616]. Media type parameters are allowed within Accept- > Post, but Accept-Post has no notion of preference - "accept-params" > or "q" arguments, as specified in Section 14.1 of [RFC2616], are not > significant. > > What is "app:accept"? > > Furthermore: the fact that we'd have both Accept-Patch and Accept-Post > kind of implies that maybe something more generic is needed. > > Wouldn't it make more sense to allow "Accept" as a response header field? > > Best regards, Julian > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7bfcf9149291d604f8f6d48a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on an "Acceptable" header to match "= ;Allow" for OPTIONS and HTTP 406.

been doing somet= hing similar for quite a while (old blog post here:[1]).





On Fri, May 9, 2014 at 8:06 AM, Julian R= eschke <julian.reschke@gmx.de> wrote:
On 2014-05-07 02:14, Erik Wilde wrote:
hello.

= http://www.w3.org/TR/ldp/#header-accept-post (the "Linked D= ata
Platform") is a current W3C document in last call WD status, and it introduces/uses the Accept-Post header field proposed in a current draft:
http://tools.ietf.org/html/draft-wilde-accept-post

we have publicized this proposed header field on this list, and the
latest draft also includes a list of known implementations of this
header field:

http://tools.ietf.org/html/draft-wilde-accept-pos= t-02#section-6

after making the specification available for a while, and listing known
implementations, we are wondering about next steps. what it would take
to get this draft moving towards an experimental RFC (apart from some
references that will need to be updated).

thanks a lot and kind regards,

dret.

Editorial question:

=C2=A0 =C2=A0The app:accept element is similar to the HTTP Accept request h= eader
=C2=A0 =C2=A0field [RFC2616]. =C2=A0Media type parameters are allowed withi= n Accept-
=C2=A0 =C2=A0Post, but Accept-Post has no notion of preference - "acce= pt-params"
=C2=A0 =C2=A0or "q" arguments, as specified in Section 14.1 of [R= FC2616], are not
=C2=A0 =C2=A0significant.

What is "app:accept"?

Furthermore: the fact that we'd have both Accept-Patch and Accept-Post = kind of implies that maybe something more generic is needed.

Wouldn't it make more sense to allow "Accept" as a response h= eader field?

Best regards, Julian


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--047d7bfcf9149291d604f8f6d48a-- From nobody Fri May 9 05:39:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE201A02D9 for ; Fri, 9 May 2014 05:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 GOZvZrSbzlTj for ; Fri, 9 May 2014 05:39:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 789571A02DD for ; Fri, 9 May 2014 05:39:50 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSMP5-1WGvho2tAp-00TT3f; Fri, 09 May 2014 14:39:39 +0200 Message-ID: <536CCC87.5090706@gmx.de> Date: Fri, 09 May 2014 14:39:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mike amundsen References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g2vm8QiyeRtZZdCojwd65r4oz0TvZ3L8P+Yh2chTtSXP8jPdmaG 1EWslPHUeB9Z1Jfv0NDH4CDwFYTy3NlJbYQu8X8AEx0jiNuyfB8orqKsowlBjGAA4cCLP2Y VVubPVn+OF67ygeDlgrb8X5NmlRzT2ODaABGR8/qtWsWBGbTKlww0L1P6TkdkhHnXEMjkKB vU12tkX7xbK13EBlXPK2A== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iSTBmeU8DtQptUKlaefryi836qw Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:39:55 -0000 On 2014-05-09 14:34, mike amundsen wrote: > +1 on an "Acceptable" header to match "Allow" for OPTIONS and HTTP 406. > > been doing something similar for quite a while (old blog post here:[1]). > ... Can't we just extend "Accept" to be a response header field? Best regards, Julian From nobody Fri May 9 05:46:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D421A02A9 for ; Fri, 9 May 2014 05:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 qaoaYoo_k6XR for ; Fri, 9 May 2014 05:46:30 -0700 (PDT) Received: from nm28-vm2.bullet.mail.ir2.yahoo.com (nm28-vm2.bullet.mail.ir2.yahoo.com [212.82.97.62]) by ietfa.amsl.com (Postfix) with ESMTP id 275D71A0298 for ; Fri, 9 May 2014 05:46:29 -0700 (PDT) Received: from [212.82.98.58] by nm28.bullet.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:46:24 -0000 Received: from [212.82.98.73] by tm11.bullet.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:46:24 -0000 Received: from [127.0.0.1] by omp1010.mail.ir2.yahoo.com with NNFMP; 09 May 2014 12:46:24 -0000 X-Yahoo-Newman-Id: 800869.45272.bm@omp1010.mail.ir2.yahoo.com Received: (qmail 4218 invoked from network); 9 May 2014 12:46:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399639584; bh=nMsoD8zXRYys1yj/Ce2e+37/CRkXy/O+fwCIxcq0KpY=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=xGdYgwfekS3wYz5olyTAqVgiEH1Ngl8z5NdDzsReJs6YCPAjwO/Z5RAwWqiZ345O7wfsq5pWmywjt3RpyQSgQ32x+BKuBD+YcPXZrIPsDh/8hJ3LwNsgOCy20XyeSmbq3sWn3kz3PRD3/XxSFgQfuUM1O1TEmIaf5wK/o59wToI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dr.mypoVM1m0mNDswM7l_oJUeIK_V.s6SGg6Y.ZB8V9irQG 5NDIzbz5FJsO2crvShzzl2mfWfUBKrecPt_JtCJe9SydBQBcHTZaZqUfP2Fy ZjWCXd4ICKCrrVyJs.c68EsQRotxs7UhnI3o9kRLVUiPPQnLpN_iUWwTLBKy KaYZDUgZ1tnGe_ePbBJnl_v..3QPKdlzU0NNB_HG2BDXVd4DWK5ZiTAO5xnW XB0x7WG7lWRCFZoNKBYVC9XipkVd8zQ8g87I17s7l0apJWuKbsYoHd_PvDUp O3k5DKTWFb3vdPN3ZWp_9UoiHeatswc.XEkXFU3fUJMC9x5A.of8l.q1p9Ug 6s2gQ1g07zMV.URtVuHPsqhEAXQ6kMxV24TMzyzef_AYvsK0A91UhOcn9zwY kE03Whe_9eKRwa5O4tZ0vwGxq3B0Swj7N6P2JpjG7_hswPyr9pR3GNngfdMu ksnrda4Js_PX10IDd1j882z_8v1vQ4Xfvbn0upQ1TVT.dO5trUQ5foGRIlaI Kgr1briBZN4BqhxdRqBPuNpP5hjECskR6nEeroSuofiuA_sC.5ICDjt_Jc_L rnTe4KALDYyLt19swsxiaV8WOAR28vqEr5dwA9VOZjQlQHy6ruEpa0BUQTr2 gVPKJ1y93gtdoMJRuiuF.PVsAE04y8FjmuVwUVsEMZy5JC75QozEdNIyTIyi h9jRk_C9k9HFExhWY346SC1IPgVc3MSNoUMFbAj0zHOkex7x8sRx4REx_Cc5 toOH5DOC.cUcp7OGt X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- X-Rocket-Received: from mail-we0-f181.google.com (mamund@74.125.82.181 with plain [188.125.68.56]) by smtp127.mail.ir2.yahoo.com with SMTP; 09 May 2014 12:46:24 +0000 UTC Received: by mail-we0-f181.google.com with SMTP id w61so3793265wes.26 for ; Fri, 09 May 2014 05:46:23 -0700 (PDT) X-Gm-Message-State: ALoCoQlmQXlQR6PTCTs4fWpiVB3QH23NqWewl3l+3cd0+9K1e4KHXZhCxS2pPdSge7+ueuGqF0K3 X-Received: by 10.180.94.37 with SMTP id cz5mr3204134wib.19.1399639583696; Fri, 09 May 2014 05:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.79.169 with HTTP; Fri, 9 May 2014 05:46:02 -0700 (PDT) In-Reply-To: <536CCC87.5090706@gmx.de> References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> From: mike amundsen Date: Fri, 9 May 2014 08:46:02 -0400 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d04426c2c33448f04f8f6fc56 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zodENxRO4w8D7FDmHvKjSgapdPk Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:46:31 -0000 --f46d04426c2c33448f04f8f6fc56 Content-Type: text/plain; charset=UTF-8 Think of an OPTIONS response when the client wants to know: 1) what media types are accepted for requests AND 2) what media types are returned for responses i think you need a new header. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, May 9, 2014 at 8:39 AM, Julian Reschke wrote: > On 2014-05-09 14:34, mike amundsen wrote: > >> +1 on an "Acceptable" header to match "Allow" for OPTIONS and HTTP 406. >> >> been doing something similar for quite a while (old blog post here:[1]). >> ... >> > > Can't we just extend "Accept" to be a response header field? > > Best regards, Julian > --f46d04426c2c33448f04f8f6fc56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Think of an OPTIONS response when the client wants to know= :
1) what media types are accepted for requests
AND
2) what media types are returned for responses

i = think you need a new header.





On Fri, May 9, 2014 at 8:39 AM, Julian R= eschke <julian.reschke@gmx.de> wrote:
On 2014-05-09 14:34, mike amundsen wrote:
+1 on an "Acceptable" header to match "Allow" for OPTIO= NS and HTTP 406.

been doing something similar for quite a while (old blog post here:[1]).
...

Can't we just extend "Accept" to be a response header field?<= br>
Best regards, Julian

--f46d04426c2c33448f04f8f6fc56-- From nobody Fri May 9 05:46:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE51A02B0 for ; Fri, 9 May 2014 05:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TMsyW7fprryq for ; Fri, 9 May 2014 05:46:31 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3ED1A02A3 for ; Fri, 9 May 2014 05:46:31 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so1256351wib.5 for ; Fri, 09 May 2014 05:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nnp7w/bdM3BtIHe4EFt54YZG8FtC5woMfCJR/Qv1Q4E=; b=buB7CsZ+ANb8UBfGmXlTka5f/Yu8/Wg5zvrcknRXBfAaQqr8wxs5mNN9JD2i0b8jHT D4Cyd7kLh9AfAiebhw/ZrGmrllHwnbMjJuk6I5f3B0Sul4TqDGNhFPErdi6tLC44ZWDy hra8J5HF/GYbQMdOmTBsDyCp+rvzP6acahXO02tx+eTsycEpn8YfkoBLuccRQWrDUlY9 wvzpHlMf6C4MQzp/8HfTPPLk46IYFSQKW8VQoFutlug09SFa3zdiQmOGg8t56XtIuR4A 57hOSr1pgH0nj9pn4Mzsxsl3Uda9l/t6TX/liFOoBrjpb7CnCV95WHr0AiSYCuTlmiSL 1tTg== MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr3203426wiw.5.1399639586003; Fri, 09 May 2014 05:46:26 -0700 (PDT) Received: by 10.216.223.68 with HTTP; Fri, 9 May 2014 05:46:25 -0700 (PDT) Received: by 10.216.223.68 with HTTP; Fri, 9 May 2014 05:46:25 -0700 (PDT) In-Reply-To: <536CCC87.5090706@gmx.de> References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> Date: Fri, 9 May 2014 05:46:25 -0700 Message-ID: From: James M Snell To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d043c824656641e04f8f6fc36 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AfZ6kT4-lmes22uMgZoEcbvnuHI Cc: Steve K Speicher , John Arwe , IETF Apps Discuss , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:46:33 -0000 --f46d043c824656641e04f8f6fc36 Content-Type: text/plain; charset=UTF-8 -1.. In most cases where I've used this kind of mechanism, it is important to distinguish what you'd accept via post separately than what you'd accept via patch or put. There is also no requirement for q-value ordering. Reusing Accept would mean requiring special case handling that's just not worth the effort when the separate headers approach gets us easily where we want to go. On May 9, 2014 5:39 AM, "Julian Reschke" wrote: > On 2014-05-09 14:34, mike amundsen wrote: > >> +1 on an "Acceptable" header to match "Allow" for OPTIONS and HTTP 406. >> >> been doing something similar for quite a while (old blog post here:[1]). >> ... >> > > Can't we just extend "Accept" to be a response header field? > > Best regards, Julian > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d043c824656641e04f8f6fc36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

-1.. In most cases where I've used this kind of mechanis= m, it is important to distinguish what you'd accept via post separately= than what you'd accept via patch or put. There is also no requirement = for q-value ordering. Reusing Accept would mean requiring special case hand= ling that's just not worth the effort when the separate headers approac= h gets us easily where we want to go.

On May 9, 2014 5:39 AM, "Julian Reschke&quo= t; <julian.reschke@gmx.de&g= t; wrote:
On 2014-05-09 14:34, mike amundsen wrote:
+1 on an "Acceptable" header to match "Allow" for OPTIO= NS and HTTP 406.

been doing something similar for quite a while (old blog post here:[1]). ...

Can't we just extend "Accept" to be a response header field?<= br>
Best regards, Julian

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--f46d043c824656641e04f8f6fc36-- From nobody Fri May 9 05:54:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EDA1A02A2 for ; Fri, 9 May 2014 05:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ojun_U9RVpPv for ; Fri, 9 May 2014 05:54:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF61A02A0 for ; Fri, 9 May 2014 05:54:48 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQzIE-1WFZxh195S-00UKxr; Fri, 09 May 2014 14:54:31 +0200 Message-ID: <536CD003.7050909@gmx.de> Date: Fri, 09 May 2014 14:54:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mike amundsen References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mkkRJHzdM5jCCitFfAuyDRpWCEysObU/GSUzVSLv+0zM1r21oSV 2bKph+KpcR2ri/UtVSYfWYLbZfB0VhKN5AIgGTjYeZlFPSHmXeUHz/7kr2VoWo+KRRcX8rE qb8Hh7cdJKxxABCmWpm0r+RE6lCnkk/LoIict0Xu64Sdr7kFkHt0HK2Y2xZjIC6/Uwwn+kT 14fgd7R6kpSIGqgttNBeg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rhz_baSwyrO-4ZqPLDBCg0re3qk Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:54:50 -0000 On 2014-05-09 14:46, mike amundsen wrote: > Think of an OPTIONS response when the client wants to know: > 1) what media types are accepted for requests > AND > 2) what media types are returned for responses > > i think you need a new header. > ... I don't see why we need 2). Can you elaborate? Best regards, Julian From nobody Fri May 9 06:19:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D421A02B6 for ; Fri, 9 May 2014 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 2Q7WIH3TK8SL for ; Fri, 9 May 2014 06:19:33 -0700 (PDT) Received: from nm2-vm1.bullet.mail.gq1.yahoo.com (nm2-vm1.bullet.mail.gq1.yahoo.com [98.136.218.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3EA1A029D for ; Fri, 9 May 2014 06:19:33 -0700 (PDT) Received: from [98.137.12.62] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2014 13:19:28 -0000 Received: from [98.137.12.197] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 09 May 2014 13:19:28 -0000 Received: from [127.0.0.1] by omp1005.mail.gq1.yahoo.com with NNFMP; 09 May 2014 13:19:28 -0000 X-Yahoo-Newman-Id: 550750.59254.bm@omp1005.mail.gq1.yahoo.com Received: (qmail 28953 invoked from network); 9 May 2014 13:19:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399641568; bh=CoN1sKiDEtrsFPfGN5ufhycKcJyDP+fZIH3ugJRwQ34=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=HXxXci1p9T8NftN/gSHx14ErVQutwYtJAmsG5vE8YU1Lbl8Vkqj1GoTzOLSODq2y7ciKc6cYsEMBegQU+kplIHzFBPaYtB40oV7Tgd5joRF8LAxGNiRHa81NncU+Q1mVZ1nJuZQ77OUr/Zq+DQHywHsqVrjdnrBEJhyLlhgtlKc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KhbEIpcVM1mD31RaTB_efUcawJgWkusYegJvy7Gl5yF0ZXq lVKFgaZ6g4Zay9kFtg8eQkGYTKsBWglI4NK9c0Kd9Y6SD6aiIfV6ssv.2py. v5PDeigrJqcAl.5G4acfIl3gNV1.DFSdZPjWjhKnHuAXRNAppYruygdV3my. ZsiymDEn2cOamM3pbrV_C2xLPpcweVP2l7aWwKIJ9ldE3Y1U2WGQJ9UaeiAc H0XPnQLShJDD8nnf9IqM1lnRA9b9YV2TdHfuzIxDH2Fos8oIyj3yW7Rocwk2 ng9mST7akDnSzaiDgqZQEyrnw2lJ.jz_VYDY1WNZo1tEqIwh_1FwuccJCvzD DRzMMa.mYhk8_C7b7C8JEOZ2KT9k9DrTyttbeG._DcIr5SXvbFJngMLqJGy8 O0G5nUiVerx6IwUrSNk7a_QJwd6xW_EIKNc0Ugkv5Q4G7Pphohnezre8PSO_ 6sk3zHKLh..27ejgTOXgEIhH6iTVeoQfglSMShP.aEO4PiQtoPqFZgqyInBz vBQP35I4Bj49rZYFHmzS4sTEWgZClRp0j1KiTYnhQm91bqIZVvzey86cJgdN FuU7IBgaDtyEB1fCk1x0giutIMT7qmlS7ynY7BLYzCUX9_JupPepoYQnCOZl aCZy8Id4WOBc1bbCBPOioyEzFrpBw4KUpgnlBqDBFXZOgYe2YfUZSD8RppGY v0C2GUyZex3Ojru17T5ySmtBLRG8OuwqYiRTN4XbJiCkOX4jkS5VelGGeHYD S2pMCC42H4V6_Vy.Ajqi69o8- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- X-Rocket-Received: from mail-wi0-f176.google.com (mamund@209.85.212.176 with plain [98.138.105.22]) by smtp201.mail.gq1.yahoo.com with SMTP; 09 May 2014 13:19:28 +0000 UTC Received: by mail-wi0-f176.google.com with SMTP id n15so1313259wiw.3 for ; Fri, 09 May 2014 06:19:26 -0700 (PDT) X-Gm-Message-State: ALoCoQkU2CFUU52gTevWzWCDr95bOKrBDEV3rIBibHxVUGR9J2RRSK2PzP6k2A7Ow3LFYrGn7/Mj X-Received: by 10.180.126.33 with SMTP id mv1mr3410318wib.6.1399641566408; Fri, 09 May 2014 06:19:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.79.169 with HTTP; Fri, 9 May 2014 06:19:06 -0700 (PDT) In-Reply-To: <536CD003.7050909@gmx.de> References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> <536CD003.7050909@gmx.de> From: mike amundsen Date: Fri, 9 May 2014 09:19:06 -0400 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8f839d71610d3004f8f772f7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/g57Elf-qVCICV1kARnraOEVyXLA Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:19:34 -0000 --e89a8f839d71610d3004f8f772f7 Content-Type: text/plain; charset=UTF-8 **** REQUEST **** OPTIONS /users HTTP/1.1 **** RESPONSE **** 200 OK HTTP/1.1 Allow: GET, HEAD, POST Accept: text/html, application/atom+xml, application/collection+json Accepts: application/www-form-url-encoded Content-Type: text/plain Methods Allowed: GET, HEAD, POST Response Types Available: text/html, applicaiton/atom+xml, application/collection+json Request Types Accepted: application/www-form-url-encoded mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Fri, May 9, 2014 at 8:54 AM, Julian Reschke wrote: > On 2014-05-09 14:46, mike amundsen wrote: > >> Think of an OPTIONS response when the client wants to know: >> 1) what media types are accepted for requests >> AND >> 2) what media types are returned for responses >> >> i think you need a new header. >> ... >> > > I don't see why we need 2). Can you elaborate? > > Best regards, Julian > --e89a8f839d71610d3004f8f772f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
**** REQUEST ****
OPTIONS /users HTTP/1.1

**** RESPONSE ****
200 OK HTTP/1.1
Allow: GET, HEAD, POST
Accept: text/html, application/ato= m+xml, application/collection+json
Accepts: application/www-form-url-encoded
Content-Type: text= /plain

Methods Allowed: GET, HEAD, POST
= Response Types Available: text/html, applicaiton/atom+xml, application/coll= ection+json
Request Types Accepted: application/www-form-url-encoded



On Fri, May 9, 2014 at 8:54 AM, Julian R= eschke <julian.reschke@gmx.de> wrote:
On 2014-05-09 14:46, mike amundsen wrote:
Think of an OPTIONS response when the client wants to know:
1) what media types are accepted for requests
AND
2) what media types are returned for responses

i think you need a new header.
...

I don't see why we need 2). Can you elaborate?

Best regards, Julian

--e89a8f839d71610d3004f8f772f7-- From nobody Fri May 9 06:32:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834FC1A02A6 for ; Fri, 9 May 2014 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 2XH_oUKGW-_6 for ; Fri, 9 May 2014 06:31:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAD1A00A2 for ; Fri, 9 May 2014 06:31:53 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUZKF-1WJ9QX1I0Z-00RG9u; Fri, 09 May 2014 15:31:38 +0200 Message-ID: <536CD8B6.9070003@gmx.de> Date: Fri, 09 May 2014 15:31:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mike amundsen References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> <536CD003.7050909@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6k839LfsAmjNR//kWeHQmI7IDpCWeQictXmxXZzcbGTRd52ZyOO b+LT8I/tI2wDjPgouCFoWxZoaCzRVT8zwiLl/yo/4zUp5Pj3FNp+IK+K5fdxXzEkqPtYWkI z/Z0c4aBlELmNwIMT5XxFe6z2cdL1DhQk5Qgb6tb/xw1WsSpBIAurwlKFS7DFYOF7/VYfSN DS4TKFCVbcs+7+UKM9xIw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bW-dF0SuhEEH1l_s6zx7Zc2Gpyw Cc: John Arwe , Steve K Speicher , "apps-discuss@ietf.org application-layer protocols" , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:31:58 -0000 On 2014-05-09 15:19, mike amundsen wrote: > **** REQUEST **** > OPTIONS /users HTTP/1.1 > > > **** RESPONSE **** > 200 OK HTTP/1.1 > Allow: GET, HEAD, POST > Accept: text/html, application/atom+xml, application/collection+json > Accepts: application/www-form-url-encoded > Content-Type: text/plain > > Methods Allowed: GET, HEAD, POST > Response Types Available: text/html, applicaiton/atom+xml, > application/collection+json > Request Types Accepted: application/www-form-url-encoded > .... What's the actual use case for querying the set of available response types? Best regards, Julian From nobody Fri May 9 08:57:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000311A02C7 for ; Fri, 9 May 2014 08:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 vMWAZhEJd6no for ; Fri, 9 May 2014 08:57:39 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DC2CB1A0059 for ; Fri, 9 May 2014 08:57:38 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so4078238wev.5 for ; Fri, 09 May 2014 08:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=vDafA982uol7peFooHVymBjtr+jIzBQXRgTem4ahQQw=; b=et3XHMJXEU+loJIUWD4y89Jc5xOaWhsL0B9nS0xgCnjewyPcnMJ6zAx5IEEGVw3FDo GBVzyByqN48ucw7jShFgeNE+49pq2iqho5eMR+EEJSfnfAO5rOYKAW5Eg+qKa7a45y7n 1DiBgryiHPnYSTUADZSOgzR4bj6uLekzZyYbM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type; bh=vDafA982uol7peFooHVymBjtr+jIzBQXRgTem4ahQQw=; b=chFH78N9PXnLi5yT08iJUU7eUEsxLdgici4XyGXih6eXsFFaFzLOJDyBV4d/Q1K1bE vxWeyhT6l08VwbcxQIWyJzQnhmHqYvDm2hOuSEA1kqmXbble3QkozKH563AJPxurYBFf F8KGwoJpMJd6XjhuDNH052UMyRty6wpPKI5xLaYerh0fFnMSOvsN8hASUBquxCyFfPqQ +hw1jaseD5Ya5eDtDKaIZsrJREPoA3A1pAEruuGw2FayNu8geqWL6hF/NaLXBFgPQa+u Y9HALHbvSr8C0U0WcUB1hqn5fojm6tBPbgXPgDrI2++S53n5nA0/H6Bq2Wjyni9KP75L xgZQ== X-Gm-Message-State: ALoCoQl2OmHnfs+xHoAvNVsdIpi0xmFhKd0pysMt0A2si/tCf3oLhpOtdlxRjEAjQSv3Ruo0b1a6 MIME-Version: 1.0 X-Received: by 10.180.189.69 with SMTP id gg5mr4031768wic.52.1399651053321; Fri, 09 May 2014 08:57:33 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.16.9 with HTTP; Fri, 9 May 2014 08:57:33 -0700 (PDT) Date: Fri, 9 May 2014 08:57:33 -0700 X-Google-Sender-Auth: qHtJpNw1Cr3_5wY82UZCg8IKc0M Message-ID: From: Kurt Andersen To: Salvatore Loreto Content-Type: multipart/alternative; boundary=001a11c329fad7e02604f8f9a7ae Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xrY_i7ZmKxYQXgDoYHAFULI3e4A Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:57:41 -0000 --001a11c329fad7e02604f8f9a7ae Content-Type: text/plain; charset=UTF-8 On Thu, May 8, 2014 at 11:09 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > This is a formal call for adoption of draft-kucherawy-email-auth-codes > into APPSAWG. > > Yes - and I'm willing to participate as a reviewer. --Kurt Andersen --001a11c329fad7e02604f8f9a7ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 8, 2014 at 11:09 PM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

This is a formal call for adoption of draft-kucherawy-email-auth-codes into= APPSAWG.=C2=A0=C2=A0

=C2=A0
Yes - and I'm will= ing to participate as a reviewer.

--Kurt Andersen

--001a11c329fad7e02604f8f9a7ae-- From nobody Fri May 9 09:48:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2A1A02F7 for ; Fri, 9 May 2014 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 1VmQv1PDEvJD for ; Fri, 9 May 2014 09:48:42 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (mail-by1on0156.outbound.o365filtering.com [207.46.101.156]) by ietfa.amsl.com (Postfix) with ESMTP id 426BB1A02C3 for ; Fri, 9 May 2014 09:48:42 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.949.7; Fri, 9 May 2014 16:48:36 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.126]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.126]) with mapi id 15.00.0949.001; Fri, 9 May 2014 16:48:36 +0000 From: Terry Zink To: Arnt Gulbrandsen , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures Thread-Index: AQHPakDx1B42O46UhUW4NcwAt8qDPZs1skqAgABQBgCAABfyAIABCh+AgAAfa+CAAFonAIAAWnwdgAAGS4CAAHk0MA== Date: Fri, 9 May 2014 16:48:33 +0000 Message-ID: References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> In-Reply-To: <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-exchange-antispam-report-test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(377454003)(189002)(199002)(56776002)(99396002)(101416001)(54316003)(4396001)(59766002)(97336001)(56816006)(51856002)(87936001)(65816002)(49866002)(47976003)(47736002)(63696004)(2656002)(33646001)(76482001)(77982001)(87266001)(95666003)(97186001)(90146001)(79102001)(21056001)(85306002)(50986002)(53806002)(54356002)(47446003)(77096001)(64706001)(20776003)(92566001)(81542001)(93136001)(74876001)(76786001)(76796001)(83072002)(85852003)(93516002)(74662001)(94316002)(19580405001)(95416001)(94946001)(74366001)(81816001)(80022001)(74706001)(93886001)(81686001)(46102001)(74502001)(69226001)(15975445006)(19580395003)(31966008)(98676001)(81342001)(83322001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eIuh3qZ_uXyy_fqU9VDMng-7tiY Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 16:48:44 -0000 > Why does SPF+DKIM warrant more protocol treatment? For clarity to the end user. If a message is rejected because neither Condi= tion 1 nor Condition 2 is met, then it is more accurate to say to the end u= ser that neither condition was met. Saying only Condition 1 wasn't met misl= eads the sender into thinking that either Condition 2 was met, or that it i= sn't a requirement. This is incorrect and a bounce should reflect that. -- Terry -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Arnt= Gulbrandsen Sent: Friday, May 9, 2014 2:33 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for = authentication failures There's always been cases where several status codes were possible, e.g. 5.2.x+5.4.y. AFAICT servers generally report whichever issue they notice=20 first, which is perhaps not perfect but has been good enough for a long=20 time. Why does SPF+DKIM warrant more protocol treatment? Arnt _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri May 9 10:12:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38851A008F for ; Fri, 9 May 2014 10:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 lp4RtfJKuPGY for ; Fri, 9 May 2014 10:11:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4C921A0066 for ; Fri, 9 May 2014 10:11:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s49HBmIM021067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 9 May 2014 10:11:52 -0700 Message-ID: <536D0C4E.5060409@dcrocker.net> Date: Fri, 09 May 2014 10:11:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 09 May 2014 10:11:52 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EimtZuCDsZ0rhKJ2Ze_I3Vpbka8 Subject: Re: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 17:11:58 -0000 On 5/9/2014 8:57 AM, Kurt Andersen wrote: > On Thu, May 8, 2014 at 11:09 PM, Salvatore Loreto > > > wrote: > > > This is a formal call for adoption of > draft-kucherawy-email-auth-codes into APPSAWG. > > > Yes - and I'm willing to participate as a reviewer. ditto ditto. d./ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 9 16:01:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEE61A0049 for ; Fri, 9 May 2014 16:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 NsbDISNh47pt for ; Fri, 9 May 2014 16:01:45 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id E95CB1A0023 for ; Fri, 9 May 2014 16:01:44 -0700 (PDT) Received: from airbears-136-152-36-31.airbears.berkeley.edu ([136.152.36.31] helo=dretair11.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WitnO-0001yj-7x; Fri, 09 May 2014 16:01:39 -0700 Message-ID: <536D5EFC.9090604@berkeley.edu> Date: Fri, 09 May 2014 16:04:28 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: James M Snell , Julian Reschke , IETF Apps Discuss References: <53697AD6.2030504@berkeley.edu> <536CC4D2.4000709@gmx.de> <536CCC87.5090706@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/juF5_E-g7PYw_jOFFfUwEyHY14Y Cc: John Arwe , Steve K Speicher , Arnaud Le Hors Subject: Re: [apps-discuss] Accept-Post HTTP header field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:01:48 -0000 hello. On 2014-05-09, 5:46, James M Snell wrote: > -1.. In most cases where I've used this kind of mechanism, it is > important to distinguish what you'd accept via post separately than what > you'd accept via patch or put. There is also no requirement for q-value > ordering. Reusing Accept would mean requiring special case handling > that's just not worth the effort when the separate headers approach gets > us easily where we want to go. +1 on the -1 ;-) reusing Accept wouldn't work. when publishing earlier versions of the draft, i did get feedback about a more general Accept-* header (instead of having separate Accept-Patch and Accept-Post and maybe others). this is certainly possible, but the syntax would get more complicated because, as james points out, typically various methods accept different sets of media types. plus we already have Accept-Patch out there. Accept-Post is the result of a real need (W3C's LDP work), and it does solve the problem that LDP has. other solutions certainly would have been possible as well. mostly, we tried to align our solution with what exists (Accept-Patch), and without solving broader problems then the ones that we were facing. just out of curiosity, since we're talking about the possibility of generalizing the Accept-* approach: does anybody have any interest in having Accept-Put or a general-purpose Accept-* so that PUT would be covered as well? thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Sat May 10 16:22:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11FB1A02A6 for ; Sat, 10 May 2014 16:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IJiupmVzVG_4 for ; Sat, 10 May 2014 16:22:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 309841A0249 for ; Sat, 10 May 2014 16:22:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7NGXD70KG000QOY@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 10 May 2014 16:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399763829; bh=ChPFfHs0tYJZyaLsq0JlRdnli2t3LSzBAAgvbvkMA3Q=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=LlPUKTZF6r74aZG7nun2PMYI1Y6z/5bK6tqNqqlaldlO5JPy0Aozso0pzxepwEBEs AclSdvU3sG24nstKDBJ0ozLRyz5TgRQFeJcUTnuzUXWmg3scPJdKq5C+VCsSzDz5zV fysTvvHZ7lpXz1CYh3i0FlMd3z61Bgt2SRZ0SaNc= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTJWRLO0000052@mauve.mrochek.com>; Sat, 10 May 2014 16:17:08 -0700 (PDT) Message-id: <01P7NGXBV5XU000052@mauve.mrochek.com> Date: Sat, 10 May 2014 16:10:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 09 May 2014 05:02:18 +0000" <20140509050218.5710.qmail@joyce.lan> References: <20140509050218.5710.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zzaF-TNKFmNpJXoBrK5xWVwQUXc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 23:22:21 -0000 > >This seems slippery slope-ish to me. When DKIM comes out, do we also need > >to register a set for each of the possible {SPF, DKIM, DMARC} combinations? > I'm not at all sure this is a rathole we want to go down, but if we do > it seems to me it would be more useful to describe the failures at a > policy rather than mechanism level, e.g. "not enough authentication > for channel" or "not enough authentication for sender policy." The > details can be in the text, but the point of carving it up this way is > that the former tells the MTA that it might be worthwhile to send it a > different way, while the latter says there's something wrong with the > message (from the receiver's point of view.) Bingo. This is what I was referring to when I said that I was unsure whether we want to record a DKIM or DMARC failure. Unless we're now attaching DKIM signature failures exclusively to DMARC - and I don't think we are - telling me that the message was rejected due to a DKIM failure doesn't tell an MLM anything useful. What if it was some other DKIM signature on the message? What if the list itself attached a signature and a problem at the receving end caused the signature to fail to verify? Contrast this with saying "Rejected because of DMARC policy". This tells a MLM something useful: It says that domain shown in the From: field of that message has a policy that is incompatible with the list. In this situation a list could, given sufficient failures of this sort, revoke that sender's right to post. Or all senders in that domain. Instead of revoking the recipient's right to receive list mail. The more I think about it the more convinced I am that DMARC-specific codes (or if you prefer, a "policy attached to the domain in the from field" code) is the right way to go here. Ned From nobody Sat May 10 16:37:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C71A02A6 for ; Sat, 10 May 2014 16:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0RhNfSKgsXyJ for ; Sat, 10 May 2014 16:36:58 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7FF1A0249 for ; Sat, 10 May 2014 16:36:58 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 99D0DD04544; Sat, 10 May 2014 19:36:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1399765010; bh=Oe9C77ZEMwWppPs7Uqx4aggqQoA8PSNCJx1zWC+KLCM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OqTflUdLb7bLKrUs+FoRBHS0Iuo8LpavWdaEpKH5b0BzeUXEloBaKwMIwGLbJXYwE cZu/aYSQ7rCK2WQaSl3R4uBquZ3+0ZkgWiOOvAm7wDgTioskutSAag+qniaTbwhbDE F0JIcd7McwOWN3+T+0/DWM+Q1RXTB3C8quIRxCTg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 61942D040C9; Sat, 10 May 2014 19:36:50 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Sat, 10 May 2014 19:36:49 -0400 Message-ID: <2095574.vcXelAC4ch@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <01P7NGXBV5XU000052@mauve.mrochek.com> References: <20140509050218.5710.qmail@joyce.lan> <01P7NGXBV5XU000052@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G9lDFnvRkWq6pe1j-XDTayA_x8I Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 23:37:00 -0000 On Saturday, May 10, 2014 16:10:42 Ned Freed wrote: > > >This seems slippery slope-ish to me. When DKIM comes out, do we also > > >need > > >to register a set for each of the possible {SPF, DKIM, DMARC} > > >combinations? > > > > I'm not at all sure this is a rathole we want to go down, but if we do > > it seems to me it would be more useful to describe the failures at a > > policy rather than mechanism level, e.g. "not enough authentication > > for channel" or "not enough authentication for sender policy." The > > details can be in the text, but the point of carving it up this way is > > that the former tells the MTA that it might be worthwhile to send it a > > different way, while the latter says there's something wrong with the > > message (from the receiver's point of view.) > > Bingo. This is what I was referring to when I said that I was unsure whether > we want to record a DKIM or DMARC failure. > > Unless we're now attaching DKIM signature failures exclusively to DMARC - > and I don't think we are - telling me that the message was rejected due to > a DKIM failure doesn't tell an MLM anything useful. What if it was some > other DKIM signature on the message? What if the list itself attached a > signature and a problem at the receving end caused the signature to fail to > verify? > > Contrast this with saying "Rejected because of DMARC policy". This tells a > MLM something useful: It says that domain shown in the From: field of that > message has a policy that is incompatible with the list. In this situation > a list could, given sufficient failures of this sort, revoke that sender's > right to post. Or all senders in that domain. Instead of revoking the > recipient's right to receive list mail. > > The more I think about it the more convinced I am that DMARC-specific codes > (or if you prefer, a "policy attached to the domain in the from field" code) > is the right way to go here. Do you think there should be SPF specific codes too since, unlike DKIM, it has it's only policy function (and currently recommends what codes one should use)? Scott K From nobody Sat May 10 17:27:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909491A02B6 for ; Sat, 10 May 2014 17:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tAAyCE4WXN6a for ; Sat, 10 May 2014 17:27:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 604251A02B5 for ; Sat, 10 May 2014 17:27:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7NJCU1RCW001QMB@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 10 May 2014 17:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399768013; bh=vnfCYpbCi9r6WsyRZa+iPUJo4fVTqBhKuwx1F5gFrQ8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=FWEjVN7CbEdZjc9bCjXlck5OQYUFwvrajYaX2qnutn4YpzDIImjgZWCRFfCgTISMO Yf0+iAADTtcoW0XbKtasQpDEfAAlgEgRtHk0hFjd9p5AhC0YtsjLRRj6reUiGjBY/P KE/3fgTgPnqiSU9spK1hNmt4+9N2sjCegiTUuig8= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTJWRLO0000052@mauve.mrochek.com>; Sat, 10 May 2014 17:26:52 -0700 (PDT) Message-id: <01P7NJCSFBA8000052@mauve.mrochek.com> Date: Sat, 10 May 2014 17:22:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 10 May 2014 19:36:49 -0400" <2095574.vcXelAC4ch@scott-latitude-e6320> References: <20140509050218.5710.qmail@joyce.lan> <01P7NGXBV5XU000052@mauve.mrochek.com> <2095574.vcXelAC4ch@scott-latitude-e6320> To: Scott Kitterman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/l7j3egFnTXmTSpcwauZAqsH0Kdo Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 00:27:37 -0000 > On Saturday, May 10, 2014 16:10:42 Ned Freed wrote: > > > >This seems slippery slope-ish to me. When DKIM comes out, do we also > > > >need > > > >to register a set for each of the possible {SPF, DKIM, DMARC} > > > >combinations? > > > > > > I'm not at all sure this is a rathole we want to go down, but if we do > > > it seems to me it would be more useful to describe the failures at a > > > policy rather than mechanism level, e.g. "not enough authentication > > > for channel" or "not enough authentication for sender policy." The > > > details can be in the text, but the point of carving it up this way is > > > that the former tells the MTA that it might be worthwhile to send it a > > > different way, while the latter says there's something wrong with the > > > message (from the receiver's point of view.) > > > > Bingo. This is what I was referring to when I said that I was unsure whether > > we want to record a DKIM or DMARC failure. > > > > Unless we're now attaching DKIM signature failures exclusively to DMARC - > > and I don't think we are - telling me that the message was rejected due to > > a DKIM failure doesn't tell an MLM anything useful. What if it was some > > other DKIM signature on the message? What if the list itself attached a > > signature and a problem at the receving end caused the signature to fail to > > verify? > > > > Contrast this with saying "Rejected because of DMARC policy". This tells a > > MLM something useful: It says that domain shown in the From: field of that > > message has a policy that is incompatible with the list. In this situation > > a list could, given sufficient failures of this sort, revoke that sender's > > right to post. Or all senders in that domain. Instead of revoking the > > recipient's right to receive list mail. > > > > The more I think about it the more convinced I am that DMARC-specific codes > > (or if you prefer, a "policy attached to the domain in the from field" code) > > is the right way to go here. > Do you think there should be SPF specific codes too since, unlike DKIM, it has > it's only policy function (and currently recommends what codes one should > use)? Sorry, I meant to address that and forgot to. The answer is yes, since SPF implements a different policy it deserves its own policy codes. That said, this isn't as urgent since DMARC is the a case where automatic actions are facilitated by using the codes. I don't see a comparable case for SPF. But of course on something like this I could easily be missing something. We all to some extent see this stuff through the prism of our own implementations and experiences. Ned From nobody Sat May 10 18:03:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FAB1A0134 for ; Sat, 10 May 2014 18:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 29dEF21ZArre for ; Sat, 10 May 2014 18:03:09 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B81A0126 for ; Sat, 10 May 2014 18:03:08 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x13so5329599wgg.34 for ; Sat, 10 May 2014 18:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T1xLKYbBLyNebCpEXiUqILUxWGr/1HRa1Qr3OZXe97Q=; b=qhiJpJRjtUmCQJcdkCfqInxEBhL1xjUaBL7osyHNEiNpAixmd0nR+CDq4To+iKUsEO IvvfRdnzSQbHz7gUfbkJsUetUjkbAOINoZ9jXol/LhxTSPvLXk3jhiV0lsliEQ7Pfi63 +BcJHAzDmfERnjDDWnsxi9YF/Fiz8MrFTQ0pKSHGXhE7gTJ84rxfAcIPRzyTZfkGCZGE bqswk7uXu/i6fFC18pPog561bsiLzm6DneVe8dcj3eraxCKsHTn1r0LTFnVqH4C0ulvX rr9PYJfi10y4uO3KfvEZ98NMkn6dYfmxbfHMw99kq1ymrxT+om2mzJzOmmeQrdEZDfrB pjgA== MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr9320567wiw.5.1399770182635; Sat, 10 May 2014 18:03:02 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Sat, 10 May 2014 18:03:02 -0700 (PDT) In-Reply-To: <01P7NJCSFBA8000052@mauve.mrochek.com> References: <20140509050218.5710.qmail@joyce.lan> <01P7NGXBV5XU000052@mauve.mrochek.com> <2095574.vcXelAC4ch@scott-latitude-e6320> <01P7NJCSFBA8000052@mauve.mrochek.com> Date: Sat, 10 May 2014 18:03:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d043c824680d87304f9156468 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fJZRtt7ZJ6ZHOl81pDxYLFT9Dj0 Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 01:03:10 -0000 --f46d043c824680d87304f9156468 Content-Type: text/plain; charset=UTF-8 On Sat, May 10, 2014 at 5:22 PM, Ned Freed wrote: > > > The more I think about it the more convinced I am that DMARC-specific > codes > > > (or if you prefer, a "policy attached to the domain in the from field" > code) > > > is the right way to go here. > > > Do you think there should be SPF specific codes too since, unlike DKIM, > it has > > it's only policy function (and currently recommends what codes one should > > use)? > > Sorry, I meant to address that and forgot to. The answer is yes, since SPF > implements a different policy it deserves its own policy codes. > > That said, this isn't as urgent since DMARC is the a case where automatic > actions are facilitated by using the codes. I don't see a comparable case > for > SPF. > > But of course on something like this I could easily be missing something. > We > all to some extent see this stuff through the prism of our own > implementations > and experiences. > I think this document should register distinct codes for DKIM and SPF, for operators that don't do DMARC but might reject for either of those. Registering a DMARC code is also certainly a good idea, but wouldn't it be better to handle that as part of the DMARC document itself? Otherwise, to what normative thing would a DMARC code registration refer? -MSK --f46d043c824680d87304f9156468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 10, 2014 at 5:22 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
>= > The more I think about it the more convinced I am that DMARC-specific= codes
> > (or if you prefer, a "policy attached to the domain in the f= rom field" code)
> > is the right way to go here.

> Do you think there should be SPF specific codes too since, unlike DKIM= , it has
> it's only policy function (and currently recommends what codes one= should
> use)?

Sorry, I meant to address that and forgot to. The answer is yes= , since SPF
implements a different policy it deserves its own policy codes.

That said, this isn't as urgent since DMARC is the a case where automat= ic
actions are facilitated by using the codes. I don't see a comparable ca= se for
SPF.

But of course on something like this I could easily be missing something. W= e
all to some extent see this stuff through the prism of our own implementati= ons
and experiences.

I think this= document should register distinct codes for DKIM and SPF, for operators th= at don't do DMARC but might reject for either of those.

Registering a DMARC code is also certainly a good idea, but wouldn'= ;t it be better to handle that as part of the DMARC document itself?=C2=A0 = Otherwise, to what normative thing would a DMARC code registration refer?
-MSK
--f46d043c824680d87304f9156468-- From nobody Sat May 10 18:20:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7EC1A02B6 for ; Sat, 10 May 2014 18:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IKBmn1l-OVH6 for ; Sat, 10 May 2014 18:20:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4391A0126 for ; Sat, 10 May 2014 18:20:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7NL1B8RCG0023TD@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 10 May 2014 18:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399770892; bh=RAj6CCtMBpUHgD92mW18CPNahUVVkZjxZBuXiKosu/w=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=XvIiLrTX8cx8JIeFVOYxsXFHGKkwqSpC8F3jyhI9CudCVSJdmaej9FHaY/1UYENYw VhyXDvOgHMfEsTnn4rwiXNXRGQvNTAtQJ+9Ib8DvreSP1m/0fHsRUXxg5su3838+HH tu1DVaz8EsfBaZn878vrBDlachUuORwC4kNPkWIk= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTJWRLO0000052@mauve.mrochek.com>; Sat, 10 May 2014 18:14:50 -0700 (PDT) Message-id: <01P7NL19J2HU000052@mauve.mrochek.com> Date: Sat, 10 May 2014 18:13:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 10 May 2014 18:03:02 -0700" References: <20140509050218.5710.qmail@joyce.lan> <01P7NGXBV5XU000052@mauve.mrochek.com> <2095574.vcXelAC4ch@scott-latitude-e6320> <01P7NJCSFBA8000052@mauve.mrochek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9hMSpI2zO-tgZOqiZseMVbJSVgw Cc: Scott Kitterman , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 01:20:06 -0000 > On Sat, May 10, 2014 at 5:22 PM, Ned Freed wrote: > > > > The more I think about it the more convinced I am that DMARC-specific > > codes > > > > (or if you prefer, a "policy attached to the domain in the from field" > > code) > > > > is the right way to go here. > > > > > Do you think there should be SPF specific codes too since, unlike DKIM, > > it has > > > it's only policy function (and currently recommends what codes one should > > > use)? > > > > Sorry, I meant to address that and forgot to. The answer is yes, since SPF > > implements a different policy it deserves its own policy codes. > > > > That said, this isn't as urgent since DMARC is the a case where automatic > > actions are facilitated by using the codes. I don't see a comparable case > > for > > SPF. > > > > But of course on something like this I could easily be missing something. > > We > > all to some extent see this stuff through the prism of our own > > implementations > > and experiences. > > > I think this document should register distinct codes for DKIM and SPF, for > operators that don't do DMARC but might reject for either of those. And as always use the most specific code available... that works for me. > Registering a DMARC code is also certainly a good idea, but wouldn't it be > better to handle that as part of the DMARC document itself? Otherwise, to > what normative thing would a DMARC code registration refer? Quite right. If that's possible it's definitely the way to go. Ned From nobody Sat May 10 21:34:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0D1A02C1 for ; Sat, 10 May 2014 21:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 hEWVSuyqmoCe for ; Sat, 10 May 2014 21:34:52 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A92531A02BF for ; Sat, 10 May 2014 21:34:52 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so7290406vcb.10 for ; Sat, 10 May 2014 21:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DAPfWJ1BA46+w1AjTFow4ddOBKYKDldy/zSbOO7bSFw=; b=CRXnMHPFInimNjDTMXLxp5sjHCqUzkTOClQylQtPzTLrUXcRocTYUz2z0EtCS2bODD qaUI6/AZVqzW8Q3jI2rFsAY8PbeqYE/JbzNYPE5U/Civhf6/W+5XEKSQ65lTZTWepWlG 1TZ52MFBx935oTrO+3vJ7/yWnPdhjxxajIBOvd1n3OXovG2eswOd+OeQI8QD0wZRftbI QJRFXzAuSFsD9jxW8cylEd4YUIps6e+5CERQr0F27uCktepVSH309Oczwq93WPIz5AqA GLeNYkIq0U5FtN/9aQ4q2U2fX2NmkW9p/a0oPWIhFlqoZeHREoTPvygoWPm3OrWAdC4L /qaw== MIME-Version: 1.0 X-Received: by 10.58.185.145 with SMTP id fc17mr16832561vec.14.1399782886912; Sat, 10 May 2014 21:34:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Sat, 10 May 2014 21:34:46 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 May 2014 00:34:46 -0400 X-Google-Sender-Auth: zk4mtHqCeHGmDSkVpQ7BtM2q214 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CiSFfEP44SmQqVM_AzevEusLRWk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 04:34:54 -0000 On Wed, May 7, 2014 at 5:32 PM, Murray S. Kucherawy wrote: > A while ago I did this short draft: > > https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/ > > ...and then promptly forgot about it. Given that email authentication is > front-and-center these days, is it worth updating it and then pushing it > through? Given its size, does anyone have thoughts about processing it > through APPSAWG? Murray asked me about this separately, after posting it here. As I was a bit behind on following this list, I didn't know he'd started a discussion here until I'm catching up now. Apart from a few editorial things, here's what I said to Murray. Some, but not all of this has been discussed here already, so add this as strong support for addressing it: On a broader level, keep in mind that 6376 says this (Section 6.3): In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems. and this (Section 6.3): If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. The two DKIM codes seem to encourage, or at least support, violation of both of these. Further, what code do I return if I check both SPF and DKIM, and both checks fail? Does it really make sense to have these as three different extended codes? Or might it makes sense to have one code that says "sender verification failed," with a description that says that no sender verification mechanism succeeded, and policy requires successful verification? It might then go on to explain that the requirement could come from local policy or from some communication of sender policy to the receiving domain. This point's a complicated one, and I'm happy if you don't address it now, and we address it on the mailing list. Barry, Applications AD From nobody Sat May 10 23:16:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404DE1A018E for ; Sat, 10 May 2014 23:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aC7wAjIz-__y for ; Sat, 10 May 2014 23:16:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4731A017D for ; Sat, 10 May 2014 23:16:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7NVE0V700001XHZ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 10 May 2014 23:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1399788687; bh=pHCIwueUM4mv6NxDE9GXJObaUkS9kylCnVtuJtUcKV0=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=SJf85mImVA98JU8MTwMdtZu1dwpsw1LVgsO3ZxLSc5JSUXvoAioAxX2g/uBBNPGxd VyNSasO0d/gA+STW/w+//WmOwC6c1F5EwsNIE3iRrXBsUd9Xjgyije2/VbAhgmjS7F mH/VtGKqnkfX05vn2fcdWVCkoUaXkNs0ulSWJtbk= MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7JTJWRLO0000052@mauve.mrochek.com>; Sat, 10 May 2014 23:11:25 -0700 (PDT) Message-id: <01P7NVDZK9CE000052@mauve.mrochek.com> Date: Sat, 10 May 2014 23:08:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 11 May 2014 00:34:46 -0400" References: To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/r89ZAbv3_w16t8F856PspS1fowY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 06:16:39 -0000 > On Wed, May 7, 2014 at 5:32 PM, Murray S. Kucherawy wrote: > > A while ago I did this short draft: > > > > https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/ > > > > ...and then promptly forgot about it. Given that email authentication is > > front-and-center these days, is it worth updating it and then pushing it > > through? Given its size, does anyone have thoughts about processing it > > through APPSAWG? > Murray asked me about this separately, after posting it here. As I > was a bit behind on following this list, I didn't know he'd started a > discussion here until I'm catching up now. > Apart from a few editorial things, here's what I said to Murray. > Some, but not all of this has been discussed here already, so add this > as strong support for addressing it: > On a broader level, keep in mind that 6376 says this (Section 6.3): > In general, modules that consume DKIM verification output SHOULD NOT > determine message acceptability based solely on a lack of any > signature or on an unverifiable signature; such rejection would cause > severe interoperability problems. > and this (Section 6.3): > If the email cannot be verified, then it SHOULD be treated the same > as all unverified email, regardless of whether or not it looks like > it was signed. > The two DKIM codes seem to encourage, or at least support, violation > of both of these. That's a fair point. > Further, what code do I return if I check both SPF and DKIM, and both > checks fail? Does it really make sense to have these as three > different extended codes? It's always been possible for there to be multiple failures happening at the same time. Which code gets returned in such cases is an implementation judgement call. (Or perhaps more likely, it's what gets checked first.) > Or might it makes sense to have one code > that says "sender verification failed," with a description that says > that no sender verification mechanism succeeded, and policy requires > successful verification? No, because "sender" means two different thing with DKIM and SPF, and a big part of the reason for having these code is to distinguish the From: header field verification failure case. > It might then go on to explain that the > requirement could come from local policy or from some communication of > sender policy to the receiving domain. Explanations can't be parsed by MLMs and used to take distinct action. (Well, actually they can, and regrettably it's sometimes necessary, but we shouldn't be encouraging it.) Ned From nobody Sat May 10 23:39:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6471A019D for ; Sat, 10 May 2014 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 kkyJFaQMOAgB for ; Sat, 10 May 2014 23:39:18 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id CE4051A019A for ; Sat, 10 May 2014 23:39:17 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so3057988wib.5 for ; Sat, 10 May 2014 23:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D+NbadukcjyZ5adM9ogrr6xu3lApDPnIy/186jFlZ28=; b=LgZDOBwXJ5YeD3gJLTpnneXsjGK5AAqXZlx2U38HYAFkKIkkJkE8Naki/C/m4XeaIC ijtOHOd53LguTDBDAmd49q7e3UrWIdFzIkdy0SVu3qp8Wh5XH8ixgcPyD6wxM5Z8XwEQ BauwrvzIRfJA08QF4E2H+pIo2gTePIJHcnLasl4/nskuG0qKLzMrJcAA/07gWgu1Hmc+ 6l4M0cyoe5vHlWHGGq/gf7PNKKyzyAaIY8Nr6Hzy4fGErp7/JEcZeCYqgMqLYhpWEjJs Du0lsQ6do7A52psP34t/+LY5+gEAPJdfzK1TGe5jDPJUQLzt10iARmb1bkJr5NCirkxY qTDw== MIME-Version: 1.0 X-Received: by 10.180.100.234 with SMTP id fb10mr10363014wib.26.1399790351881; Sat, 10 May 2014 23:39:11 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Sat, 10 May 2014 23:39:11 -0700 (PDT) In-Reply-To: <01P7NVDZK9CE000052@mauve.mrochek.com> References: <01P7NVDZK9CE000052@mauve.mrochek.com> Date: Sat, 10 May 2014 23:39:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d043748f3af1cde04f91a1643 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QXOL0tmOCztZ-X9xxhclzC5hmMY Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 06:39:20 -0000 --f46d043748f3af1cde04f91a1643 Content-Type: text/plain; charset=UTF-8 On Sat, May 10, 2014 at 11:08 PM, Ned Freed wrote: > > On a broader level, keep in mind that 6376 says this (Section 6.3): > > > In general, modules that consume DKIM verification output SHOULD NOT > > determine message acceptability based solely on a lack of any > > signature or on an unverifiable signature; such rejection would cause > > severe interoperability problems. > > > and this (Section 6.3): > > > If the email cannot be verified, then it SHOULD be treated the same > > as all unverified email, regardless of whether or not it looks like > > it was signed. > > > The two DKIM codes seem to encourage, or at least support, violation > > of both of these. > > That's a fair point. > Indeed. The example that stands out to me is a receiver that always expects mail from a particular author domain to have a valid signature, and suddenly it doesn't. This might be through ADSP, through some heuristic, or through some private arrangement with the author domain's ADMD. There might be something in the mix here about DMARC too, perhaps to indicate that DKIM failed and SPF was neutral, so report the failure. (Until there's a DMARC code, of course.) It shouldn't happen in typical DKIM operation, however, so I've got no problem reminding readers of this draft of the citations you made above. > Further, what code do I return if I check both SPF and DKIM, and both > > checks fail? Does it really make sense to have these as three > > different extended codes? > > It's always been possible for there to be multiple failures happening > at the same time. Which code gets returned in such cases is an > implementation > judgement call. (Or perhaps more likely, it's what gets checked first.) > +1. -MSK --f46d043748f3af1cde04f91a1643 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 10, 2014 at 11:08 PM, Ned Freed <ned.free= d@mrochek.com> wrote:
> On a broader level, kee= p in mind that 6376 says this (Section 6.3):

> =C2=A0 =C2=A0In general, modules that consume DKIM verification output= SHOULD NOT
> =C2=A0 =C2=A0determine message acceptability based solely on a lack of= any
> =C2=A0 =C2=A0signature or on an unverifiable signature; such rejection= would cause
> =C2=A0 =C2=A0severe interoperability problems.

> and this (Section 6.3):

> =C2=A0 =C2=A0If the email cannot be verified, then it SHOULD be treate= d the same
> =C2=A0 =C2=A0as all unverified email, regardless of whether or not it = looks like
> =C2=A0 =C2=A0it was signed.

> The two DKIM codes seem to encourage, or at least support, violation > of both of these.

That's a fair point.

Indeed.= =C2=A0 The example that stands out to me is a receiver that always expects = mail from a particular author domain to have a valid signature, and suddenl= y it doesn't.=C2=A0 This might be through ADSP, through some heuristic,= or through some private arrangement with the author domain's ADMD.

There might be something in the mix here about DMARC too, perhaps to in= dicate that DKIM failed and SPF was neutral, so report the failure.=C2=A0 (= Until there's a DMARC code, of course.)

It shouldn= 9;t happen in typical DKIM operation, however, so I've got no problem r= eminding readers of this draft of the citations you made above.

> Further, what code do I return if I check both SPF and DKIM, and both<= br> > checks fail? =C2=A0Does it really make sense to have these as three > different extended codes?

It's always been possible for there to be multiple failures happe= ning
at the same time. Which code gets returned in such cases is an implementati= on
judgement call. (Or perhaps more likely, it's what gets checked first.)=

+1.

-MSK
<= /div> --f46d043748f3af1cde04f91a1643-- From nobody Sun May 11 05:29:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C911A0318 for ; Sun, 11 May 2014 05:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6] autolearn=no 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 hqWJZngykw6f for ; Sun, 11 May 2014 05:29:22 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C31A023F for ; Sun, 11 May 2014 05:29:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 71E51FA007F; Sun, 11 May 2014 12:29:15 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1399811353-6320-6320/11/15; Sun, 11 May 2014 12:29:13 +0000 From: Arnt Gulbrandsen To: Terry Zink Date: Sun, 11 May 2014 14:29:13 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20140508203109.3798.qmail@joyce.lan> <16af3c3c01ee475eb5f2277b46d40576@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <00a101cf6b66$1ea379e0$4001a8c0@gateway.2wire.net> <8fc7ac7f-6e6e-45ab-b564-06555f82da7c@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kaCpZJM1VXE2POwlgIpxhqV0gHw Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 12:29:23 -0000 Terry Zink answers me: >> Why does SPF+DKIM warrant more protocol treatment? > > For clarity to the end user. If a message is rejected because > neither Condition 1 nor Condition 2 is met, then it is more > accurate to say to the end user that neither condition was met. > Saying only Condition 1 wasn't met misleads the sender into > thinking that either Condition 2 was met, or that it isn't a > requirement. This is incorrect and a bounce should reflect that. Clarity is desirable, but... the DNS generators I know generally take either a short-circuit approach where they stop as soon as they know the result of one test (e.g. "DKIM failed, SPF would fail too but I stopped before learning so"), or a scoring approach ("score=-4.8, required=12.0, dkim=passed, spf=failed, .."). So the approach you want is clear, yes, but one group doesn't have the information and the other has much more. That group can mix 2.a.b with 5.c.d to form either 2.e.f or 5.e.f, so reporting that in a usefully parsable way will be challenging. More bother than it's worth, IMO. Arnt From nobody Sun May 11 08:09:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F57E1A02B8 for ; Wed, 7 May 2014 20:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 5_D02CuNB6W2 for ; Wed, 7 May 2014 20:56:00 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id E7E1A1A0218 for ; Wed, 7 May 2014 20:55:59 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s483tsJo031199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 23:55:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s483tsJo031199 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1399521354; bh=HgA7QflLVVzNs8iO3brY43TH9Jw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TtVSWqIdJLyOVW+/mhdzyEXR/LWy/Lffw4HJruZcrsUckv2Cisjj2aqhA6P2123fM VAGtMpsVo3cI4zTOsoYI7dg8gw4uRBfJ8pXLHKH6l6CIpF3DJqX95cdmhR32+s5vsg TRRsmuEY6SGeF1aCXF5/6MEOwVGHcXW0W4Ow6AVk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s483tsJo031199 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 7 May 2014 23:55:33 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s483tWKC028866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 23:55:33 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Wed, 7 May 2014 23:55:32 -0400 From: "Black, David" To: Mark Nottingham Date: Wed, 7 May 2014 23:55:30 -0400 Thread-Topic: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 Thread-Index: Ac9qYQNfrrD7iLLATfyPo8XNrTZjQgADuL6Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xpLu8pWNeeNS9bUCK77VDtQ0hhY X-Mailman-Approved-At: Sun, 11 May 2014 08:09:12 -0700 Cc: "Black, David" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 03:56:02 -0000 > What target audience are you thinking of? Anyone who has a passing famili= arity > with the IETF must realise that modifying a Best Current Practice isn't > something you can do unilaterally? I'm thinking about people who aren't active in the IETF, and in particular don't pay a lot of attention to our processes (heck, it was years after I started coming to IETF meetings that I finally understood what a BCP is), but do look at our documents to figure out what to do before getting around to bringing their "clever" new ideas to us rather later than we might like to have initially seen them in a perfect world. > I'm struggling to come up with appropriate text here. Do we really need t= o > caution people that the process needs to be followed, and that might be > difficult if you want to do something controversial? >=20 > E.g. we could say that modifying BCP115 is "unusual" - but considering th= at > there's a modification of it underway right now, for the second time in e= ight > years, that's not strictly true. Ok ... here's an suggestion that doesn't use a 2119 keyword: OLD A specification that defines substructure within a URI scheme MUST do so in the defining document for that URI scheme, or by modifying [RFC4395]. NEW A specification that defines substructure within a URI scheme MUST do so in the defining document for that URI scheme, or by modifying [RFC4395]. The latter approach is not preferred and should only be used in exceptional circumstances. IMHO, twice in eight years is consistent with "exceptional circumstances." Thanks, --David > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, May 07, 2014 9:58 PM > To: Black, David > Cc: apps-discuss@ietf.org > Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 >=20 >=20 > On 7 May 2014, at 12:30 pm, Black, David wrote: >=20 > > For [2], while I'm sure that you're correct that any unwise attempt to > modify that BCP/RFC would be caught, IMHO, it would be helpful to add som= e > text to warn the unwise earlier, before they invest any significant > time/effort in pursuing that sort of modification. I don't particularly = care > whether an RFC 2119 keyword is used, but I would like to see some sort of= clue > offered ;-). >=20 > I'm struggling to come up with appropriate text here. Do we really need t= o > caution people that the process needs to be followed, and that might be > difficult if you want to do something controversial? >=20 > E.g. we could say that modifying BCP115 is "unusual" - but considering th= at > there's a modification of it underway right now, for the second time in e= ight > years, that's not strictly true. >=20 > What target audience are you thinking of? Anyone who has a passing famili= arity > with the IETF must realise that modifying a Best Current Practice isn't > something you can do unilaterally? >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From nobody Sun May 11 15:49:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A971A0377 for ; Sun, 11 May 2014 15:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 gNKcPeTJlX4h for ; Sun, 11 May 2014 15:49:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8442B1A0375 for ; Sun, 11 May 2014 15:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4BMn10A027942; Mon, 12 May 2014 00:49:01 +0200 (CEST) Received: from [192.168.217.145] (p54891D17.dip0.t-ipconnect.de [84.137.29.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A3D101956; Mon, 12 May 2014 00:49:00 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann Date: Mon, 12 May 2014 00:48:57 +0200 X-Mao-Original-Outgoing-Id: 421541337.446427-38972b09f87d1f735c854774c2b4cb22 Content-Transfer-Encoding: quoted-printable Message-Id: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Kd0yLgMRJLTvQrqlwiqoBCJD0Ik Cc: Peter Occil Subject: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 22:49:12 -0000 If you care about language tags, I hope the subject got your attention. If you don't, please ignore this request for assistance. Concise Binary Object Representation (CBOR, RFC 7049) is a binary format for structured objects. CBOR has a number of pre-defined data types and allows additional data types to be registered as "tags". Among the pre-defined data types is a text string (Unicode characters, encoded in UTF-8). No facility is pre-defined for associating a Language Tag with such a string. A new CBOR tag is being proposed for combining a CBOR text string with a Language Tag. The (single-page) proposal is in: http://peteroupc.github.io/CBOR/langtags.html The proposal is almost trivially obvious (pair a language tag with an UTF-8 string in a two-element array) and looks right to me. But I'm not an expert in Language Tags, and silly mistakes are being made by non-experts all the time. If you are an expert in Language Tags: -- Is anything missing or could anything be done in a better way? -- Or does this really simply look right? Responses to me privately or to the list are appreciated. Gr=FC=DFe, Carsten From nobody Sun May 11 18:30:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F61A03AC for ; Sun, 11 May 2014 18:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 ZlsMkPOpVyfn for ; Sun, 11 May 2014 18:30:22 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA11A03AA for ; Sun, 11 May 2014 18:30:21 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id D9D5A32E571; Mon, 12 May 2014 10:30:14 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7441_4e35_246ed713_0859_423b_86d8_d1dcf64c8627; Mon, 12 May 2014 10:30:14 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5F5BBBF4C5; Mon, 12 May 2014 10:30:14 +0900 (JST) Message-ID: <53702419.70403@it.aoyama.ac.jp> Date: Mon, 12 May 2014 10:30:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Carsten Bormann , IETF Apps Discuss References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> In-Reply-To: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pEIaPQ3d93ZWjRsxO12UBOmBnNM Cc: Peter Occil Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 01:30:24 -0000 Just took a short look. What I noticed is that this works fine on its=20 own, but as soon as this is combined with other properties/attributes of=20 strings, it may not scale. Regards, Martin. On 2014/05/12 07:48, Carsten Bormann wrote: > If you care about language tags, I hope the subject got your > attention. If you don't, please ignore this request for assistance. > > Concise Binary Object Representation (CBOR, RFC 7049) is a binary > format for structured objects. CBOR has a number of pre-defined data > types and allows additional data types to be registered as "tags". > Among the pre-defined data types is a text string (Unicode characters, > encoded in UTF-8). No facility is pre-defined for associating a > Language Tag with such a string. > > A new CBOR tag is being proposed for combining a CBOR text string with > a Language Tag. The (single-page) proposal is in: > > http://peteroupc.github.io/CBOR/langtags.html > > The proposal is almost trivially obvious (pair a language tag with an > UTF-8 string in a two-element array) and looks right to me. But I'm > not an expert in Language Tags, and silly mistakes are being made by > non-experts all the time. > > If you are an expert in Language Tags: > -- Is anything missing or could anything be done in a better way? > -- Or does this really simply look right? > > Responses to me privately or to the list are appreciated. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Sun May 11 19:09:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6FF1A03BE for ; Sun, 11 May 2014 19:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lraXJPZlumWq for ; Sun, 11 May 2014 19:09:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 093C81A03BD for ; Sun, 11 May 2014 19:09:36 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 508E522E1F3; Sun, 11 May 2014 22:09:22 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> Date: Mon, 12 May 2014 12:09:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wEpVTq9UVR1fEMzKSHrbxHvhv3w Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 02:09:38 -0000 On 8 May 2014, at 1:55 pm, Black, David wrote: > OLD > A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]. > NEW > A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]. The latter approach is not preferred and should only be > used in exceptional circumstances. I=92m not against this. What do other people think? -- Mark Nottingham http://www.mnot.net/ From nobody Mon May 12 07:32:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4B1A0247 for ; Mon, 12 May 2014 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 n89qty6ejIZe for ; Mon, 12 May 2014 07:32:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DBFDE1A071D for ; Mon, 12 May 2014 07:32:52 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4CEWgfr070051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 May 2014 07:32:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <53702419.70403@it.aoyama.ac.jp> Date: Mon, 12 May 2014 07:32:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <40416404-D7C6-4C53-8578-C65D83272661@vpnc.org> References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Fuv87VTuG1Mhuv8Nf3Yjas5GmOw Cc: Peter Occil Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 14:32:54 -0000 On May 11, 2014, at 6:30 PM, Martin J. D=FCrst = wrote: > Just took a short look. What I noticed is that this works fine on its = own, but as soon as this is combined with other properties/attributes of = strings, it may not scale. Martin has a good point. What Peter is proposing is, in essence: (Tag 38)[ "en", "Hello" ] where "Tag 38" defines the pair. If someone later wants to tag the UTF8 = text with some other property, such as a statement about the Unicode = property of all the characters in the string, that new tag would have to = be able to either wrap a UTF8 string *or* a tagged array. This could be replaced with an extensible map (for instance, with 0 = meaning "the string" and 1 meaning "the language tag"), but then there = would need to be an IANA registry for the map values. In the name of = simplicity, it is probably better just to let Tag 38 be defined as it is = now, and if other properties/attributes come up later, maybe then come = up with a more complicated scheme. --Paul Hoffman= From nobody Mon May 12 07:44:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446181A0721 for ; Mon, 12 May 2014 07:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 13rCuJSk1oVP for ; Mon, 12 May 2014 07:44:28 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 724421A0711 for ; Mon, 12 May 2014 07:44:28 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id ih12so7134251qab.12 for ; Mon, 12 May 2014 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=98PRBhSCCMsdshIvMyf72qNFL31EWV+7M9+VTcvAQAc=; b=zhkCOrb8eXe+iUd86gN0oETvmoxOmZWsuyF3lzlgDpU79AMApoDvlmrdZBkDFlmtpe oMR1Z1hckx+zIKbpytD1n/Ew4qeX74/LxgZNl0TXWpHi+8kTKD/Zfrwy8O7GVVR2mns6 +GQtYJHWeQl2aXfw2/SieFsn+cMhl9SV/IWCGAZ/iD/F+vH0wPD+nXjlxufdiZ5FvJ1U qntxVz4AFO4XWX+vpGDKWZiDBNaRpW84PJboM6EtJcoWt3h8ZYIdGjR1X9rvAmLmq5Vd TD6aB64EWT9ZfYRAVB1Kgmj1VYaXbfQvJWtRJV5sWEDQkexsqHHYbtkT7KaAmKBPVQex +BwQ== X-Received: by 10.229.134.198 with SMTP id k6mr38824045qct.13.1399905862253; Mon, 12 May 2014 07:44:22 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id 5sm7320879qgi.45.2014.05.12.07.44.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 07:44:21 -0700 (PDT) Message-ID: From: "Peter Occil" To: "IETF Apps Discuss" References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> <1058FF09CEF745CC875635CB365BCECC@PeterPC> In-Reply-To: <1058FF09CEF745CC875635CB365BCECC@PeterPC> Date: Mon, 12 May 2014 10:44:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140512-0, 05/12/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/z8f3DC8xDefqOqkryuaKtLpxiKk Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 14:44:29 -0000 Trying to send to the Apps-Discuss mailing list again, now that I'm subscribed. -----Original Message----- From: Peter Occil Sent: Sunday, May 11, 2014 10:20 PM To: "Martin J. Dürst" Cc: Carsten Bormann ; IETF Apps Discuss Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags If I understand what you mean by "not scaling", I think it's because my specification doesn't expressly allow using CBOR tags on the language tag string or the string being tagged with a language. If this interpretation is right, I think this can be solved by adding the following: "The language tag and the arbitrary string can have any number of CBOR tags on it." --Peter -----Original Message----- From: "Martin J. Dürst" Sent: Sunday, May 11, 2014 9:30 PM To: Carsten Bormann ; IETF Apps Discuss Cc: Peter Occil Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags Just took a short look. What I noticed is that this works fine on its own, but as soon as this is combined with other properties/attributes of strings, it may not scale. Regards, Martin. From nobody Tue May 13 10:54:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9D1A019C for ; Tue, 13 May 2014 10:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 M3zrEznVn1hP for ; Tue, 13 May 2014 10:54:34 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4569F1A0181 for ; Tue, 13 May 2014 10:54:30 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so904910veb.36 for ; Tue, 13 May 2014 10:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mtHJ2PY1OPQiFGm1PggdLtId9j/HtZrO5U8Glv5sq9Y=; b=AGXUcpI1BQsFs+FP9ZgiWQ7R9s7AEJE3/JcQOES1oz0k3qWegwVsmHUA+3jEbWlQkd KqbViFwHWtURclaHOngTLElkCwLlILW2SjMGIGZFCf3q7ctIYvn+tIC0JvbhMW+MmqF/ zXDx22iOY8TIX/efjK1koZo/rM+11059gjt/mqvVAAb8cNUH2+ozj30R42d/pIFC96yE 2P45ueNH4VVVIXVhZ4lZ2PS1XO90LVcUvyQ3PDbYGcfz+EjQwB6FRF7czrXVBhiBQH6F ibozYgM1h99vCrvcUvCsLuJJGR59wNc3w57nJrJJwkYM5zdVaeaHX7nuXT9mM8857wSl E6aQ== MIME-Version: 1.0 X-Received: by 10.52.110.105 with SMTP id hz9mr25598110vdb.9.1400003663565; Tue, 13 May 2014 10:54:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Tue, 13 May 2014 10:54:23 -0700 (PDT) In-Reply-To: References: <01P7NVDZK9CE000052@mauve.mrochek.com> Date: Tue, 13 May 2014 13:54:23 -0400 X-Google-Sender-Auth: 3dEc8Zng0aA6r0wSv3tukrhBarc Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/W1ZwTcecglDlyIBs3nw8kwbeifk Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:54:36 -0000 >> > The two DKIM codes seem to encourage, or at least support, violation >> > of both of these. >> >> That's a fair point. > > Indeed. The example that stands out to me is a receiver that always expects > mail from a particular author domain to have a valid signature, and suddenly > it doesn't. This might be through ADSP, through some heuristic, or through > some private arrangement with the author domain's ADMD. > > There might be something in the mix here about DMARC too, perhaps to > indicate that DKIM failed and SPF was neutral, so report the failure. > (Until there's a DMARC code, of course.) > > It shouldn't happen in typical DKIM operation, however, so I've got no > problem reminding readers of this draft of the citations you made above. I'm concerned about more than "reminding readers". The issue here is that the message was not bounced because of a broken DKIM signature or a missing one. It was bounced because of a policy that was triggered by the lack of a valid DKIM signature, and that policy is something that's outside of DKIM entirely. I'm very unhappy with the idea of returning a code that's explicitly documented to mean "there was no DKIM signature on the message", without being tied to the policy. I would be much happier with a code that was defined to mean "I bounced this because I have a policy that requires a valid DKIM signature from the From domain, and this message lacks such a signature." The situation for SPF is somewhat different, because SPF does have policy information as part of it. >> > Further, what code do I return if I check both SPF and DKIM, and both >> > checks fail? Does it really make sense to have these as three >> > different extended codes? >> >> It's always been possible for there to be multiple failures happening >> at the same time. Which code gets returned in such cases is an >> implementation >> judgement call. (Or perhaps more likely, it's what gets checked first.) > > +1. That's a facile answer, and not a very helpful one. Perhaps this would/will all be made better when DMARC adds a similar code that says "bounced because DMARC checks failed," and those who implement DMARC would then never return one of these, but would instead return that one. The point here, I guess, is that if I'm really bouncing this because the SPF check failed, regardless of what happened with DKIM, then returning the SPF code is fine. But if I'm bouncing this because the combination of SPF *and* DKIM checks failed, then I'm giving incomplete information about the bounce -- and I contend that it's sufficiently incomplete as to be seriously misleading (because SPF failures and DKIM failures happen for different reasons, if I care at all I need to see the whole picture. Here: SPF checks will *always* fail when you send mail to me at . So we're relying on the DKIM signature. If there's no valid DKIM signature and you bounce it with the SPF code, that's not useful information: we *know* SPF will fail. If you don't (also?) give the DKIM information, it's of no help. Barry From nobody Tue May 13 18:53:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927671A0182 for ; Tue, 13 May 2014 18:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 je5ATO5wnoat for ; Tue, 13 May 2014 18:53:38 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2F1A0197 for ; Tue, 13 May 2014 18:53:38 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.60.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB14322E1F4; Tue, 13 May 2014 21:53:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> Date: Wed, 14 May 2014 11:53:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vEm42q3o86og0EvnZm-o0SxrVQY Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 01:53:40 -0000 I got private feedback from others that they were OK with this too, so = I=92ve added: =93=94=94 The latter approach is not preferred and ought only be used in = exceptional circumstances. =93=94=94 (=93ought=94 instead of =93should=94 to avoid confusion over 2119 = terms). Cheers, On 8 May 2014, at 1:55 pm, Black, David wrote: >> What target audience are you thinking of? Anyone who has a passing = familiarity >> with the IETF must realise that modifying a Best Current Practice = isn't >> something you can do unilaterally? >=20 > I'm thinking about people who aren't active in the IETF, and in = particular > don't pay a lot of attention to our processes (heck, it was years = after I > started coming to IETF meetings that I finally understood what a BCP = is), > but do look at our documents to figure out what to do before getting = around > to bringing their "clever" new ideas to us rather later than we might = like > to have initially seen them in a perfect world. >=20 >> I'm struggling to come up with appropriate text here. Do we really = need to >> caution people that the process needs to be followed, and that might = be >> difficult if you want to do something controversial? >>=20 >> E.g. we could say that modifying BCP115 is "unusual" - but = considering that >> there's a modification of it underway right now, for the second time = in eight >> years, that's not strictly true. >=20 > Ok ... here's an suggestion that doesn't use a 2119 keyword: >=20 > OLD > A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]. > NEW > A specification that defines substructure within a URI scheme MUST = do > so in the defining document for that URI scheme, or by modifying > [RFC4395]. The latter approach is not preferred and should only be > used in exceptional circumstances. >=20 > IMHO, twice in eight years is consistent with "exceptional = circumstances." >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Wednesday, May 07, 2014 9:58 PM >> To: Black, David >> Cc: apps-discuss@ietf.org >> Subject: Re: OPS-Dir review of = draft-ietf-appsawg-uri-get-off-my-lawn-04 >>=20 >>=20 >> On 7 May 2014, at 12:30 pm, Black, David wrote: >>=20 >>> For [2], while I'm sure that you're correct that any unwise attempt = to >> modify that BCP/RFC would be caught, IMHO, it would be helpful to add = some >> text to warn the unwise earlier, before they invest any significant >> time/effort in pursuing that sort of modification. I don't = particularly care >> whether an RFC 2119 keyword is used, but I would like to see some = sort of clue >> offered ;-). >>=20 >> I'm struggling to come up with appropriate text here. Do we really = need to >> caution people that the process needs to be followed, and that might = be >> difficult if you want to do something controversial? >>=20 >> E.g. we could say that modifying BCP115 is "unusual" - but = considering that >> there's a modification of it underway right now, for the second time = in eight >> years, that's not strictly true. >>=20 >> What target audience are you thinking of? Anyone who has a passing = familiarity >> with the IETF must realise that modifying a Best Current Practice = isn't >> something you can do unilaterally? >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From nobody Tue May 13 19:41:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDE91A020E for ; Tue, 13 May 2014 19:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tyohK-GMcTZE for ; Tue, 13 May 2014 19:41:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE6E31A020D for ; Tue, 13 May 2014 19:41:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7RURHRECG002CSX@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 13 May 2014 19:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1400034987; bh=X5ZVUa+hv2glVmx7EHSolG5rd2B52FjX9NsFBSDXtXY=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Szwvr92BEQDZO1WDzTWyeoX+d1BmFwizmqQxHXyAVlznf4q6sWsQCNySu4375SOy8 CIuMyizDO0zORugWgh/G5jc/KjCNIjRn/DpwVhfoMz95mhpx7uWPJeGC6i7S5EkAem R4z2n6C/CTURYG/BpsF2eBTjBGHdN4/3iGkcpThQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7ROHZ2Y4G000052@mauve.mrochek.com>; Tue, 13 May 2014 19:36:23 -0700 (PDT) Message-id: <01P7RURE7JKS000052@mauve.mrochek.com> Date: Tue, 13 May 2014 18:15:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 May 2014 13:54:23 -0400" References: <01P7NVDZK9CE000052@mauve.mrochek.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DeKd_jlz1DYny4QMT0vHHHZqY3g Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 02:41:42 -0000 > >> > The two DKIM codes seem to encourage, or at least support, violation > >> > of both of these. > >> > >> That's a fair point. > > > > Indeed. The example that stands out to me is a receiver that always expects > > mail from a particular author domain to have a valid signature, and suddenly > > it doesn't. This might be through ADSP, through some heuristic, or through > > some private arrangement with the author domain's ADMD. But the point is this is a failure due to policy. The fact that the policy was implemented via DKIM is secondary and not really of interest to an automatic processor. > > There might be something in the mix here about DMARC too, perhaps to > > indicate that DKIM failed and SPF was neutral, so report the failure. > > (Until there's a DMARC code, of course.) > > > > It shouldn't happen in typical DKIM operation, however, so I've got no > > problem reminding readers of this draft of the citations you made above. > I'm concerned about more than "reminding readers". The issue here is > that the message was not bounced because of a broken DKIM signature or > a missing one. It was bounced because of a policy that was triggered > by the lack of a valid DKIM signature, and that policy is something > that's outside of DKIM entirely. Exactly. > I'm very unhappy with the idea of > returning a code that's explicitly documented to mean "there was no > DKIM signature on the message", without being tied to the policy. For my part, I think we worry excessively about defining codes, and end up with far too few codes available. I don't care if this gets defined as long as DMARC and similar policy schemes specify the codes that are to be used preferentially in such cases. > I would be much happier with a code that was defined to mean "I > bounced this because I have a policy that requires a valid DKIM > signature from the From domain, and this message lacks such a > signature." Exactly. > The situation for SPF is somewhat different, because SPF does have > policy information as part of it. It's a different situation, but not for this reason. Mitigating SPF issues is not something which, AFAIK, is amenable to automatic processing. Whereas mitigating DMARC policy failures is. This makes codes for SPF policy failures a "nice to have", but DMARC codes are more important. > >> > Further, what code do I return if I check both SPF and DKIM, and both > >> > checks fail? Does it really make sense to have these as three > >> > different extended codes? > >> > >> It's always been possible for there to be multiple failures happening > >> at the same time. Which code gets returned in such cases is an > >> implementation > >> judgement call. (Or perhaps more likely, it's what gets checked first.) > > > > +1. > That's a facile answer, and not a very helpful one. Perhaps this > would/will all be made better when DMARC adds a similar code that says > "bounced because DMARC checks failed," and those who implement DMARC > would then never return one of these, but would instead return that > one. Well, it's a statement of reality, facile or not, helpful or not. You might as well worry about the agents that refuse to implement any specific codes and always return 5.0.0 for everything. Or return the wrong codes. Yes, people are lazy and such implementations exist. It's not an argument against defining new codes, especially when those codes have real utility. There always has to be some degree of trust that server implementors will either know to use, or can be persuaded to use, codes that help clients do the right thing. > The point here, I guess, is that if I'm really bouncing this because > the SPF check failed, regardless of what happened with DKIM, then > returning the SPF code is fine. But if I'm bouncing this because the > combination of SPF *and* DKIM checks failed, then I'm giving > incomplete information about the bounce -- and I contend that it's > sufficiently incomplete as to be seriously misleading (because SPF > failures and DKIM failures happen for different reasons, if I care at > all I need to see the whole picture. > Here: SPF checks will *always* fail when you send mail to me at > . So we're relying on the DKIM signature. > If there's no valid DKIM signature and you bounce it with the SPF > code, that's not useful information: we *know* SPF will fail. If you > don't (also?) give the DKIM information, it's of no help. This example makes no sense to me. You seem to be conflating an incidental SPF failure with reporting actual errors. If the SPF failure does not, in fact, cause the message to fail to be delivered due to whatever SPF policy is in effect, then it has no business being reported. And if SPF policy is what causes the failure, it's likely to cause a failure at the MAIL FROM, before DKIM evaluation can occur. Or perhaps you're talking about a failure of DMARC policy, where the underlying failure can be either an SPF or DKIM check or even - if my understanding is correct - a cross check between the From: and MAIL FROM having nothing to do with DKIM or SPF failures per se. In such a case I don't see why an automatic processor would care: It knows that whatever policy is linked to the From: header field, and can act accordingly. Remember: The utility of having detail in enhanced status codes is primarily for automatic processing. (And yes, I'm aware of the stuff in NOTARY that says they're to be used for internationalization. I'll pay attention to that the minute someone shows me a widely deployed client that actually does this, along with the use-case where reporting a specific translated code to an end user had some actual value.) Nothing prevents elaboration of what failed in the text message associated with the code. So unless you can explain why an autoamatic processor dealing with a DMARC failure would care about the failure being because of SPF, DKIM, something else, or a combination of those factors, I fail to see the point. Now there are admittedly cases where more complex things happen, such as with SpamAssassin where a wide variety of checks are done, each contributing to an overall score, and the message is rejected if that score exceeds some thresshold. (Or more likely, silently discarded, making error reporting moot.) While it might conceivably have been nice to somewhat align such schemes with enhanced status codes, I think that ship has sailed. Ned From nobody Tue May 13 20:33:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366A51A0218; Tue, 13 May 2014 20:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 mqKUWhcOUluU; Tue, 13 May 2014 20:33:25 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A974A1A0145; Tue, 13 May 2014 20:33:25 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so1852730qcr.34 for ; Tue, 13 May 2014 20:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=fjwarKIQ6jPjCEa/u68v/yEz/f9hfYMZo1ncnA4LfhI=; b=K0drNiFGY+m+pyVCy85YbwaSwigwiBHIwCju6K14uT5IX7JEyR4aWdAIyjCi+Bqguj VVMdrBrhA4/lOykOmgHgduXQ0miMgxQroW83s8KeBAk9rPAsXHDUw4eyHW7akPlDdNDD 6oH07DRgVtY1/PD20uOEQ2DE8Ew6d1Z/kWoztn04jC/UqV1dZ3DO2C0d4HufZNXG1yR/ ZsHCxRzGJlb8/7TcUhyV2U6GyjOFOypZXbQWjFKsTz631n/uCFZetUc2UcDlQlEVK1GQ /pxtfpXaEw8zhC+akahMwXade2QlXkfjXLav6XdjX5R/A/ciIGtliX3MJWykJBMNuEk5 rI+A== X-Received: by 10.229.192.7 with SMTP id do7mr2094984qcb.1.1400038399007; Tue, 13 May 2014 20:33:19 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id w2sm920440qar.21.2014.05.13.20.33.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 20:33:18 -0700 (PDT) Message-ID: <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> From: "Peter Occil" To: "Randy Presuhn" , "LTRU Working Group" References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> In-Reply-To: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Tue, 13 May 2014 23:33:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140513-3, 05/13/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/P_Mi8xKriyQ-x25834S4GiCiGbg Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 03:33:27 -0000 I'm not aware of any use case where having multiple language tags for the same plain-text string is useful. For instance, RDF supports only one language tag for each string. And HTML5 doesn't support multiple languages in the Content-Language header field or META tag; instead, for multilingual documents, it relies on markup to set the language used for each section. But plain-text strings don't admit of HTML-like markup without more. Moreover, having multiple language tags for plain text leads to the additional problem of determining which parts of the text each language tag applies to, which is not so easy in the case of your three-language example. --Peter -----Original Message----- From: Randy Presuhn Sent: Monday, May 12, 2014 1:44 AM To: Ira McDonald ; LTRU Working Group ; Carsten Bormann ; Peter Occil ; Ira McDonald Subject: Re: [Ltru] Fwd: [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags Hi - Is representation of multi-lingual strings a concern? E.g. "She said 'Bonjour', and then 'Ciao'." Randy >From: Ira McDonald >Sent: May 11, 2014 4:50 PM >To: LTRU Working Group , Carsten Bormann , >Peter Occil , Ira McDonald >Subject: [Ltru] Fwd: [apps-discuss] Defining a CBOR tag for RFC 5646 >Language Tags > >Hi, > > > >Forwarding this note to the LTRU list for language tag experts to review. >Please copy your reply to IETF Apps Discuss list (see below). > >Cheers, >- Ira McDonald > > >---------- Forwarded message ---------- >From: Carsten Bormann >Date: Sun, May 11, 2014 at 6:48 PM >Subject: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags >To: IETF Apps Discuss >Cc: Peter Occil > > >If you care about language tags, I hope the subject got your >attention. If you don't, please ignore this request for assistance. > >Concise Binary Object Representation (CBOR, RFC 7049) is a binary >format for structured objects. CBOR has a number of pre-defined data >types and allows additional data types to be registered as "tags". >Among the pre-defined data types is a text string (Unicode characters, >encoded in UTF-8). No facility is pre-defined for associating a >Language Tag with such a string. > >A new CBOR tag is being proposed for combining a CBOR text string with >a Language Tag. The (single-page) proposal is in: > >http://peteroupc.github.io/CBOR/langtags.html > >The proposal is almost trivially obvious (pair a language tag with an >UTF-8 string in a two-element array) and looks right to me. But I'm >not an expert in Language Tags, and silly mistakes are being made by >non-experts all the time. > >If you are an expert in Language Tags: >-- Is anything missing or could anything be done in a better way? >-- Or does this really simply look right? > >Responses to me privately or to the list are appreciated. > >Grüße, Carsten > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue May 13 20:51:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4D71A0225 for ; Tue, 13 May 2014 20:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BWJih6BJGG4U for ; Tue, 13 May 2014 20:51:25 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAD1A0224 for ; Tue, 13 May 2014 20:51:24 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 43D09D0451E; Tue, 13 May 2014 23:51:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1400039477; bh=u63Ui0cBmF/UQTmMapBBkQtYVG5ONB6kCKkxMM3u2Kg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hkIpHXDufQpJO3rNVRJoBIppFm6iSJk2KGYI/bw1f8kLfodJ4r28982oq0z1v6Ud3 LoD2az0Y2C+Wdk90so4In/9jSqVAc70l7moXGs3aAN1ksIVx3Kq1PLWPpByzg/uPq5 wOR2yRBI6OropsrZgskjeg2X/T3YeJp/bMaqg7xk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0BBF7D04498; Tue, 13 May 2014 23:51:16 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 13 May 2014 23:51:15 -0400 Message-ID: <3170728.LAmlBes8sn@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <703AE153-B44D-4753-A672-23A8031E2A68@ericsson.com> References: <703AE153-B44D-4753-A672-23A8031E2A68@ericsson.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8v3oa6mawHNpERvMHABIp8RcQxs Subject: Re: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 03:51:28 -0000 On Friday, May 09, 2014 06:09:09 Salvatore Loreto wrote: > This is a formal call for adoption of draft-kucherawy-email-auth-codes into > APPSAWG. The call will close on May 23, 2014. > > The chairs note that there has already been some _expression_ of interest > for adoption in a recent thread; however more feedback is requested to make > sure appsawg is the right venue for this draft > > Please submit comments, concerns, support, etc. for this document's handling > by APPSAWG in reply to this thread by May 23, 2014. Note that this is not > an indication of support for the document as-is, only for APPSAWG adopting > it for further development. > > As for the APPSAWG process you will find the mini-charter for the draft at > the end of this message. in order to adopt the draft we also need to secure > a minimal set of reviewers and supporters for the document. If you'd like > to be added to that list, please say so in your reply. > > cheers > /Salvatore > > > > The "email-auth-codes" Mini-Charter > ---------------------------------------------- > > The adoption of SPF and DKIM as emerging email authentication technologies > has been significant. Absent from these, an oversight at the time, is a way > to indicate to an SMTP client the fact that a message is being rejected > specifically because one of these mechanisms failed to authenticate the > message. Without these, only generic authentication error codes can be > returned. > > This short document registers new Email Enhanced Status Codes (see RFC 3643 > and RFC 5248) so that this can be clearly indicated by SMTP servers. No > other work is proposed for this document > > The following have committed to work on the document through to publication: > > Reviewers: (please volunteer!) I volunteer. I'm not 100% sure we need this, but I'm definitely willing to work on figuring out if we do and working on the document assuming we do. Scott K From nobody Wed May 14 00:18:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9321A0276 for ; Wed, 14 May 2014 00:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 rfHDUIsLt0hv for ; Wed, 14 May 2014 00:18:24 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E0F221A0271 for ; Wed, 14 May 2014 00:18:23 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wm4so1691405obc.32 for ; Wed, 14 May 2014 00:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f8lybHLosC1/5aJ403fS6HPz7Z7vuWzR09hGX55zJPc=; b=WTzgpfsOobXT2k7ejfRgUNx1CD5Ly7xd9V8w5VP/lafE9rOO3CsFgzcMRZt39KeVds KhcrNKeO9ScN6ZimyZxuBWtmUW4mnTFdtmtDk0Z9zMaqDJGTcLrHXForC6TtSr2f5/CI psKCJX1pjQVGobrGJ0C7QLcfSnkCvVztMaRKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f8lybHLosC1/5aJ403fS6HPz7Z7vuWzR09hGX55zJPc=; b=cyLxEg+7khQhTwUFaSMpUYbK1bfIDueS/BmurKbCpTEEQtrrc+S5CbgfOl1k4wKZwG sFH08DpoZpvFnSepMtXYXC2R1UiZ2Hgj/6qZk3FFnKj07yXsAELmKgkac+AhU+RtRUKR 1zowmwe97qYsn5NzeSW0tvKx7LoJMkiE4ArKtGvUGZpmZ6+8T+XeFERLGYHuV6liWNbj QJnhZYSSQM6Ah/QOoFp7Xq0ARQL/JbwRsIOl7mORBqJFGK5rgEWDJQtOmXXvbXo0byEH p8y6PyJ18oN7Zcnla0ht67ur0AUmq7FBCN2aIYWR4l9X55EawkuEx65GGjCzOBLv9kXs Pbdg== X-Gm-Message-State: ALoCoQlDJDlGfpHl0VobmEw+rJizTTUVxIML/C+Hpd++SjGW4S6QZNiAGr8BuHNB7ArDbwyvThjb MIME-Version: 1.0 X-Received: by 10.182.104.101 with SMTP id gd5mr1711347obb.54.1400051897334; Wed, 14 May 2014 00:18:17 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Wed, 14 May 2014 00:18:17 -0700 (PDT) In-Reply-To: <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> Date: Wed, 14 May 2014 08:18:17 +0100 Message-ID: From: Dave Cridland To: Peter Occil Content-Type: multipart/alternative; boundary=089e0115ec140210e904f956fc5c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gxMdD2YTdHNKfNXtoFZRf7E2ua8 Cc: Randy Presuhn , LTRU Working Group , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 07:18:25 -0000 --089e0115ec140210e904f956fc5c Content-Type: text/plain; charset=UTF-8 On 14 May 2014 04:33, Peter Occil wrote: > I'm not aware of any use case where having multiple language tags for the > same plain-text string is useful. For instance, RDF supports only one > language tag for each string. And HTML5 doesn't support multiple languages > in the Content-Language header field or META tag; instead, for multilingual > documents, it relies on markup to set the language used for each section. > But plain-text strings don't admit of HTML-like markup without more. > > Moreover, having multiple language tags for plain text leads to the > additional problem of determining which parts of the text each language tag > applies to, which is not so easy in the case of your three-language example. > Many years ago, Mark Crispin and Chris Newman had a proposal for embedding language tags in invalid UTF-8; I seem to recall they publicly renounced their proposal rather dramatically in favour of a Unicode Consortium proposal for embedding the language tags somewhere in Plane 14 - published as RFC 2482. The fact it was all initiated in order to support the pressing needs of ACAP might give you some hints as to why it never really took off, but as a counter-proposal to language tags in metadata, it might be worth re-examining. Dave. --089e0115ec140210e904f956fc5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 4 May 2014 04:33, Peter Occil <poccil14@gmail.com> wrote:
I'm not aware of any use case where having multiple language tags for t= he same plain-text string is useful. =C2=A0For instance, RDF supports only = one language tag for each string. =C2=A0And HTML5 doesn't support multi= ple languages in the Content-Language header field or META tag; instead, fo= r multilingual documents, it relies on markup to set the language used for = each section. But plain-text strings don't admit of HTML-like markup wi= thout more.

Moreover, having multiple language tags for plain text leads to the additio= nal problem of determining which parts of the text each language tag applie= s to, which is not so easy in the case of your three-language example.

Many years ago, Mark Crispin and Chris New= man had a proposal for embedding language tags in invalid UTF-8; I seem to = recall they publicly renounced their proposal rather dramatically in favour= of a Unicode Consortium proposal for embedding the language tags somewhere= in Plane 14 - published as RFC 2482.

The fact it was all initiated in order to support the p= ressing needs of ACAP might give you some hints as to why it never really t= ook off, but as a counter-proposal to language tags in metadata, it might b= e worth re-examining.

Dave.=C2=A0
--089e0115ec140210e904f956fc5c-- From nobody Wed May 14 00:42:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423981A0276 for ; Wed, 14 May 2014 00:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 06Za2NWkK_QW for ; Wed, 14 May 2014 00:42:27 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2721A0273 for ; Wed, 14 May 2014 00:42:27 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so1458241wgg.21 for ; Wed, 14 May 2014 00:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S8b97c0kQO0Wc03k8M8PsMyUhg95ZPhcdSSsgZZ+hpY=; b=dyxZTa0F7KGLXAkrsSBgPZS4Xq6nWqiTUqe+DKXrrHpLdjn28X4HmqawUkeb3gup1m 66wN1TDqjzUsGti9GNmRAeZ4kI3QAccgl3Nf3cbV949LX5U3xdbjtkXV2m3D06M5Xz0z HCQdT8H6hVjmp9xxegbb8UnyGlLrn4+2V3FzVwC2egmyM7kOr6QvVrzEqd2+RRRemdBp JkT+88OTr58RVIl4x3IAYBkGq4xeWzRGlboUGZdmGkif9RNPABfbFaH3EWdIEQUEbr4K UTr96qRbX9JofkZpSJwgIVIn2fqHtPrgHSfX+vUVayCQ5XHgsEa+YO5VPyCUbDrtIvLu QLlA== MIME-Version: 1.0 X-Received: by 10.180.92.103 with SMTP id cl7mr2181913wib.26.1400053340636; Wed, 14 May 2014 00:42:20 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 14 May 2014 00:42:20 -0700 (PDT) In-Reply-To: <01P7RURE7JKS000052@mauve.mrochek.com> References: <01P7NVDZK9CE000052@mauve.mrochek.com> <01P7RURE7JKS000052@mauve.mrochek.com> Date: Wed, 14 May 2014 00:42:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d04388e49090cd404f95752a5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RfbZU2tk9x8nSlG4q5azwv-8xzg Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Registering email status codes for authentication failures X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 07:42:29 -0000 --f46d04388e49090cd404f95752a5 Content-Type: text/plain; charset=UTF-8 On Tue, May 13, 2014 at 6:15 PM, Ned Freed wrote: > > But the point is this is a failure due to policy. The fact that the policy > was implemented via DKIM is secondary and not really of interest to an > automatic processor. > [...] > > I would be much happier with a code that was defined to mean "I > > bounced this because I have a policy that requires a valid DKIM > > signature from the From domain, and this message lacks such a > > signature." > > Exactly. > Sure, that's fine with me. -MSK --f46d04388e49090cd404f95752a5 Content-Type: text/html; charset=UTF-8
On Tue, May 13, 2014 at 6:15 PM, Ned Freed <ned.freed@mrochek.com> wrote:

But the point is this is a failure due to policy. The fact that the policy
was implemented via DKIM is secondary and not really of interest to an
automatic processor.
[...]
> I would be much happier with a code that was defined to mean "I
> bounced this because I have a policy that requires a valid DKIM
> signature from the From domain, and this message lacks such a
> signature."

Exactly.

Sure, that's fine with me.

-MSK
--f46d04388e49090cd404f95752a5-- From nobody Wed May 14 01:26:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359871A0278; Wed, 14 May 2014 01:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_CASH=2.3, SPF_HELO_PASS=-0.001] autolearn=no 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 gYFfwFmczwY0; Wed, 14 May 2014 01:26:45 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDB41A0273; Wed, 14 May 2014 01:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4E8QVSV019627; Wed, 14 May 2014 10:26:31 +0200 (CEST) Received: from eduroam-pool7-0232.wlan.uni-bremen.de (eduroam-pool7-0232.wlan.uni-bremen.de [134.102.112.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 55894196D; Wed, 14 May 2014 10:26:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Wed, 14 May 2014 10:26:29 +0200 X-Mao-Original-Outgoing-Id: 421748789.324169-a20965c2f85802dc9abb9a53e438585d Content-Transfer-Encoding: quoted-printable Message-Id: <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> To: Dave Cridland X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AXOvOgUoYctlNAutDuZgn7bAPh4 Cc: Randy Presuhn , LTRU Working Group , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 08:26:47 -0000 On 14 May 2014, at 09:18, Dave Cridland wrote: > embedding language tags in invalid UTF-8 In 2010, RFC 6082 deprecated that (and moved RFC 2482 to Historic), = saying: It is an idea whose time never quite came. It has been superseded by whole-transaction language identification such as the MIME Content-language header [RFC3282] and more general markup mechanisms such as those provided by XML. The Unicode Consortium has deprecated the language tag character facility and strongly recommends against its use. The application that motivated the new CBOR tag we are talking about = happens not to require multi-language strings. (It seems their usage is mostly about internationalization, i.e., = pairing a string with its locale.) If such a facility were needed, it could be modeled as (shown in CBOR = diagnostic notation): somenewtag([[=E2=80=9Cen=E2=80=9D, "She said =E2=80=98=E2=80=9C], = [=E2=80=9Cfr=E2=80=9D, =E2=80=9CBonjour=E2=80=9D], [=E2=80=9Cen=E2=80=9D, = "', and then =E2=80=98=E2=80=9C], [=E2=80=9Czh=E2=80=9D, =E2=80=9C=E4=BD=A0= =E5=A5=BD=E2=80=9D], [=E2=80=9Cen=E2=80=9D, "=E2=80=99.=E2=80=9D]]) or even, maximizing compatibility by using the proposed tag as well: othernewtag([38([=E2=80=9Cen=E2=80=9D, "She said =E2=80=98=E2=80=9C]), = 38([=E2=80=9Cfr=E2=80=9D, =E2=80=9CBonjour=E2=80=9D]), 38([=E2=80=9Cen=E2=80= =9D, "', and then =E2=80=98=E2=80=9C]), 38([=E2=80=9Czh=E2=80=9D, = =E2=80=9C=E4=BD=A0=E5=A5=BD=E2=80=9D]), 38([=E2=80=9Cen=E2=80=9D, = "=E2=80=99.=E2=80=9D])]) (there are many other ways this could be modeled, too). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 14 03:09:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8261A0286; Wed, 14 May 2014 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 RtXkbs2FE0aM; Wed, 14 May 2014 03:09:39 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8085E1A027E; Wed, 14 May 2014 03:09:39 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id i8so2392646qcq.15 for ; Wed, 14 May 2014 03:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=RPN0I8iHie0afCHczSOV0QlFHA5YEirOfYqiRK2DWTI=; b=fkCv/1JxvG4N71yr8fwoWs9bFp6toAhFrz5a0l+TH3dKxRHWBxECS0yM0/mt8utO5S 0qZf4kWtb0vUfe2Le/VGrdnSFggEzthPQsZZneDdGPpP7b6PXExORLjVs+YSXq/SiCpm jn5O53OPtqUuN5B7LwmgJyc92SUpf39JUFCE/SDkmGqOqbQKHrMosgtXYgg56fU95U0A rOS5C664PWhWaEpVdaRErA/o8/Obu7ArgV/Z2GwCWrmk8T+e6nMeZ8uyNLoHwdhoLGOL EsKdZo1ZCzDtCWge1rPnkzVlY7H97Ef3Cx9oAFtdBTe4+eit8OPvcwrtct56RaBxKkYp qLDQ== X-Received: by 10.140.28.198 with SMTP id 64mr3974845qgz.49.1400062172763; Wed, 14 May 2014 03:09:32 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id d18sm2204747qac.28.2014.05.14.03.09.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 03:09:32 -0700 (PDT) Message-ID: <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> From: "Peter Occil" To: "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> In-Reply-To: <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> Date: Wed, 14 May 2014 06:09:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140513-3, 05/13/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/b9SmzvcIRx7l2D1ktemQW5YlYxw Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:09:40 -0000 I have one last issue. I want to clarify that the language tag and the tagged string can optionally be annotated with CBOR tags. For example: 38([tagX("en"), tagY("Hello world")]) I think this will address some of the "scalability" issue that Martin Duerst raised. --Peter From nobody Wed May 14 06:20:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC651A0095 for ; Wed, 14 May 2014 06:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 uGPNKfmU9cHe for ; Wed, 14 May 2014 06:20:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id 791881A0299 for ; Wed, 14 May 2014 06:20:34 -0700 (PDT) Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (10.255.75.37) by AMSPR07MB469.eurprd07.prod.outlook.com (10.242.106.139) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 13:20:26 +0000 Received: from pc6 (86.183.19.164) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 13:20:25 +0000 Message-ID: <007601cf6f76$ec07ec40$4001a8c0@gateway.2wire.net> From: t.petch To: IETF Apps Discuss References: Date: Wed, 14 May 2014 14:17:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.183.19.164] X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(101416001)(81816999)(79102001)(88136002)(19580395003)(76482001)(85852003)(50466002)(76176999)(83322001)(47776003)(83072002)(74502001)(4396001)(23676002)(66066001)(99396002)(33646001)(84392001)(87286001)(86362001)(20776003)(81342001)(44716002)(50226001)(46102001)(93916002)(81686999)(87936001)(14496001)(92566001)(89996001)(44736004)(31966008)(64706001)(77982001)(62236002)(74662001)(62966002)(80022001)(77156001)(61296002)(21056001)(50986999)(102836001)(92726001)(81542001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB469; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iynGcZVjeYbR5JlF-RoYux2qRHk Subject: [apps-discuss] X-Google-DKIM-Signature: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:20:37 -0000 I am seeing X-Google-DKIM-Signature in the headers of some of the mail I get on IETF lists but struggle to see how it can be being used. Who is going to verify a Google proprietary signature? Can anyone clarify this for me? I am familiar with DKIM and its various policy RFC. To all intents and purposes, it looks like a regular DKIM signature, v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=... bh=... b=... etc Tom Petch From nobody Wed May 14 11:44:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD01A02B4 for ; Wed, 14 May 2014 11:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no 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 d5ZULtYZrICA for ; Wed, 14 May 2014 11:44:03 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 348A21A0147 for ; Wed, 14 May 2014 11:44:02 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so2921732wiw.8 for ; Wed, 14 May 2014 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DbRNWlPRf+f8FZGTNFHE0qQdut+tXM98PUsclt/VXmg=; b=GLr8Tp9LrxoSXZ0xH+8ApIxDE36EPyBX/U8Ro5+00d//1cKGQONIISV0id9+V6XbSP HP0zLu7eqX9BOl45AoJhKuv2UlmKEw0V3ezW4F4Uv5w3m5P0dxTn+LTGhkomE1A23Hwa wuBZEFp4NCHCRw2R/bXs3Ntf0QA1OxnnkkhqeIXyZfrJ7l6awr57ptPrw/F2DmXKA82V h0bazHwZr7qzxFEYAWAr4RgPF0lY/iFSlsxPOUAIMARKDLYxvdmKTLuY5yCHjSCYUd0k h8Q4eItrzdnz29LOww3wzo98T2Cubvg9kqFCK2FdF7w5U4ean+THGOmaPJ+fXMtuKKrm pL3A== MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr27225146wiw.5.1400093035853; Wed, 14 May 2014 11:43:55 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 14 May 2014 11:43:55 -0700 (PDT) In-Reply-To: <007601cf6f76$ec07ec40$4001a8c0@gateway.2wire.net> References: <007601cf6f76$ec07ec40$4001a8c0@gateway.2wire.net> Date: Wed, 14 May 2014 11:43:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=f46d043c82460dfd3a04f96090cb Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_blROpC5GpEPk96nBqKoNUaO5rg Cc: IETF Apps Discuss Subject: Re: [apps-discuss] X-Google-DKIM-Signature: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 18:44:04 -0000 --f46d043c82460dfd3a04f96090cb Content-Type: text/plain; charset=UTF-8 On Wed, May 14, 2014 at 6:17 AM, t.petch wrote: > I am seeing > X-Google-DKIM-Signature > in the headers of some of the mail I get on IETF lists but struggle to > see how it can be being used. Who is going to verify a Google > proprietary signature? > As I understand it, that's an internally generated signature that's given different handling of some kind by other internal agents. It's not meant to be consumed by anyone outside of Gmail, though it is otherwise a valid DKIM signature. -MSK --f46d043c82460dfd3a04f96090cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 14, 2014 at 6:17 AM, t.petch <ietfc@btconne= ct.com> wrote:
I am seeing
X-Google-DKIM-Signature
in the headers of some of the mail I get on IETF lists but struggle to
see how it can be being used. =C2=A0Who is going to verify a Google
proprietary signature?

As I understand = it, that's an internally generated signature that's given different= handling of some kind by other internal agents.=C2=A0 It's not meant t= o be consumed by anyone outside of Gmail, though it is otherwise a valid DK= IM signature.

-MSK
--f46d043c82460dfd3a04f96090cb-- From nobody Thu May 15 04:07:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507891A0027 for ; Thu, 15 May 2014 04:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 k0jCSqX_f28Y for ; Thu, 15 May 2014 04:07:38 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3336B1A0028 for ; Thu, 15 May 2014 04:07:32 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1E8B241C064 for ; Thu, 15 May 2014 13:07:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ShmzKy7m0iDV for ; Thu, 15 May 2014 13:07:22 +0200 (CEST) X-Originating-IP: 10.58.1.144 Received: from webmail.gandi.net (unknown [10.58.1.144]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 9B5B541C079 for ; Thu, 15 May 2014 13:07:21 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 15 May 2014 13:07:21 +0200 From: "Michiel B. de Jong" To: apps-discuss@ietf.org Message-ID: X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.9.5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xC8-aAiqlg_QagApKPVHjT5JATA Subject: [apps-discuss] remoteStorage (draft-dejong-remotestorage-03 rc2 release candidate tagged) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 11:07:40 -0000 Hi, In the area of per-user data storage from the browser, we are preparing version 03 of the remoteStorage I-D. The main change is that we are opening up the option to use Kerberos instead of OAuth: https://github.com/remotestorage/spec/blob/1b5592f4a3c3493ec045becfac22f8c38c5cc898/CHANGELOG.md Some context: There are now three options for a website to let you store your own user data at a different DNS domain than the website you are using. All three use cross-origin AJAX requests with OAuth bearer tokens: * GoogleDrive JS API * Dropbox.js * remoteStorage Google are of course the only provider of GoogleDrive, and Dropbox are the only provider of Dropbox, but remoteStorage is an open protocol (work in progress) that can be implemented on any server by anyone. Who wants to help open up the monopolies on hosting per-user data? :) We are trying to create an open alternative for not only GoogleDrive and Dropbox, but also Apple's iCloud, MicroSoft's OneDrive, and even Canonical's UbuntuOne, all of which use proprietary and incompatible APIs. If this seems to be an important battle to you or to your employer, then: Comments and input welcome! Cheers, Michiel de Jong From nobody Thu May 15 09:35:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED3A1A04F8; Thu, 15 May 2014 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 Ik-OF1S8kL7P; Thu, 15 May 2014 09:35:30 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FA31A00C2; Thu, 15 May 2014 09:35:30 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so2123969qge.36 for ; Thu, 15 May 2014 09:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=gT2eh/GxUgPIJQiherfxI26U1jhsnYLTUYajrtm6Fxs=; b=Y7tG7Os/Gn5S/wH9eU8V26APdS7YVwix+aN7ZGNuGT4lFGymEWYbPIaodCi/cxyjOJ GFliDKxBj17qkzZAwBA0SjnOMh6nEO7bnIOYMl08dD1GFlmt6xW+7OgqyPUOgASLh6lM zk0vSJYtfj3lOoF2b1uWn+JCICYvFWPPpoMIViADkMGTgZesekt/NY+QtL7ynk2H9e5j qUIOfwtTo4nJQM+JkS+y+iL2JYIpgD6c4SFh8V8rXDtZyqNuJ2BQO2yugJ/SCSIswRit 48vt5d17P8troLot3nLvAVwxy6xyvAjP05/641xH0ykZaNdu6aOo2j+bpWeXKhTIJ7fd lj+Q== X-Received: by 10.224.119.131 with SMTP id z3mr14609582qaq.91.1400171722542; Thu, 15 May 2014 09:35:22 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id w2sm8635191qar.21.2014.05.15.09.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 09:35:21 -0700 (PDT) Message-ID: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> From: "Peter Occil" To: "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> In-Reply-To: <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> Date: Thu, 15 May 2014 12:35:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140515-0, 05/15/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pTBFHuaEWfwzXTWv7lUqn-HdtSs Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:35:31 -0000 I have updated my specification on language-tagged strings. http://peteroupc.github.io/CBOR/langtags.html The two things new are: - The "NOTE" section. - The sentence "Both the language tag and the arbitrary string can optionally be annotated with CBOR tags." --Peter From nobody Thu May 15 13:54:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8111A0164 for ; Thu, 15 May 2014 13:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BNaTN4gJhLj4 for ; Thu, 15 May 2014 13:54:47 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35A1A0124 for ; Thu, 15 May 2014 13:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4884B29D5B7 for ; Thu, 15 May 2014 15:54:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa8Yxj3tp61m for ; Thu, 15 May 2014 15:54:40 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2BB1C29D5B0 for ; Thu, 15 May 2014 15:54:40 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1DC5229D5B7 for ; Thu, 15 May 2014 15:54:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OjIxUXlxfwOq for ; Thu, 15 May 2014 15:54:40 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 0083C29D5B0 for ; Thu, 15 May 2014 15:54:39 -0500 (CDT) Date: Thu, 15 May 2014 15:54:38 -0500 (CDT) From: Franck Martin To: apps-discuss@ietf.org Message-ID: <727879497.117811.1400187278910.JavaMail.zimbra@peachymango.org> In-Reply-To: <401851503.117798.1400187194460.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-martin-smtp-ipv6-to-ipv4-fallback-01.txt Thread-Index: X/GlHKF738qZkjACN/tuMnoEQXh9FQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L6qjcK-qCZbBBuKQkxwb57Ct52w Subject: [apps-discuss] New Version Notification for draft-martin-smtp-ipv6-to-ipv4-fallback-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 20:54:49 -0000 I decided to drop the SMTP extension, as by the time it is implemented, the world would have changed, and people did not seem to excited about it. A new version of I-D, draft-martin-smtp-ipv6-to-ipv4-fallback-01.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Name: draft-martin-smtp-ipv6-to-ipv4-fallback Revision: 01 Title: SMTP IPv6 to IPv4 Fallback: An Applicability Statement Document date: 2014-05-15 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-martin-smtp-ipv6-to-ipv4-fallback-01.txt Status: https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/ Htmlized: http://tools.ietf.org/html/draft-martin-smtp-ipv6-to-ipv4-fallback-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-martin-smtp-ipv6-to-ipv4-fallback-01 Abstract: This Applicability Statement describes how Mail Transfer Agents (MTAs) can be encouraged to fall back to IPv4 when a message is refused over IPv6. From nobody Thu May 15 18:11:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D91A06D7; Thu, 15 May 2014 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dIK19h3tHp0h; Thu, 15 May 2014 18:11:33 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54971A06D9; Thu, 15 May 2014 18:11:32 -0700 (PDT) Received: from [192.168.1.57] (unknown [118.209.226.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B0C00509B6; Thu, 15 May 2014 21:11:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55B645@MX15A.corp.emc.com> Date: Fri, 16 May 2014 11:11:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <10DD33E7-440B-41AC-9E7F-BC62E5C79510@mnot.net> References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C55B645@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G7CAV6Niy977JzWeJQ384d9RFtY Cc: "ops-dir@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 01:11:40 -0000 Hi David, Discussing this with the IESG, I=92ve currently revised this to: =93=94=94 A specification that defines substructure within a specific URI scheme = MUST do so in the defining document for that URI scheme. A specification = that defines substructure for URI schemes overall MUST do so by = modifying {{BCP115}}. =93=94=94 Do you think a note about the inadvisability of doing a BCP115 = modification is still necessary, or does the separation here help? Thanks, On 14 May 2014, at 10:49 pm, Black, David wrote: > Mark, >=20 > That works for me; thank you for following through on this. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Tuesday, May 13, 2014 9:53 PM >> To: Black, David >> Cc: apps-discuss@ietf.org >> Subject: Re: OPS-Dir review of = draft-ietf-appsawg-uri-get-off-my-lawn-04 >>=20 >> I got private feedback from others that they were OK with this too, = so I've >> added: >>=20 >> """ >> The latter approach is not preferred and ought only be used in = exceptional >> circumstances. >> """ >>=20 >> ("ought" instead of "should" to avoid confusion over 2119 terms). >>=20 >> Cheers, >>=20 >>=20 >>=20 >> On 8 May 2014, at 1:55 pm, Black, David wrote: >>=20 >>>> What target audience are you thinking of? Anyone who has a passing >> familiarity >>>> with the IETF must realise that modifying a Best Current Practice = isn't >>>> something you can do unilaterally? >>>=20 >>> I'm thinking about people who aren't active in the IETF, and in = particular >>> don't pay a lot of attention to our processes (heck, it was years = after I >>> started coming to IETF meetings that I finally understood what a BCP = is), >>> but do look at our documents to figure out what to do before getting = around >>> to bringing their "clever" new ideas to us rather later than we = might like >>> to have initially seen them in a perfect world. >>>=20 >>>> I'm struggling to come up with appropriate text here. Do we really = need to >>>> caution people that the process needs to be followed, and that = might be >>>> difficult if you want to do something controversial? >>>>=20 >>>> E.g. we could say that modifying BCP115 is "unusual" - but = considering that >>>> there's a modification of it underway right now, for the second = time in >> eight >>>> years, that's not strictly true. >>>=20 >>> Ok ... here's an suggestion that doesn't use a 2119 keyword: >>>=20 >>> OLD >>> A specification that defines substructure within a URI scheme MUST = do >>> so in the defining document for that URI scheme, or by modifying >>> [RFC4395]. >>> NEW >>> A specification that defines substructure within a URI scheme MUST = do >>> so in the defining document for that URI scheme, or by modifying >>> [RFC4395]. The latter approach is not preferred and should only be >>> used in exceptional circumstances. >>>=20 >>> IMHO, twice in eight years is consistent with "exceptional = circumstances." >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Mark Nottingham [mailto:mnot@mnot.net] >>>> Sent: Wednesday, May 07, 2014 9:58 PM >>>> To: Black, David >>>> Cc: apps-discuss@ietf.org >>>> Subject: Re: OPS-Dir review of = draft-ietf-appsawg-uri-get-off-my-lawn-04 >>>>=20 >>>>=20 >>>> On 7 May 2014, at 12:30 pm, Black, David = wrote: >>>>=20 >>>>> For [2], while I'm sure that you're correct that any unwise = attempt to >>>> modify that BCP/RFC would be caught, IMHO, it would be helpful to = add some >>>> text to warn the unwise earlier, before they invest any significant >>>> time/effort in pursuing that sort of modification. I don't = particularly >> care >>>> whether an RFC 2119 keyword is used, but I would like to see some = sort of >> clue >>>> offered ;-). >>>>=20 >>>> I'm struggling to come up with appropriate text here. Do we really = need to >>>> caution people that the process needs to be followed, and that = might be >>>> difficult if you want to do something controversial? >>>>=20 >>>> E.g. we could say that modifying BCP115 is "unusual" - but = considering that >>>> there's a modification of it underway right now, for the second = time in >> eight >>>> years, that's not strictly true. >>>>=20 >>>> What target audience are you thinking of? Anyone who has a passing >> familiarity >>>> with the IETF must realise that modifying a Best Current Practice = isn't >>>> something you can do unilaterally? >>>>=20 >>>> Cheers, >>>>=20 >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From nobody Mon May 19 03:07:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB61A0314 for ; Mon, 19 May 2014 03:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.412 X-Spam-Level: **** X-Spam-Status: No, score=4.412 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 r_4upRV4_NVq for ; Mon, 19 May 2014 03:07:33 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB361A032A for ; Mon, 19 May 2014 03:07:33 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id A61D632E539; Mon, 19 May 2014 19:07:32 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4cf4_bbfd_b74f215d_7819_45e8_b767_e1690ab88c65; Mon, 19 May 2014 19:07:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C6F8EBF53D; Mon, 19 May 2014 19:07:31 +0900 (JST) Message-ID: <5379D7D7.8020202@it.aoyama.ac.jp> Date: Mon, 19 May 2014 19:07:19 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-p2psip-diagnostics.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5U9ASEwQd1B1-3pj1IcqSKzaeAc Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-p2psip-diagnostics-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 10:07:36 -0000 I have been selected as the Applications Area Review Team reviewer for=20 this draft (for background on apps-review, please see=20 http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments=20 you may receive. Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft. Document: draft-ietf-p2psip-diagnostics Title: P2P Overlay Diagnostics Reviewer: Martin J. D=C3=BCrst Review Date: various days before and including May 19, 2014 IETF Last Call Date: not yet IESG Telechat Date: not yet Summary: To me, the draft looks in reasonable shape, with some issues to=20 be fixed as bellow. However, I'm not a SIP or P2P expert, and therefore=20 this review shouldn't be taken as an active endorsement of the draft. Preface: I sincerely apologize for the long time it took me to review=20 this draft. I have reviewed -13, but I have also checked the diff at=20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-14.txt= =20 to make sure I haven't missed anything new. Overall issue: There were quite a few places in the text where the=20 wording choice was somewhat suboptimal. I strongly recommend a review by=20 a native English speaker familiar with the subject. Minor issues: Structure: The meat of the draft is all in section 5. It may make sense=20 to split that section (but merge others) to get a better balance. But I=20 can't give a specific proposal, sorry. The start of section 5 also reads=20 like an abstract for a whole document. p. 9: DiagnosticRequest has 'dmFlags' before 'length', but in the text,=20 the order is reversed. Please align. p. 10: There is only a single 'kind' code (0xFFFE) reserved for private=20 use. Given that currently only about 16 such codes are defined in the=20 spec, it seems okay to reserve a somewhat larger number of these codes=20 for private/experimental use. 5.1.2, timestamp_received (and timestamps in general): is a resolution=20 of milliseconds good enough? It may be way more than actually useful in=20 a world-wide overlay, but it could be less than desirable in a local=20 deployment. Same also for the limits (10 to 600 seconds) on the=20 expiration field. A local network should probably not need a timeout of=20 10 seconds. 5.1.3, PROCESS_POWER, BANDWIDTH: 32bits of MIPS and Kbps seem to cover=20 the current range of hardware, but what about extremely slow hardware or=20 very fast hardware in a few years? Similar for bandwidth. What about=20 e.g. defining some kind of log scale, which may reflect the long-term=20 realities of technology and market better? Same for MEMORY_FOOTPRINT. 5.1.3, SOFTWARE_VERSION: there is a '*', is that supposed to be some=20 kind of syntax indicator (e.g. repetition as in regular expressions)?=20 The example should be put into quotes. 5.1.3, BATTERY_STATUS: "using a battery power" -> "using battery power" 5.2: "and will treat the message if it was a normal ping" -> "and will=20 treat the message *AS* if it was a normal ping" 5.4: I'm surprised that this diagnostics document has to define an error=20 code for "Underlay Destination Unreachable". Shouldn't such an error=20 condition occur in the base protocol already? 5.5.1: There are way too many MUSTs here. It would be much better to put=20 limitations on field values where these field values are defined, and=20 just describe the limitations in positive language. 5.5.1: The first paragraph uses "Ping message with diagnostic=20 extension", the second paragraph uses "diagnostic Ping message". Please=20 unify terminology. 5.5.3: The first two paragraphs semantically form one single sentence.=20 The first paragraph forms one syntactical sentence. Both of these are=20 too long. In the first paragraph, it is impossible to understand to what clauses=20 the initial "When" applies without rereading the paragraph. Please fix. Section 6: Just to check, would this be what's described in this section: Would also be okay? Or should it be=20 ? Things like these should be carefully=20 specified. An actual example also will help. 8.1 and 8.5: Rather than creating two registries that have to be kept in=20 sync, it would be better to create one registry where the first 64=20 entries have more columns than the rest. 8.6: "XML namespaces": I only see one namespace. Is the intent that the=20 example above actually be written e.g. like Why is there a need for a separate namespace for just one or two=20 elements? It's a common misconception that each spec that defines a bit=20 of XML has to have its own namespace. As long as there is coordination=20 to avoid element name collisions (which should be achievable e.g. in an=20 IETF WG), there's absolutely no need for such piecemeal namespaces. : I'm not at all sure it's a good idea to use an=20 XML namespace URI to identify protocol/format extensions. But it may=20 already be too late to fix this. Regards, Martin. From nobody Mon May 19 12:26:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B112F1A03CE; Mon, 19 May 2014 12:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RlloyPNHdP7T; Mon, 19 May 2014 12:25:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1931A03CD; Mon, 19 May 2014 12:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1400527558; x=1401737158; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IbelAiHVXAcThumVFUm1nOpwNYeas8uKVC1bXOwiC4U=; b=Gj2M1R3Bo/YsjaS7RcROZGUeiiMQAKwwBms6ntP6n2bFNedMVM38SqJh COm74F3H9YBnVxvRzGGLUlvLfSzQBAFu7dEsu+UpbVLD4vOrPNFtxKy3J M1HkD0eHQtsBv5YGxZ1qQtCJfYeQUVUVpLHZ+mLgaWKjOkahY2q9SrU+i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FABxaelOtJA2N/2dsb2JhbABZgwZRWIJppmkBAQEBAQeSboc9ARmBABZ0giYBAQQBAQEgETobAgEIDgwCJgICAh8GCxUQAgQBEogtAxENrW+eEA2GLxeBKoQrhW15gWI6gnWBSwEDl2aBdIE9i3GFbIM3bYFD X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208";a="323088128" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 19 May 2014 19:25:58 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4JJPvJd032211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 19:25:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 19 May 2014 14:25:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Occil , LTRU Working Group , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags Thread-Index: AQHPcFu5j1m6+8TePkCSdIp/gGJKJ5tIPtQA Date: Mon, 19 May 2014 19:25:56 +0000 Message-ID: References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DX8AhCrUw6FERv5ohtqJ8tqPhWA Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:26:00 -0000 SG0uICBJIHdhcyB0aGlua2luZzoNCg0KeyAiZW4iOiAiSGVsbG8iLCAiZnIiOiAiQm9uam91ciIg fQ0KDQpmb3IgdGhlIGNhc2Ugb2YgYWx0ZXJuYXRpdmVzLiAgVGhlIHdpcmUgc2l6ZSBiZXR3ZWVu DQoNClsgImVuIjogIkhlbGxvIiBdIGFuZCB7ICJlbiI6ICJIZWxsbyIgfQ0KDQppcyB6ZXJvOyBw ZXJoYXBzIHdlIGNvdWxkIGtpbGwgdHdvIGJpcmRzIHdpdGggb25lIHN0b25lPw0KDQpPbiA1LzE1 LzE0LCAxMDozNSBBTSwgIlBldGVyIE9jY2lsIiA8cG9jY2lsMTRAZ21haWwuY29tPiB3cm90ZToN Cg0KPkkgaGF2ZSB1cGRhdGVkIG15IHNwZWNpZmljYXRpb24gb24gbGFuZ3VhZ2UtdGFnZ2VkIHN0 cmluZ3MuDQo+DQo+aHR0cDovL3BldGVyb3VwYy5naXRodWIuaW8vQ0JPUi9sYW5ndGFncy5odG1s DQo+DQo+VGhlIHR3byB0aGluZ3MgbmV3IGFyZToNCj4NCj4tIFRoZSAiTk9URSIgc2VjdGlvbi4N Cj4tIFRoZSBzZW50ZW5jZSAiQm90aCB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgYXJiaXRyYXJ5 IHN0cmluZyBjYW4NCj5vcHRpb25hbGx5IGJlIGFubm90YXRlZCB3aXRoIENCT1IgdGFncy4iDQo+ DQo+LS1QZXRlciANCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj5hcHBzLWRpc2N1c3NAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K Pg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Mon May 19 12:30:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A5F1A03D7 for ; Mon, 19 May 2014 12:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 B3mu38Mw4cU8 for ; Mon, 19 May 2014 12:30:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484501A03DF for ; Mon, 19 May 2014 12:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=854; q=dns/txt; s=iport; t=1400527849; x=1401737449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hc9pQwxqYVflO1jW5q3gUKr7mTIMnEg1nKHnOV7RJiU=; b=hk4/xo0kCyyuNWrkAmtfUBM1BmUKOdQG2oO16dZZXkaQYBSm13874i46 OxFxHf106QvBQAazx1/Aich1rWTJb/6aBT8oNA87k612g/NXrMhT9h8Rf 2NXiHjfjKajT0cPdw4HOo9iix9S3b+Y9HJyPqUoqI97txP6uHGhBfXUJT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FALVbelOtJV2d/2dsb2JhbABZgwaBKYJppmkBAQEBAQEGmisBGYEAFnSCJgEBBCMRRRACAQgaAiYCAgIwFRACBAENBYhBrX2kTReBKoQrhW2CWzMHgnWBSwEDmVqTGoM3gjA X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208";a="326121577" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 19 May 2014 19:30:32 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4JJUWgo017048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 19:30:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 19 May 2014 14:30:32 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , IETF Apps Discuss Thread-Topic: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags Thread-Index: AQHPbWs8z177ZL7RbUCMkh9f9SonTps8fF2AgADarYCACu7yAA== Date: Mon, 19 May 2014 19:30:31 +0000 Message-ID: References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> <40416404-D7C6-4C53-8578-C65D83272661@vpnc.org> In-Reply-To: <40416404-D7C6-4C53-8578-C65D83272661@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <3295BC821F9D6A408FCCCD5FC183B5E6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I06Glkco1GQ5YCoqIIbqwkPnpp0 Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:30:50 -0000 U29ycnksIHJlYWRpbmcgdGhpcyBsaXN0IGJhY2t3YXJkLg0KDQpPbiA1LzEyLzE0LCA4OjMyIEFN LCAiUGF1bCBIb2ZmbWFuIiA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPiB3cm90ZToNCg0KPlRoaXMg Y291bGQgYmUgcmVwbGFjZWQgd2l0aCBhbiBleHRlbnNpYmxlIG1hcCAoZm9yIGluc3RhbmNlLCB3 aXRoIDANCj5tZWFuaW5nICJ0aGUgc3RyaW5nIiBhbmQgMSBtZWFuaW5nICJ0aGUgbGFuZ3VhZ2Ug dGFnIiksIGJ1dCB0aGVuIHRoZXJlDQo+d291bGQgbmVlZCB0byBiZSBhbiBJQU5BIHJlZ2lzdHJ5 IGZvciB0aGUgbWFwIHZhbHVlcy4gSW4gdGhlIG5hbWUgb2YNCj5zaW1wbGljaXR5LCBpdCBpcyBw cm9iYWJseSBiZXR0ZXIganVzdCB0byBsZXQgVGFnIDM4IGJlIGRlZmluZWQgYXMgaXQgaXMNCj5u b3csIGFuZCBpZiBvdGhlciBwcm9wZXJ0aWVzL2F0dHJpYnV0ZXMgY29tZSB1cCBsYXRlciwgbWF5 YmUgdGhlbiBjb21lIHVwDQo+d2l0aCBhIG1vcmUgY29tcGxpY2F0ZWQgc2NoZW1lLg0KDQpXaHkg d291bGQgdGhlcmUgbmVlZCB0byBiZSBhIG5ldyBJQU5BIHJlZ2lzdHJ5PyAgRG9lc24ndCBSRkMg NTY0NiBhbHJlYWR5DQpkbyB0aGF0Pw0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon May 19 13:39:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D411A03FA for ; Mon, 19 May 2014 13:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 n8xP_URF2QcJ for ; Mon, 19 May 2014 13:39:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE6C1A03F2 for ; Mon, 19 May 2014 13:39:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4JKdT8I000616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 May 2014 13:39:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Mon, 19 May 2014 13:39:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0CB646AF-D66A-47C6-BAC1-248585C1A09A@vpnc.org> References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> <40416404-D7C6-4C53-8578-C65D83272661@vpnc.org> To: Joe Hildebrand Hildebrand X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1LhLcJllTL68R1M6kDeDVN8VnQo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 20:39:51 -0000 On May 19, 2014, at 12:30 PM, Joe Hildebrand (jhildebr) = wrote: > Sorry, reading this list backward. >=20 > On 5/12/14, 8:32 AM, "Paul Hoffman" wrote: >=20 >> This could be replaced with an extensible map (for instance, with 0 >> meaning "the string" and 1 meaning "the language tag"), but then = there >> would need to be an IANA registry for the map values. In the name of >> simplicity, it is probably better just to let Tag 38 be defined as it = is >> now, and if other properties/attributes come up later, maybe then = come up >> with a more complicated scheme. >=20 > Why would there need to be a new IANA registry? Doesn't RFC 5646 = already > do that? I was talking about a different IANA registry. If there are going to be = many tags that could be applied to a string ("the language tag", "adult = language", ...), then there would need to be an IANA registry for that. = Which is why I'm not thrilled about either "this tag is over just that = string" or "this is one of many tags on that string". --Paul Hoffman= From nobody Mon May 19 13:54:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1F1A03F7; Sun, 11 May 2014 22:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 zXRh6eZziOHc; Sun, 11 May 2014 22:37:12 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9320C1A02C7; Sun, 11 May 2014 22:37:11 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Wjiv9-0004qd-Hg; Mon, 12 May 2014 01:37:03 -0400 Date: Mon, 12 May 2014 01:37:03 -0400 From: John Cowan To: Ira McDonald Message-ID: <20140512053703.GS17946@mercury.ccil.org> References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RlnenIXILjCSYgRlA_UiS1E35Fk X-Mailman-Approved-At: Mon, 19 May 2014 13:54:05 -0700 Cc: LTRU Working Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:37:14 -0000 Carsten Bormann scripsit: > The proposal is almost trivially obvious (pair a language tag with an > UTF-8 string in a two-element array) and looks right to me. But I'm > not an expert in Language Tags, and silly mistakes are being made by > non-experts all the time. Looks good to me. But I would recommend requiring the encoder to do the case folding rather than leaving it to the decoder. This is a form of early uniform normalization, which is generally a Good Thing if you can get it. The main mistake people make is trying to make the language tag fixed length, which you have already avoided. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org A: "Spiro conjectures Ex-Lax." Q: "What does Pat Nixon frost her cakes with?" --"Jeopardy" for generative semanticists From nobody Mon May 19 13:54:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460D01A0107; Wed, 14 May 2014 10:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 9ShF5de6UTEk; Wed, 14 May 2014 10:38:33 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA091A0104; Wed, 14 May 2014 10:38:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Wkd8L-0001iI-NV; Wed, 14 May 2014 13:38:25 -0400 Date: Wed, 14 May 2014 13:38:25 -0400 From: John Cowan To: Dave Cridland Message-ID: <20140514173825.GC20388@mercury.ccil.org> References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5GrNejJ1iSENbolN_9noKI2jlZk X-Mailman-Approved-At: Mon, 19 May 2014 13:54:05 -0700 Cc: Randy Presuhn , LTRU Working Group , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:38:35 -0000 Dave Cridland scripsit: > Many years ago, Mark Crispin and Chris Newman had a proposal for embedding > language tags in invalid UTF-8; I seem to recall they publicly renounced > their proposal rather dramatically in favour of a Unicode Consortium > proposal for embedding the language tags somewhere in Plane 14 - published > as RFC 2482. That's correct. There is a character meaning "Language tag follows" (U+E0001) and then there are tag versions of the 96 ASCII graphic characters (U+E0020 through U+E007E), though in fact only letters, digits, and hyphen would be useful. U+E007F means "No language tag". > The fact it was all initiated in order to support the pressing needs of > ACAP might give you some hints as to why it never really took off, but as a > counter-proposal to language tags in metadata, it might be worth > re-examining. It might, but don't get your hopes up. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev From nobody Mon May 19 13:54:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79111A0074; Wed, 14 May 2014 05:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 mW_ZbfKe-PNR; Wed, 14 May 2014 05:50:00 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 896BD1A008A; Wed, 14 May 2014 05:49:53 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4ECnj0C029837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 08:49:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4ECnj0C029837 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400071786; bh=9VAiUriXoZkqpzoxdeD2h1Y41xQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LmPnJ8FWE26Pj70mGI+LLJCJW3Qm946IVyx2EMGFJy6Z8V2QyX0rKz+ZFxbQ1Wd8h LvDjCKqWxgEephaoa4VsQhcJ6m1D+Zx5VyYHk8tsfWrBiiM9Frgdo9lXbqSlhA6S5Y XkiZzeeUx5H7j6x5xOij+PeK1Wl+loSsEcPmUrLE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4ECnj0C029837 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 14 May 2014 08:49:30 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4ECnT45030242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 08:49:29 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 14 May 2014 08:49:29 -0400 From: "Black, David" To: Mark Nottingham Date: Wed, 14 May 2014 08:49:27 -0400 Thread-Topic: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 Thread-Index: Ac9vF1SUMi/BYiRwSzaTOc+oksQgQAAWvYfQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55B645@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QubJ51eIRfdgAK1MUx7TOJH3Plk X-Mailman-Approved-At: Mon, 19 May 2014 13:54:26 -0700 Cc: "ops-dir@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:50:04 -0000 Mark, That works for me; thank you for following through on this. Thanks, --David > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Tuesday, May 13, 2014 9:53 PM > To: Black, David > Cc: apps-discuss@ietf.org > Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 >=20 > I got private feedback from others that they were OK with this too, so I'= ve > added: >=20 > """ > The latter approach is not preferred and ought only be used in exceptiona= l > circumstances. > """ >=20 > ("ought" instead of "should" to avoid confusion over 2119 terms). >=20 > Cheers, >=20 >=20 >=20 > On 8 May 2014, at 1:55 pm, Black, David wrote: >=20 > >> What target audience are you thinking of? Anyone who has a passing > familiarity > >> with the IETF must realise that modifying a Best Current Practice isn'= t > >> something you can do unilaterally? > > > > I'm thinking about people who aren't active in the IETF, and in particu= lar > > don't pay a lot of attention to our processes (heck, it was years after= I > > started coming to IETF meetings that I finally understood what a BCP is= ), > > but do look at our documents to figure out what to do before getting ar= ound > > to bringing their "clever" new ideas to us rather later than we might l= ike > > to have initially seen them in a perfect world. > > > >> I'm struggling to come up with appropriate text here. Do we really nee= d to > >> caution people that the process needs to be followed, and that might b= e > >> difficult if you want to do something controversial? > >> > >> E.g. we could say that modifying BCP115 is "unusual" - but considering= that > >> there's a modification of it underway right now, for the second time i= n > eight > >> years, that's not strictly true. > > > > Ok ... here's an suggestion that doesn't use a 2119 keyword: > > > > OLD > > A specification that defines substructure within a URI scheme MUST do > > so in the defining document for that URI scheme, or by modifying > > [RFC4395]. > > NEW > > A specification that defines substructure within a URI scheme MUST do > > so in the defining document for that URI scheme, or by modifying > > [RFC4395]. The latter approach is not preferred and should only be > > used in exceptional circumstances. > > > > IMHO, twice in eight years is consistent with "exceptional circumstance= s." > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Mark Nottingham [mailto:mnot@mnot.net] > >> Sent: Wednesday, May 07, 2014 9:58 PM > >> To: Black, David > >> Cc: apps-discuss@ietf.org > >> Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-= 04 > >> > >> > >> On 7 May 2014, at 12:30 pm, Black, David wrote: > >> > >>> For [2], while I'm sure that you're correct that any unwise attempt t= o > >> modify that BCP/RFC would be caught, IMHO, it would be helpful to add = some > >> text to warn the unwise earlier, before they invest any significant > >> time/effort in pursuing that sort of modification. I don't particular= ly > care > >> whether an RFC 2119 keyword is used, but I would like to see some sort= of > clue > >> offered ;-). > >> > >> I'm struggling to come up with appropriate text here. Do we really nee= d to > >> caution people that the process needs to be followed, and that might b= e > >> difficult if you want to do something controversial? > >> > >> E.g. we could say that modifying BCP115 is "unusual" - but considering= that > >> there's a modification of it underway right now, for the second time i= n > eight > >> years, that's not strictly true. > >> > >> What target audience are you thinking of? Anyone who has a passing > familiarity > >> with the IETF must realise that modifying a Best Current Practice isn'= t > >> something you can do unilaterally? > >> > >> Cheers, > >> > >> -- > >> Mark Nottingham http://www.mnot.net/ > >> > >> > >> > > >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From nobody Mon May 19 13:54:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08AB1A00F0; Thu, 15 May 2014 20:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 qrw9tfSSXZ4C; Thu, 15 May 2014 20:56:22 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8288C1A00CF; Thu, 15 May 2014 20:56:22 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4G3uD5w014674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 23:56:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s4G3uD5w014674 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400212574; bh=erfboxjMNECCrveznfHFCOdzNHU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=eg2lQk5gZxYP1MyEAJnbc+BxF3oAMShcPShiOkDLKtnTyc8voEbrwqnYKr2jZoDDV Lw0SrYGjA/t0Kn/KFfVca21KKuwtl+7vU+Th8a6xX9S6i+O/kKczEEIvF6ViEDCyWD vxT0e4e/U8o/5FB3IkbkCxqRkGn+muYX5RYuSm2k= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s4G3uD5w014674 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 15 May 2014 23:56:01 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4G3u0SR012141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 23:56:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Thu, 15 May 2014 23:56:00 -0400 From: "Black, David" To: Mark Nottingham Date: Thu, 15 May 2014 23:55:57 -0400 Thread-Topic: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 Thread-Index: Ac9wo8U7BAlG80GsRhymWMiLVo50MAAFZKjg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55BA0C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076BECFE9B@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C438BD2@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C55B645@MX15A.corp.emc.com> <10DD33E7-440B-41AC-9E7F-BC62E5C79510@mnot.net> In-Reply-To: <10DD33E7-440B-41AC-9E7F-BC62E5C79510@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q_RKbdOJTsA19JDBI_VT5mPuzlg X-Mailman-Approved-At: Mon, 19 May 2014 13:54:28 -0700 Cc: "ops-dir@ietf.org" , "Black, David" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 03:56:25 -0000 Hi Mark, The separation into two sentences is an improvement. IMHO, an additional note about inadvisability of modifying BCP115 is still helpful. OTOH, I'll defer on whether it's necessary to the ADs involved in approving the draft, as I had originally flagged this as a minor editorial item and think the draft is ok with or without the additional note. Thanks, --David > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Thursday, May 15, 2014 9:11 PM > To: Black, David > Cc: apps-discuss@ietf.org; ops-dir@ietf.org > Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-04 >=20 > Hi David, >=20 > Discussing this with the IESG, I've currently revised this to: >=20 > """ > A specification that defines substructure within a specific URI scheme MU= ST do > so in the defining document for that URI scheme. A specification that def= ines > substructure for URI schemes overall MUST do so by modifying {{BCP115}}. > """ >=20 > Do you think a note about the inadvisability of doing a BCP115 modificati= on is > still necessary, or does the separation here help? >=20 > Thanks, >=20 >=20 > On 14 May 2014, at 10:49 pm, Black, David wrote: >=20 > > Mark, > > > > That works for me; thank you for following through on this. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Mark Nottingham [mailto:mnot@mnot.net] > >> Sent: Tuesday, May 13, 2014 9:53 PM > >> To: Black, David > >> Cc: apps-discuss@ietf.org > >> Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-lawn-= 04 > >> > >> I got private feedback from others that they were OK with this too, so= I've > >> added: > >> > >> """ > >> The latter approach is not preferred and ought only be used in excepti= onal > >> circumstances. > >> """ > >> > >> ("ought" instead of "should" to avoid confusion over 2119 terms). > >> > >> Cheers, > >> > >> > >> > >> On 8 May 2014, at 1:55 pm, Black, David wrote: > >> > >>>> What target audience are you thinking of? Anyone who has a passing > >> familiarity > >>>> with the IETF must realise that modifying a Best Current Practice is= n't > >>>> something you can do unilaterally? > >>> > >>> I'm thinking about people who aren't active in the IETF, and in parti= cular > >>> don't pay a lot of attention to our processes (heck, it was years aft= er I > >>> started coming to IETF meetings that I finally understood what a BCP = is), > >>> but do look at our documents to figure out what to do before getting > around > >>> to bringing their "clever" new ideas to us rather later than we might= like > >>> to have initially seen them in a perfect world. > >>> > >>>> I'm struggling to come up with appropriate text here. Do we really n= eed > to > >>>> caution people that the process needs to be followed, and that might= be > >>>> difficult if you want to do something controversial? > >>>> > >>>> E.g. we could say that modifying BCP115 is "unusual" - but consideri= ng > that > >>>> there's a modification of it underway right now, for the second time= in > >> eight > >>>> years, that's not strictly true. > >>> > >>> Ok ... here's an suggestion that doesn't use a 2119 keyword: > >>> > >>> OLD > >>> A specification that defines substructure within a URI scheme MUST d= o > >>> so in the defining document for that URI scheme, or by modifying > >>> [RFC4395]. > >>> NEW > >>> A specification that defines substructure within a URI scheme MUST d= o > >>> so in the defining document for that URI scheme, or by modifying > >>> [RFC4395]. The latter approach is not preferred and should only be > >>> used in exceptional circumstances. > >>> > >>> IMHO, twice in eight years is consistent with "exceptional circumstan= ces." > >>> > >>> Thanks, > >>> --David > >>> > >>>> -----Original Message----- > >>>> From: Mark Nottingham [mailto:mnot@mnot.net] > >>>> Sent: Wednesday, May 07, 2014 9:58 PM > >>>> To: Black, David > >>>> Cc: apps-discuss@ietf.org > >>>> Subject: Re: OPS-Dir review of draft-ietf-appsawg-uri-get-off-my-law= n-04 > >>>> > >>>> > >>>> On 7 May 2014, at 12:30 pm, Black, David wrote= : > >>>> > >>>>> For [2], while I'm sure that you're correct that any unwise attempt= to > >>>> modify that BCP/RFC would be caught, IMHO, it would be helpful to ad= d > some > >>>> text to warn the unwise earlier, before they invest any significant > >>>> time/effort in pursuing that sort of modification. I don't particul= arly > >> care > >>>> whether an RFC 2119 keyword is used, but I would like to see some so= rt of > >> clue > >>>> offered ;-). > >>>> > >>>> I'm struggling to come up with appropriate text here. Do we really n= eed > to > >>>> caution people that the process needs to be followed, and that might= be > >>>> difficult if you want to do something controversial? > >>>> > >>>> E.g. we could say that modifying BCP115 is "unusual" - but consideri= ng > that > >>>> there's a modification of it underway right now, for the second time= in > >> eight > >>>> years, that's not strictly true. > >>>> > >>>> What target audience are you thinking of? Anyone who has a passing > >> familiarity > >>>> with the IETF must realise that modifying a Best Current Practice is= n't > >>>> something you can do unilaterally? > >>>> > >>>> Cheers, > >>>> > >>>> -- > >>>> Mark Nottingham http://www.mnot.net/ > >>>> > >>>> > >>>> > >>> > >> > >> -- > >> Mark Nottingham http://www.mnot.net/ > >> > >> > >> > > >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From nobody Mon May 19 13:55:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC321A017A; Wed, 14 May 2014 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 z37ja0vtVwyo; Wed, 14 May 2014 10:34:50 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 59F211A0102; Wed, 14 May 2014 10:34:50 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id i8so3352074qcq.18 for ; Wed, 14 May 2014 10:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0K0xKkUOWSJiJSyRR0KoRAeSiGommR+4demm553do4s=; b=uVoGBsAN0BVG2Z59awKSpwvvIlwbYPI8XCTYHJbowGD5h+l1BBYpLpYeeIQHJjM7bi /T3HnKqJwbZDJEOEwIUltwfBocFnE9jvxRyNUVW4jx729x9wNQgvW44VGEM7XKry+U5S e4AxUn8pO7f4L8po/IdrZ0pbC3dZo+U2IAMrWsSv/onw+6ozrj7+zZVS2iiKDQSEdXKp yBkV1FwJ1zD2zKXh9mJjT8qI+9LhYDTViAsltU+AK2PPwGTxg02a9EHYVfJkp8bcPbW+ /yXqm1v3zYrCim6j1F72GEH2bPBGf/kLwFqcP049UR7OobJFj47sgvRtL9JSL+ZwunAK iq9g== X-Received: by 10.224.112.74 with SMTP id v10mr5665198qap.28.1400088883532; Wed, 14 May 2014 10:34:43 -0700 (PDT) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.229.151.81 with HTTP; Wed, 14 May 2014 10:34:23 -0700 (PDT) In-Reply-To: References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Wed, 14 May 2014 10:34:23 -0700 X-Google-Sender-Auth: HCN-uV9k4syZ-T-hyyO971VtaEY Message-ID: To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c3b23a8e996204f95f98a8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xtpcK-r57lU2oY1toqgAYKHyaK4 X-Mailman-Approved-At: Mon, 19 May 2014 13:54:59 -0700 Cc: Randy Presuhn , LTRU Working Group , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Ltru] Fwd: Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:34:52 -0000 --001a11c3b23a8e996204f95f98a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > as a counter-proposal to language tags in metadata, it might be worth re-examining. The tag characters in Unicode are deprecated, and should not be used. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* On 14 May 2014 00:18, Dave Cridland wrote: > On 14 May 2014 04:33, Peter Occil wrote: > >> I'm not aware of any use case where having multiple language tags for th= e >> same plain-text string is useful. For instance, RDF supports only one >> language tag for each string. And HTML5 doesn't support multiple langua= ges >> in the Content-Language header field or META tag; instead, for multiling= ual >> documents, it relies on markup to set the language used for each section= . >> But plain-text strings don't admit of HTML-like markup without more. >> >> Moreover, having multiple language tags for plain text leads to the >> additional problem of determining which parts of the text each language = tag >> applies to, which is not so easy in the case of your three-language exam= ple. >> > > Many years ago, Mark Crispin and Chris Newman had a proposal for embeddin= g > language tags in invalid UTF-8; I seem to recall they publicly renounced > their proposal rather dramatically in favour of a Unicode Consortium > proposal for embedding the language tags somewhere in Plane 14 - publishe= d > as RFC 2482. > > The fact it was all initiated in order to support the pressing needs of > ACAP might give you some hints as to why it never really took off, but as= a > counter-proposal to language tags in metadata, it might be worth > re-examining. > > Dave. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > --001a11c3b23a8e996204f95f98a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0as a counter-proposal to language tags= in metadata, it might be worth re-examining.

The tag characters in Unicode are deprecated, and= should not be used.


<= div style=3D"background-color:transparent;margin-top:0px;margin-left:0px;ma= rgin-bottom:0px;margin-right:0px">
=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94


On 14 May 2014 00:18, Dave Cridland <da= ve@cridland.net> wrote:
On 14 May 2014 04:33, Peter Occil <poccil14@gmail.com>= wrote:
I'm not aware of any use case where having multiple language tags for t= he same plain-text string is useful. =C2=A0For instance, RDF supports only = one language tag for each string. =C2=A0And HTML5 doesn't support multi= ple languages in the Content-Language header field or META tag; instead, fo= r multilingual documents, it relies on markup to set the language used for = each section. But plain-text strings don't admit of HTML-like markup wi= thout more.

Moreover, having multiple language tags for plain text leads to the additio= nal problem of determining which parts of the text each language tag applie= s to, which is not so easy in the case of your three-language example.

Many years ago, Mark Crispin and Chr= is Newman had a proposal for embedding language tags in invalid UTF-8; I se= em to recall they publicly renounced their proposal rather dramatically in = favour of a Unicode Consortium proposal for embedding the language tags som= ewhere in Plane 14 - published as RFC 2482.

The fact it was all initiated in order to support the p= ressing needs of ACAP might give you some hints as to why it never really t= ook off, but as a counter-proposal to language tags in metadata, it might b= e worth re-examining.

Dave.=C2=A0

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru


--001a11c3b23a8e996204f95f98a8-- From nobody Mon May 19 13:55:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829641A015F for ; Fri, 16 May 2014 12:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 GM_SSjyn0vDX for ; Fri, 16 May 2014 12:40:58 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03E51A0222 for ; Fri, 16 May 2014 12:40:57 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so5316894wgh.2 for ; Fri, 16 May 2014 12:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ZvEnPCxgtLZ6csU10fl7+0ueKbCW/KNBga+GDUscPs0=; b=csGeBqFHvadhI12wqokhcugTby2hFWDiyuTSH1kgV+upPspq58PCoSbCI4+mYYG48f V17wYZR7d89Tk1xPjSHLe/m391eWFbtsqlA5IRPPlagl13ftZ1DxQEB+xIHhx1M819iX MYIneYRda/siqbG5CZH/2thAxfmxamGxf7zb7Np2/hU7qiuCkS1T/GdnO/H0DUCT2PfM Oywpx8Ki1gPgO1LdD/NzY2T0sdpWLaO3uJE6Cw3GQR0zwn9llQoW2gWGKqsNLMbLFszT PP9kxgYznr4V+MrW9S5ybBw3B/TYaTv3gJ4Nw0pErU5ACPTXb+s4p6rZedtjdZnbkuzw zwdw== MIME-Version: 1.0 X-Received: by 10.180.91.1 with SMTP id ca1mr15404068wib.32.1400269249405; Fri, 16 May 2014 12:40:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Fri, 16 May 2014 12:40:49 -0700 (PDT) Date: Fri, 16 May 2014 15:40:49 -0400 X-Google-Sender-Auth: Av8BR3VNfYp6cSfi8qmUhoFzfsY Message-ID: From: Phillip Hallam-Baker To: General discussion of application-layer protocols Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-VuaNwbAi1kpkGfQu6sYZ1UhX1M X-Mailman-Approved-At: Mon, 19 May 2014 13:55:46 -0700 Subject: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 19:40:59 -0000 So I made a post to the IETF list yesterday in which I gave a high level view of the Internet 2020 project and the three goals of Security, Access and Autonomy. The goal of Autonomy being to make the Internet user independent of institutional control points like ICANN and the corporations trying to establish themselves as control points. ICANN is of course the one we have had concerns about for the longest time and the autonomy problem is that I don't buy a DNS name, I can only rent it. And that means that names that are DNS bound can always be reassigned in the future. Which is one of the reasons why HTTP urls are unsatisfactory. Larry Masinter has of course raised this sort of concern before and proposed dated URLs. But this morning a different approach to the problem occurred to me: Lets take a URL at a web site and imagine I download a page on 1st Jan 2010: http://www.cnn.com/whatever.html Now what if I wanted to connect up today to the same party that I connected to last time. This is not the same as the URN or the dated URL problem. I want to connect up to the same entity regardless of whom ICANN happen to sell the domain name to next. How about one of the following: http://www.cnn.com.2010/whatever.html http://www.cnn.com.1.2010/whatever.html http://www.cnn.com.1.1.2010/whatever.html DNS labels are not allowed to be all numbers but the DNS protocol works for them. In fact they seem to work with my existing software which was not a design goal but would be cool. Now resolving such names would of course require a new infrastructure, quite possibly a subscription infrastructure that would track the changing ownership of the names over time. And this infrastructure would probably involve Certificate Transparency like services and DNSSEC. But we could use this to provide persistence for Web content and for Web services which would be incredibly cool. We can also apply the same idea to email addresses: phill@hallambaker.com could be anyone. phill@hallambaker.com.16.5.2014 is uniquely my account. From nobody Mon May 19 13:56:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0041A03CA for ; Sun, 11 May 2014 19:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 ivJEph5c9hgG for ; Sun, 11 May 2014 19:20:11 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 540561A03C9 for ; Sun, 11 May 2014 19:20:11 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so6924506qgz.16 for ; Sun, 11 May 2014 19:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=DfOPAbN9thjofFtkPvj7AVyVyLiNSjxcsEMp1pnKujA=; b=Dw2aRE7+xjIL2AlATz/JGiPxyr/Njxwp58p66Rd+9fo+/GQtSm+8E49lBoj7sPceZH p4MHizhvwW2R+kjoVqImKSC5Lf7UnPZwWXUf2QJc+/t8DWJMCr87eskpSebuzT1OIrO9 Yp/JoowDIL7vYAegC4QPsPp1pL8+R2QkIGITU2sWp0JoFHYPhf6N2KpTw7j4QYiRlP2D xM5mx5jC2XYC6GfSjeBCoQe2CnferYpnzhF22LZmm7G5MFBzIv0arTXFWq2yExfQ3uhq roy1DxT/C+bSe2E9UBFf3yKC5lxlZxLiAJl1nOXY6Aa9N8xLeaUcGMI9Cvgdy2h9xvGO /ELA== X-Received: by 10.140.31.196 with SMTP id f62mr31887935qgf.59.1399861205385; Sun, 11 May 2014 19:20:05 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id r14sm19312605qay.36.2014.05.11.19.20.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 May 2014 19:20:04 -0700 (PDT) Message-ID: <1058FF09CEF745CC875635CB365BCECC@PeterPC> From: "Peter Occil" To: =?utf-8?Q?=22Martin_J._D=C3=BCrst=22?= References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> In-Reply-To: <53702419.70403@it.aoyama.ac.jp> Date: Sun, 11 May 2014 22:20:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140511-3, 05/11/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CelUD8Am-BWg2WDLsPvz7pi0XRQ X-Mailman-Approved-At: Mon, 19 May 2014 13:55:56 -0700 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 02:20:12 -0000 If I understand what you mean by "not scaling", I think it's because my specification doesn't expressly allow using CBOR tags on the language tag string or the string being tagged with a language. If this interpretation is right, I think this can be solved by adding the following: "The language tag and the arbitrary string can have any number of CBOR tags on it." --Peter -----Original Message----- From: "Martin J. Dürst" Sent: Sunday, May 11, 2014 9:30 PM To: Carsten Bormann ; IETF Apps Discuss Cc: Peter Occil Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags Just took a short look. What I noticed is that this works fine on its own, but as soon as this is combined with other properties/attributes of strings, it may not scale. Regards, Martin. From nobody Mon May 19 14:06:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6791A0413 for ; Mon, 19 May 2014 14:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 wgj5PujjANvY for ; Mon, 19 May 2014 14:06:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF28B1A0404 for ; Mon, 19 May 2014 14:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1400533588; x=1401743188; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vbCNPi2fBmgxstFyLhYs1ag0sbqelT4bB8pVzzFJ4/c=; b=B7uFWYZfyuVHgRQO8fVf/KEsGiZQWG57ikycO/vfw1JmjKFh35TN4dDA ZHGVImlxZ7ZgDJKpB/2IG4+IMXw1RkMVI8bmnAe+gtxlR5Q8Y/dgUWVA/ GPRj+Wjgs/uFiQFl2Paa1CY4OtcLr4+4jDwd23nc33bt54rtUkqveckcK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFAONwelOtJV2Q/2dsb2JhbABZgwZRWIJppmoBAQEBAQEGmikBGYEEFnSCJgEBBCMRRRACAQgaAiYCAgIwFRACBA4FiEENrWOkXBeBKoQrhWyCWzMHgnWBSwSZWpMagzeCMA X-IronPort-AV: E=Sophos;i="4.98,869,1392163200"; d="scan'208";a="326148471" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 19 May 2014 21:06:27 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4JL6Rrv024346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 21:06:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 19 May 2014 16:06:26 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman Thread-Topic: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags Thread-Index: AQHPbWs8z177ZL7RbUCMkh9f9SonTps8fF2AgADarYCACu7yAIAAd9oA//+i9AA= Date: Mon, 19 May 2014 21:06:26 +0000 Message-ID: References: <9C6F4F37-39C8-498C-8FDA-C894C3A7BF29@tzi.org> <53702419.70403@it.aoyama.ac.jp> <40416404-D7C6-4C53-8578-C65D83272661@vpnc.org> <0CB646AF-D66A-47C6-BAC1-248585C1A09A@vpnc.org> In-Reply-To: <0CB646AF-D66A-47C6-BAC1-248585C1A09A@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <1CB9A2BB46ED42409150F36A37CDF931@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/s9PeQg8OuzghZ8ROhARNfh32KZE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:06:29 -0000 T24gNS8xOS8xNCwgMjozOSBQTSwgIlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkB2cG5jLm9y Zz4gd3JvdGU6DQoNCj5JIHdhcyB0YWxraW5nIGFib3V0IGEgZGlmZmVyZW50IElBTkEgcmVnaXN0 cnkuIElmIHRoZXJlIGFyZSBnb2luZyB0byBiZQ0KPm1hbnkgdGFncyB0aGF0IGNvdWxkIGJlIGFw cGxpZWQgdG8gYSBzdHJpbmcgKCJ0aGUgbGFuZ3VhZ2UgdGFnIiwgImFkdWx0DQo+bGFuZ3VhZ2Ui LCAuLi4pLCB0aGVuIHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgYW4gSUFOQSByZWdpc3RyeSBmb3Ig dGhhdC4NCj5XaGljaCBpcyB3aHkgSSdtIG5vdCB0aHJpbGxlZCBhYm91dCBlaXRoZXIgInRoaXMg dGFnIGlzIG92ZXIganVzdCB0aGF0DQo+c3RyaW5nIiBvciAidGhpcyBpcyBvbmUgb2YgbWFueSB0 YWdzIG9uIHRoYXQgc3RyaW5nIi4NCg0KVGhlcmUncyBubyBhbWJpZ3VpdHkgdGhhdCBJIGtub3cg aWYgaW4geG1sOmxhbmc6DQpodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMteG1sLyNzZWMtbGFuZy10 YWcNCg0KQWxsIEkgd2FudCBpcyByb3VnaGx5IHRoYXQgcGx1cyB0aGUgYml0IHRoYXQgd2UgbGVh cm5lZCBhYm91dCBzb21ldGltZXMNCm5lZWRpbmcgYWx0ZXJuYXRpdmVzLCBtaW51cyB0aGUgYml0 IHdoZXJlIHlvdSBoYXZlIHRvIGtlZXAgY29udGV4dCBvZg0KZW5jbG9zaW5nIGVsZW1lbnRzLg0K DQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon May 19 15:35:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202621A0413; Mon, 19 May 2014 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 Hpn_f1eSWxjj; Mon, 19 May 2014 15:35:13 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937761A038B; Mon, 19 May 2014 15:35:13 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so9846703qgd.33 for ; Mon, 19 May 2014 15:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=I1dJiZJQZGk4MlefvEoOG4+ge/Olxk1hOgbyAkUznxM=; b=xoBzU2n0oC2zApSIO4mf0h6uQKA0oMB6bdDvt2DjjxAhifUhzUvXxKhHNBMToZGO+z CudAw6QP+MbpUITG6F9p8kRL02fgW0oLZc+hgw21d82o724CSxvSf1Gz/JIt7xHebkE0 GHBB6TOBEazCGxrfst8CBJSYGWJF+0XNxzAA8o1awfDQIIHnW2YeKfzHSlEkthVtG5Al LkI9Fnv+UUsz63VlrH9aYHGJ7wf1o1EPJgwRbEbW8sTGBmDDl3ODcvdtb9PEPCmFFc+E Lshod0+3hT9hr4VxM6gDICqRuE1N5NDQNkMtP+8Z99IbO7N2FpWN0UFRiG7hS1ECEnMO ag9A== X-Received: by 10.224.55.83 with SMTP id t19mr52510487qag.42.1400538912891; Mon, 19 May 2014 15:35:12 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id w4sm19886151qat.5.2014.05.19.15.35.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 15:35:12 -0700 (PDT) Message-ID: <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> From: "Peter Occil" To: "Joe Hildebrand \(jhildebr\)" , "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: Date: Mon, 19 May 2014 18:35:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140519-1, 05/19/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PT1Q1qXwOGld2y8t_VuPtCabS50 Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:35:16 -0000 As I recall, that is similar to the approach taken by JSON-LD when mapping the same text in different languages (there it's called a "language map"). However, one problem that I see is that this requires case-insensitive comparison of keys: if a decoder encounters a language map with two keys that differ only in case (for example, "en" and "EN"), which one should it use? The one defined earlier or later? While there are already CBOR tags in the registry that depend on such ordering (such as string references and shared references), I believe that defining further tags that depend on this kind of ordering of values in the CBOR stream should be avoided as much as possible. Another approach may be to forbid such an ambiguous language map or ignore ambiguous keys, but I don't know which is the best approach. Issues like those should be dealt with in another tag proposal; I don't mind if tag 38 (this proposal) is changed to use language maps, but additional discussion would have to be necessary. Until then, the simple language-tagged string is enough. --Peter -----Original Message----- From: Joe Hildebrand (jhildebr) Sent: Monday, May 19, 2014 3:25 PM To: Peter Occil ; LTRU Working Group ; apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags Hm. I was thinking: { "en": "Hello", "fr": "Bonjour" } for the case of alternatives. The wire size between [ "en": "Hello" ] and { "en": "Hello" } is zero; perhaps we could kill two birds with one stone? On 5/15/14, 10:35 AM, "Peter Occil" wrote: >I have updated my specification on language-tagged strings. > >http://peteroupc.github.io/CBOR/langtags.html > >The two things new are: > >- The "NOTE" section. >- The sentence "Both the language tag and the arbitrary string can >optionally be annotated with CBOR tags." > >--Peter > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss > -- Joe Hildebrand From nobody Mon May 19 15:47:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18B1A0435; Mon, 19 May 2014 15:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 aK13OYzUsN0L; Mon, 19 May 2014 15:47:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBF81A015F; Mon, 19 May 2014 15:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4JMlT4L002515; Tue, 20 May 2014 00:47:29 +0200 (CEST) Received: from [192.168.217.145] (p54893C54.dip0.t-ipconnect.de [84.137.60.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2F94513E9; Tue, 20 May 2014 00:47:28 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> Date: Tue, 20 May 2014 00:47:26 +0200 X-Mao-Original-Outgoing-Id: 422232446.806613-e6b2fbfc81d6ab6dcf6422d966010862 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> To: Peter Occil X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hVA_pOF-s0crQaCxv2HwQZwJ-gg Cc: LTRU Working Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:47:40 -0000 On 20 May 2014, at 00:35, Peter Occil wrote: > However, one problem that I see is that this requires case-insensitive = comparison of > keys: if a decoder encounters a language map with two keys that differ = only in case (for example, "en" and "EN"), which one should it use? =20 We generally handle problematic cases like this well by simply = disallowing their use by the sender. It then matters less how a receiver handles incoming improper streams. Maybe this is another reason to require case-mapping to lower-case. More aggressively, maybe combine this with at least a =93SHOULD=94 for = canonical form as in section 4.5 of RFC 5646? Gr=FC=DFe, Carsten From nobody Mon May 19 15:57:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA01A0444; Mon, 19 May 2014 15:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.604 X-Spam-Level: ** X-Spam-Status: No, score=2.604 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=no 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 1jjrNvWnwTnD; Mon, 19 May 2014 15:57:49 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FCA1A0442; Mon, 19 May 2014 15:57:49 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so10127799qgd.1 for ; Mon, 19 May 2014 15:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=5zt3FXm9NcSG6PWVE1xPOzocM0h81ofrUDyJKPh7WDU=; b=oDHHkrdK9zOl/AjZjQxfYUnfWISkvY7n9dQWzUK0yRAJ/EjFOzm2u7OP2FZB4oUSv2 +b+ZR9rmbgClZpT8gOaUSFDWr7RHXhPJmyFgjawEnXRmB7jMqBeVSwPV9FzZbf3/RTC1 H9THiOGO2iCeEarwgxS7qhxbsT1TTr6Dg+xINTs/t2nOGFLWfisttUPEbNlOaBijAj3C r3yCZ2FOHQAQDCXUhu+U/hgOy6EC66mcDT8ALYDb9nnMdk0A5WJX6LJnMXJ/Onyq08fH T0gWYPab2LG0TAL12sZi4b3PPRr6O9HlL/5n/0dD+CV3Z32DcguZV1DdcNrj4sbAr81w HMxg== X-Received: by 10.224.29.76 with SMTP id p12mr10252133qac.84.1400540268729; Mon, 19 May 2014 15:57:48 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id x1sm29709121qal.36.2014.05.19.15.57.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 15:57:48 -0700 (PDT) Message-ID: <4E728C7DF5A84CF0A21189FBF29381C4@PeterPC> From: "Peter Occil" To: "Carsten Bormann" References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> In-Reply-To: Date: Mon, 19 May 2014 18:57:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140519-1, 05/19/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9niruQohTOUkQWllyfJp0EL2PBg Cc: LTRU Working Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:57:51 -0000 A good idea. But my point still stands that a language map should be in a different tag proposal, if possible. There may still be other issues with changing this proposal from language-tagged strings to language-tagged maps that haven't been dealt with yet, but again, I don't mind if tag 38 eventually does take that course. --Peter -----Original Message----- From: Carsten Bormann Sent: Monday, May 19, 2014 6:47 PM To: Peter Occil Cc: Joe Hildebrand (jhildebr) ; LTRU Working Group ; apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags On 20 May 2014, at 00:35, Peter Occil wrote: > However, one problem that I see is that this requires case-insensitive > comparison of > keys: if a decoder encounters a language map with two keys that differ > only in case (for example, "en" and "EN"), which one should it use? We generally handle problematic cases like this well by simply disallowing their use by the sender. It then matters less how a receiver handles incoming improper streams. Maybe this is another reason to require case-mapping to lower-case. More aggressively, maybe combine this with at least a SHOULD for canonical form as in section 4.5 of RFC 5646? Gre, Carsten From nobody Tue May 20 01:08:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A39B1A030E for ; Tue, 20 May 2014 01:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 66PaV8acpIoU for ; Tue, 20 May 2014 01:08:39 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8F1A0309 for ; Tue, 20 May 2014 01:08:37 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s4K88JKd024363; Tue, 20 May 2014 09:08:24 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4K88IYI027609; Tue, 20 May 2014 09:08:18 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4K88IbT017235; Tue, 20 May 2014 09:08:18 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s4K88IA1017231; Tue, 20 May 2014 09:08:18 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Phillip Hallam-Baker References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 20 May 2014 09:08:18 +0100 In-Reply-To: (Phillip Hallam-Baker's message of "Fri\, 16 May 2014 15\:40\:49 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2nVpdz_fG9KUC4bigoBoiKDVspA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 08:08:42 -0000 Phillip Hallam-Baker writes: > . . . > http://www.cnn.com.2010/whatever.html > http://www.cnn.com.1.2010/whatever.html > http://www.cnn.com.1.1.2010/whatever.html This reminds me of one of the rather odd failings of the Internet infrastructure: There is as far as I know no where to go to find the answer to questions of the form implicit in the above proposal, that is "Who was the owner of the cnn.com domain on 2010_01_01?". We really ought to get a requirement of public archiving of domain name 'ownership' records into the contractual requirements on registrars. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Tue May 20 15:20:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9401A0393 for ; Tue, 20 May 2014 15:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 QK0olnVG9kGV for ; Tue, 20 May 2014 15:20:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF851A02B7 for ; Tue, 20 May 2014 15:20:28 -0700 (PDT) Received: (qmail 98728 invoked from network); 20 May 2014 22:20:26 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 May 2014 22:20:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2fd0.537bd52a.k1405; i=johnl@user.iecc.com; bh=q1EB2IM66C9Tu0AhGRyY6zhmNUL7Ttd4xgl0wbdI4OE=; b=VBWi81BuX2QSKiwO06tvuhc9HS4Pkvhl/u2sm7HWJrcgl82i8SbWi2P0sHpFSmCuNisPH0G2fW+4NzGkGlpCfZGTs2ckf6fbrFFBARqV588n2KPTjKk40tDkmHmXVkzmt8WDI8OXHWqJZiHSjw/HU1FkNQt5fyc1+Czpi1R6cqnB+4rStrKDO/KgyiojGhIJk3KG5K1kKclfTfgDTpPX61mfVTx63E3ByqyiLGIz5nlQqNbqpjiKooKGJaitMuLj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2fd0.537bd52a.k1405; olt=johnl@user.iecc.com; bh=q1EB2IM66C9Tu0AhGRyY6zhmNUL7Ttd4xgl0wbdI4OE=; b=no2Iv4OyzbFnsHMfTFhbxMAgbdZjfJJxLhNClKgvVw0vXjnLAhmOsKgocb0L4PJKxIlG4HN5ickHuQNzI0NtPyWs1D4RtbbyXHBnArqEgCCCo/9Sjwz/3wQyGFSabmZYRIb5GDuwf344eahsUmZFDQzf1vsoDhq3LyCbvefqZXzicxLKauWdD3EKxgu5eiAveyooH9HL1ogUdwCas0ek3igKOh4E9NPAo70sNUInhwfz+4up8UCJ8CdzmVYP106x Date: 20 May 2014 22:20:04 -0000 Message-ID: <20140520222004.12239.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kh2EUlL7FSv5SLzItyC41va5x6w Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 22:20:29 -0000 >We really ought to get a requirement of public archiving of domain >name 'ownership' records into the contractual requirements on >registrars. . . We're the IETF. If you're looking for ICANN, I expect you know where to find them. R's, John From nobody Tue May 20 18:29:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825651A03FB; Tue, 20 May 2014 18:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8X-TxJFDe3wr; Tue, 20 May 2014 18:29:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D8E1A03F5; Tue, 20 May 2014 18:29:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521012936.31691.23030.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 18:29:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/68j1Z3mlieCpzr0Y_n_vRa9H-bc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 01:29:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : URI Design and Ownership Author : Mark Nottingham Filename : draft-ietf-appsawg-uri-get-off-my-lawn-05.txt Pages : 8 Date : 2014-05-20 Abstract: RFC3986 Section 1.1.1 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 20 20:31:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFA81A0454; Tue, 20 May 2014 20:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 y95UfoRrwmEs; Tue, 20 May 2014 20:31:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8D1A0459; Tue, 20 May 2014 20:31:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521033103.15510.58644.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 20:31:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_AnGUaf89TZq7ffVWgQgOS6HiWc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 03:31:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-01.txt Pages : 6 Date : 2014-05-20 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 20 20:34:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6DA1A0459 for ; Tue, 20 May 2014 20:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 u3caYNE-zuAW for ; Tue, 20 May 2014 20:34:12 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C741A0455 for ; Tue, 20 May 2014 20:34:12 -0700 (PDT) Received: (qmail 38346 invoked from network); 21 May 2014 03:34:10 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 May 2014 03:34:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=34dd.537c1eb2.k1405; i=johnl@user.iecc.com; bh=bD/c8IRukyIZYSiMukNWbJ2DNM0H4YGYmHdoN40vavY=; b=RhylwS5e+516qse/Ru68OYWb0jQz6en+mYyOtE42w1RK/088YFIZYrTcOEBb7xkthkDxGRSnnkbdmRwV+gPH4qVmcziq9bnjzd+jPfORFol9pQ7hdBLjwiyw3j0guMhwcx7wYEov+pC03iT+TJKqah4kQqhKSQ62DhM9G1KIRFkMKtqPPN2Hi219qvEoEgaWf4VR7xA1SKbeEhkjk9RFAM9nlgQTHVzeGzrn/JQkew/JzcNf1ukEHnHOHX2bpnZR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=34dd.537c1eb2.k1405; olt=johnl@user.iecc.com; bh=bD/c8IRukyIZYSiMukNWbJ2DNM0H4YGYmHdoN40vavY=; b=eVFH3A9LfSRMBQXjVGWboWDSouZ84gS4koB2FenMlE6U9m5knr54Tx1E5ZoWhZoczckvogrQ6etKkK+MZeu9fjd3tihlV/Abvxj5f5os4dAfyAUTgAhKJaVz6xd0EuBLFcS3lgt9mEgwhIB6g/e5qsqf4bB49yKol9V1YCKU/+vTa4R3NeixluOwSouEajtgGUNoV0PPsyE5QUhDiLxSCvArd0+VUuOEn47pq37+CV5ZupqFJ10E61cZB9H4kiFO Date: 21 May 2014 03:33:48 -0000 Message-ID: <20140521033348.13532.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8hXxz7pshcYzqo0GnaCbww0ioVo Subject: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 03:34:13 -0000 I finally updated the draft, based on the thorough Dave Crocker did in February: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ As far as I know, nothing in the draft is contentious. It still refers to RFC 4408 rather than 7208 because for some reason 7208 isn't in the xml2rfc library yet. Other than that I think it's done. R's, John From nobody Wed May 21 06:59:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276F41A068F for ; Wed, 21 May 2014 06:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 u4q_E4h7Q5bi for ; Wed, 21 May 2014 06:59:05 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045561A035E for ; Wed, 21 May 2014 06:59:04 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uy5so2204304obc.1 for ; Wed, 21 May 2014 06:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oCEMX5s/wbKw/QoTKU0v82UuJoQW12I9gC3gapIExx0=; b=YnfsA6c7u+Rf8pQmQmeR3+KKPVGEvzuJgBMY6z6sUUqLXhuzhQza43I5DgJ3fjuqn6 YPFa8Zz9XyqgGS+8v7k4t9tG8n2DRiggjhzKRlZE2cs2U8hu1me3HKMOx7gDaMYMX5QY 8J2Sus7mKY0WGk3y3hQ3DI4dHYQqqEuvCmWtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oCEMX5s/wbKw/QoTKU0v82UuJoQW12I9gC3gapIExx0=; b=WSWi+E56me1F6fMLCJkCPYtwdy9pZrNYd7jGhRr26y8jZoId0n2ojjySaimiYWzePj DPPLjqsSCDN3DXSXpL9/FIdr8oAzBWz/w1wr5DuKxz3R5JNK4jor/R3mMCJMT791curV pb6RapSL0u3TfZzXzk83PoRe3A8Bbx/0IV6e5XdxEy/yFyssWqm9BxqAHusuvm7KGs62 UJ2sdRlY6ZUNTAHFBic07rQZNCKsEN5n4cLOk08FdkO2dE5WwQvA6J6yDvnO1r8ShV7b G0T6hp0CCXVdYgMoXNp7BavKNnt+apMjaYFzwXpgwhiU0bZdNwtIDZCtaXdGbK8hpUiL b26A== X-Gm-Message-State: ALoCoQm4RIsRw0m/OMA3lwgM8I7qSoLk3Y5X9VPCuDkTBBPfmV8l0pjEAEXTK2kpHJwggmR7eCnj MIME-Version: 1.0 X-Received: by 10.182.153.33 with SMTP id vd1mr2991709obb.86.1400680743883; Wed, 21 May 2014 06:59:03 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Wed, 21 May 2014 06:59:03 -0700 (PDT) In-Reply-To: <20140521033348.13532.qmail@joyce.lan> References: <20140521033348.13532.qmail@joyce.lan> Date: Wed, 21 May 2014 14:59:03 +0100 Message-ID: From: Dave Cridland To: John Levine Content-Type: multipart/alternative; boundary=089e013a23782ee51804f9e966ba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/i0pWOs0Zn2PxO42SJ6zaLTSyjR0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:59:06 -0000 --089e013a23782ee51804f9e966ba Content-Type: text/plain; charset=UTF-8 I've read through this; all looks good to me. On 21 May 2014 04:33, John Levine wrote: > I finally updated the draft, based on the thorough Dave Crocker did > in February: > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > > As far as I know, nothing in the draft is contentious. It still > refers to RFC 4408 rather than 7208 because for some reason 7208 isn't > in the xml2rfc library yet. Other than that I think it's done. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013a23782ee51804f9e966ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read through this; all looks good to me.


On 21 May 2014 0= 4:33, John Levine <johnl@taugh.com> wrote:
I finally updated the draft, based on the th= orough Dave Crocker did
in February:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://datatracker.ietf.org/doc/d= raft-ietf-appsawg-nullmx/

As far as I know, nothing in the draft is contentious. =C2=A0It still
refers to RFC 4408 rather than 7208 because for some reason 7208 isn't<= br> in the xml2rfc library yet. =C2=A0Other than that I think it's done.
R's,
John

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e013a23782ee51804f9e966ba-- From nobody Wed May 21 08:00:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7621A06C3 for ; Wed, 21 May 2014 08:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no 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 01a5aU_yQ8gt for ; Wed, 21 May 2014 08:00:52 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32541A0839 for ; Wed, 21 May 2014 08:00:44 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x13so2150186wgg.22 for ; Wed, 21 May 2014 08:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bgo8k/ux+yYtf96Zhpy9CB0WFGCBC0RhZnV9RS80684=; b=iFKPc6E/HYjuTYDEeA1+bMGRKftYFpJuO4Ds+H11O3CLXjL1MM9b16Cta3go0+ATvZ WJAtCz5R+Fp1rcr0jPeY8dpHI/t50IEC+dKDfDF3hWVLf6Vl3BabUI8fgTBDtbFqEOeu IA0XIBkAst66Q6RE2R/6GWy0UrZvQx8+ckqey2pzDv04XfvL2ZyW7pceDWNrpcSJaVOD XLrN5MoOoJaI5ToCEdx1LZ3/HRJMtf5h5ktTamogbCMvrwh8W8P6u/4Oq+Sw2lPp9F+z onsIyddljfGzjHcbBT6A44lTsPUWMuAvZ+4N/nffYTINZtsXNPLI2ocBglxFDRGb0+CZ /a5w== MIME-Version: 1.0 X-Received: by 10.194.92.81 with SMTP id ck17mr44338201wjb.14.1400684442935; Wed, 21 May 2014 08:00:42 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.134.230 with HTTP; Wed, 21 May 2014 08:00:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 11:00:42 -0400 X-Google-Sender-Auth: FZud6WdElEAWtIlndHn6aP7cNTo Message-ID: From: Bob Wyman To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bfceb6aa9e9e404f9ea420d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RjIoCrfKBrBK5nhprpADXCsyP5M Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:00:55 -0000 --047d7bfceb6aa9e9e404f9ea420d Content-Type: text/plain; charset=UTF-8 It strikes me that the Tag URI scheme defined in RFC 4151, and used by Atom , addresses the problem of "time bounded" names. Of course, the Tag URI system currently has no authoritative resolution mechanism. However, it seems that one could define and create such a thing. Thus, one could choose to either: - Use "http://www.example.com/index.html" to access whatever resource was currently so named, or - Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via the Wayback Machine , or something like it, the resource as it was on Sept 15, 2001. The same would work, of course, for email addresses: - "bob@example.com" would indicate the person currently assigned the name "bob" by the mail server currently serving "example.com" - "tag:bob@example.com,2001-09-15" would attempt to resolve to a current address for whoever had been named "bob@example.com" in 2001. That address might be something completely different, of it might resolve to whoever was currently assigned the name (and had been since 2001). Finally, Henry S. Thompson's concern might be address by support something like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS response that one would have received had you made the request "whois example.com" on 2001-09-15. Does Tag URI address your needs? If not, what is missing? If so, then would it be worth the effort to define a Tag URI registration and resolution mechanism? In any case, I am pleased to see this discussion of persistence as an important quality for names. I've long thought that too many of those who investigate the properties of naming systems are overly focused on just the three edges of Zooko's Triangle(Memorability, Global, Security) when we really should also address a fourth edge: Persistence. (We should speak of a pyramid, not a triangle...) For more on this, see an old posting of mine on "The Persistence of Identity (Updating Zooko's Pyramid)" at: http://www.wyman.us/main/2006/12/the_persistence.html [image: Pyramid, not triangle, of identity attributes] bob wyman On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker wrote: > So I made a post to the IETF list yesterday in which I gave a high > level view of the Internet 2020 project and the three goals of > Security, Access and Autonomy. > > The goal of Autonomy being to make the Internet user independent of > institutional control points like ICANN and the corporations trying to > establish themselves as control points. > > ICANN is of course the one we have had concerns about for the longest > time and the autonomy problem is that I don't buy a DNS name, I can > only rent it. And that means that names that are DNS bound can always > be reassigned in the future. Which is one of the reasons why HTTP urls > are unsatisfactory. > > Larry Masinter has of course raised this sort of concern before and > proposed dated URLs. But this morning a different approach to the > problem occurred to me: > > Lets take a URL at a web site and imagine I download a page on 1st Jan > 2010: > http://www.cnn.com/whatever.html > > Now what if I wanted to connect up today to the same party that I > connected to last time. This is not the same as the URN or the dated > URL problem. I want to connect up to the same entity regardless of > whom ICANN happen to sell the domain name to next. > > How about one of the following: > > http://www.cnn.com.2010/whatever.html > http://www.cnn.com.1.2010/whatever.html > http://www.cnn.com.1.1.2010/whatever.html > > DNS labels are not allowed to be all numbers but the DNS protocol > works for them. In fact they seem to work with my existing software > which was not a design goal but would be cool. > > > Now resolving such names would of course require a new infrastructure, > quite possibly a subscription infrastructure that would track the > changing ownership of the names over time. And this infrastructure > would probably involve Certificate Transparency like services and > DNSSEC. > > But we could use this to provide persistence for Web content and for > Web services which would be incredibly cool. > > > We can also apply the same idea to email addresses: > > phill@hallambaker.com could be anyone. > phill@hallambaker.com.16.5.2014 is uniquely my account. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7bfceb6aa9e9e404f9ea420d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It strikes me that the Tag URI scheme defined in=C2=A0RFC 4151,=C2=A0and used by <= a href=3D"http://tools.ietf.org/html/rfc4287">Atom, addresses the probl= em of "time bounded" names. Of course, the Tag URI system current= ly has no authoritati= ve resolution = mechanism.=C2=A0However, it seems that one could define and create s= uch a thing. Thus, one could choose to either:
The same would work, of course, for email addresses:
<= div>
  • "bob@example.com&qu= ot; would indicate the person currently assigned the name "bob" b= y the mail server currently serving "ex= ample.com"
  • "tag:bob@example.com,= 2001-09-15" would attempt to resolve to a current address for whoever = had been named "bob@example.com= " in 2001. That address might be something completely different, of it= might resolve to whoever was currently assigned the name (and had been sin= ce 2001).
Finally, Henry S. Thompson's concern might be address by supp= ort something like "whois tag:example.c= om,2001-09-15" which would retrieve the WHOIS response that one wo= uld have received had you made the request "whois example.com" on 2001-09-15.

Does Tag URI address your needs? If not, what is missin= g? If so, then would it be worth the effort to define a Tag URI registratio= n and resolution mechanism?

In any case, I a= m pleased to see this discussion of persistence as an important quality for= names. I've long thought that too many of those who investigate the pr= operties of naming systems are overly focused on just the three edges of Zooko's Tri= angle (Memorability, Global, Security) when we really should also addre= ss a fourth edge: Persistence. (We should speak of a pyramid, not a triangl= e...) For more on this, see an old posting of mine =C2=A0on "The Persi= stence of Identity (Updating Zooko's Pyramid)" at:=C2=A0http://www.wyman.us= /main/2006/12/the_persistence.html=C2=A0
3D"Pyramid,

bob wyman



On Fri, May 16, 2014 at 3:40 PM,= Phillip Hallam-Baker <phill@hallambaker.com> wrote:
So I made a post to the IETF list yesterday = in which I gave a high
level view of the Internet 2020 project and the three goals of
Security, Access and Autonomy.

The goal of Autonomy being to make the Internet user independent of
institutional control points like ICANN and the corporations trying to
establish themselves as control points.

ICANN is of course the one we have had concerns about for the longest
time and the autonomy problem is that I don't buy a DNS name, I can
only rent it. And that means that names that are DNS bound can always
be reassigned in the future. Which is one of the reasons why HTTP urls
are unsatisfactory.

Larry Masinter has of course raised this sort of concern before and
proposed dated URLs. But this morning a different approach to the
problem occurred to me:

Lets take a URL at a web site and imagine I download a page on 1st Jan 2010= :
http://www.c= nn.com/whatever.html

Now what if I wanted to connect up today to the same party that I
connected to last time. This is not the same as the URN or the dated
URL problem. I want to connect up to the same entity regardless of
whom ICANN happen to sell the domain name to next.

How about one of the following:

http://= www.cnn.com.2010/whatever.html
http:= //www.cnn.com.1.2010/whatever.html
htt= p://www.cnn.com.1.1.2010/whatever.html

DNS labels are not allowed to be all numbers but the DNS protocol
works for them. In fact they seem to work with my existing software
which was not a design goal but would be cool.


Now resolving such names would of course require a new infrastructure,
quite possibly a subscription infrastructure that would track the
changing ownership of the names over time. And this infrastructure
would probably involve Certificate Transparency like services and
DNSSEC.

But we could use this to provide persistence for Web content and for
Web services which would be incredibly cool.


We can also apply the same idea to email addresses:

phill@hallambaker.com could be= anyone.
phill@hallambaker.com.16.5.2014 is uniquely my account.

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--047d7bfceb6aa9e9e404f9ea420d-- From nobody Wed May 21 08:40:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25401A072A for ; Wed, 21 May 2014 08:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 vNscBGZGSSa4 for ; Wed, 21 May 2014 08:39:57 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334BC1A06F9 for ; Wed, 21 May 2014 08:39:57 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so2248497wev.3 for ; Wed, 21 May 2014 08:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9j4qv6YK3ntZCQt668eInsNla2TP+Yqlu9uInEDmBSk=; b=F2+1AoL7Obg2b973OIiltUTqvtME/IQrIo3UtMrOmX5bEQsgfO7rNvUG6Nr1/3dzNN QnEzxGmRodGVL58tbMuJY8U0StTq3U1c9daSgecXMUyQc4wigwRDbiAvdTHItATxDYcM jaZFwZyQ0ujkOip0Irv6yic1VUx+oEU9J09ZBDXgwWfbEC7gsvV6WvmrsU79tcm80xw9 ri+Vjvp+pjxOGmtuICee0QM3dn+5OdcXgODfY6u2GukfcH7NZZPPBxDnoaM8Y2lBiL8k 3rlGGPuPj0/PY+YPvxAYApfSkHHxUk3CFKFE9UZHF3I3UrVpFCykCD48U15QYKvXvPjp 9Nlg== X-Received: by 10.180.228.6 with SMTP id se6mr11205996wic.52.1400686795109; Wed, 21 May 2014 08:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.223.68 with HTTP; Wed, 21 May 2014 08:39:35 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 21 May 2014 08:39:35 -0700 Message-ID: To: Bob Wyman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tfMykgBc_HB3YuPHBAK-iSAHmYg Cc: Phillip Hallam-Baker , General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:40:04 -0000 Ah, tag URI's... those bring me back. Was it really nine years ago already!? While tag URI's *might* work structurally, I can see a number of issues using them for this purpose -- not the least of which is the fact that tag URI's provide no reliable verification. I've often considered that a variation on the "Naming Things With Hashes" approach (RFC 6920) could be leveraged... essentially, wrap things like HTTP URI within a hashed, timestamped URI syntax that can provide reliable point-in-time linking. It gets a bit ugly visually and certainly wouldn't be intended for human readability, but something along the lines of (just a strawman) pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add Where: pit == "point in time reference" 2014-05 is the point in time being asserted b0717f9a is, for lack of a better term, an Entity Tag or Validator to be matched against the fetched resource (it can, for instance, appear as the Entity Tag in the HTTP response) http%3A%2F%2Fexample.org%2Ffoo is the actual resource being referenced at the given point in time. and sha-256-32:f83b2add is the hash generated from the timestamp, validator and ref url. The inclusion of the validator makes it possible to reference specific versions of the target resource and the hash provides us with at least some level of verifiability. It's an idea, at least. Whether or not it's a good one remains to be seen ;-) - James On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: > It strikes me that the Tag URI scheme defined in RFC 4151, and used by Atom, > addresses the problem of "time bounded" names. Of course, the Tag URI system > currently has no authoritative resolution mechanism. However, it seems that > one could define and create such a thing. Thus, one could choose to either: > > Use "http://www.example.com/index.html" to access whatever resource was > currently so named, or > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via the > Wayback Machine, or something like it, the resource as it was on Sept 15, > 2001. > > The same would work, of course, for email addresses: > > "bob@example.com" would indicate the person currently assigned the name > "bob" by the mail server currently serving "example.com" > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current > address for whoever had been named "bob@example.com" in 2001. That address > might be something completely different, of it might resolve to whoever was > currently assigned the name (and had been since 2001). > > Finally, Henry S. Thompson's concern might be address by support something > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS > response that one would have received had you made the request "whois > example.com" on 2001-09-15. > > Does Tag URI address your needs? If not, what is missing? If so, then would > it be worth the effort to define a Tag URI registration and resolution > mechanism? > > In any case, I am pleased to see this discussion of persistence as an > important quality for names. I've long thought that too many of those who > investigate the properties of naming systems are overly focused on just the > three edges of Zooko's Triangle (Memorability, Global, Security) when we > really should also address a fourth edge: Persistence. (We should speak of a > pyramid, not a triangle...) For more on this, see an old posting of mine on > "The Persistence of Identity (Updating Zooko's Pyramid)" at: > http://www.wyman.us/main/2006/12/the_persistence.html > > bob wyman > > > > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker > wrote: >> >> So I made a post to the IETF list yesterday in which I gave a high >> level view of the Internet 2020 project and the three goals of >> Security, Access and Autonomy. >> >> The goal of Autonomy being to make the Internet user independent of >> institutional control points like ICANN and the corporations trying to >> establish themselves as control points. >> >> ICANN is of course the one we have had concerns about for the longest >> time and the autonomy problem is that I don't buy a DNS name, I can >> only rent it. And that means that names that are DNS bound can always >> be reassigned in the future. Which is one of the reasons why HTTP urls >> are unsatisfactory. >> >> Larry Masinter has of course raised this sort of concern before and >> proposed dated URLs. But this morning a different approach to the >> problem occurred to me: >> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >> 2010: >> http://www.cnn.com/whatever.html >> >> Now what if I wanted to connect up today to the same party that I >> connected to last time. This is not the same as the URN or the dated >> URL problem. I want to connect up to the same entity regardless of >> whom ICANN happen to sell the domain name to next. >> >> How about one of the following: >> >> http://www.cnn.com.2010/whatever.html >> http://www.cnn.com.1.2010/whatever.html >> http://www.cnn.com.1.1.2010/whatever.html >> >> DNS labels are not allowed to be all numbers but the DNS protocol >> works for them. In fact they seem to work with my existing software >> which was not a design goal but would be cool. >> >> >> Now resolving such names would of course require a new infrastructure, >> quite possibly a subscription infrastructure that would track the >> changing ownership of the names over time. And this infrastructure >> would probably involve Certificate Transparency like services and >> DNSSEC. >> >> But we could use this to provide persistence for Web content and for >> Web services which would be incredibly cool. >> >> >> We can also apply the same idea to email addresses: >> >> phill@hallambaker.com could be anyone. >> phill@hallambaker.com.16.5.2014 is uniquely my account. >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed May 21 09:11:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170DC1A0564 for ; Wed, 21 May 2014 09:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no 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 TeJKrE5xDz0Y for ; Wed, 21 May 2014 09:11:33 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D68F1A0346 for ; Wed, 21 May 2014 09:11:32 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so2230593wgh.19 for ; Wed, 21 May 2014 09:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=p6JMz76ollQCvnqfRB+KUQGoig4GqT2IgQnWSnzBboQ=; b=WQgaf+wb0vkbn/f8nIVzuE9Rf/nYtT5OXxW95KfVwk1w7CyIrJ72d1O9a4/hFlxAi7 na3GFdfREfivsF1Pkl7ajydbQmPm40A7rcdzCNGYh5u9NXlEnA4o/Aygi9m3IFY0nOe2 PvCSTi023WA/mOeCVOblrs/qdfYDvIad17m+7y4PZTXnge3YLij5socNOUwCrpZdydpK 2ppXXEigO3aIMrpGBAJdPTTOVYVxoZnDhG4jj36wFyJTP+etoxPAOOTsDoFunKhhtODq pV28UffJrvushq9L2l11yz8ZEusMo1VyiFHObe3C9uMo+MWdd9f9DZ9pwsZ2WL7GzO/D 4ipg== MIME-Version: 1.0 X-Received: by 10.180.100.41 with SMTP id ev9mr11436764wib.22.1400688690447; Wed, 21 May 2014 09:11:30 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.134.230 with HTTP; Wed, 21 May 2014 09:11:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 12:11:30 -0400 X-Google-Sender-Auth: 9b3OeycBMfbZht41PAnnfP9btxo Message-ID: From: Bob Wyman To: James M Snell Content-Type: multipart/alternative; boundary=f46d044402f4d5cf9304f9eb3f6f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0vJKJvOt7rv-CyhINbCsAFfyOos Cc: Phillip Hallam-Baker , General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:11:36 -0000 --f46d044402f4d5cf9304f9eb3f6f Content-Type: text/plain; charset=UTF-8 James, Since your "point in time reference," by including an Entity Tag or Validator, requires knowledge of the resource's attributes at the particular moment of interest, it would only work if people anticipated the need to reference the resource at some future time and stored the pit: values. It wouldn't help someone who knew nothing about the attributes of example.org on a particular date but was attempting to discover them. In those cases where one did anticipate the need to have a time independent name for a resource, the hash you propose, since it is generated from timestamp, vaildator and ref-url, essentially contains all the information (with some loss) of the other components, thus, it seems that one could economize by simply discarding those other bits. Wouldn't pit:sha-256-32:f83b2add have much the same utility as pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if ones interest is only in the specific instance of the resource so named? bob wyman On Wed, May 21, 2014 at 11:39 AM, James M Snell wrote: > Ah, tag URI's... those bring me back. Was it really nine years ago > already!? While tag URI's *might* work structurally, I can see a > number of issues using them for this purpose -- not the least of which > is the fact that tag URI's provide no reliable verification. I've > often considered that a variation on the "Naming Things With Hashes" > approach (RFC 6920) could be leveraged... essentially, wrap things > like HTTP URI within a hashed, timestamped URI syntax that can provide > reliable point-in-time linking. > > It gets a bit ugly visually and certainly wouldn't be intended for > human readability, but something along the lines of (just a strawman) > > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add > > Where: > > pit == "point in time reference" > 2014-05 is the point in time being asserted > b0717f9a is, for lack of a better term, an Entity Tag or Validator > to be matched against the fetched resource (it can, for instance, > appear as the Entity Tag in the HTTP response) > http%3A%2F%2Fexample.org%2Ffoo is the actual resource being > referenced at the given point in time. > and sha-256-32:f83b2add is the hash generated from the timestamp, > validator and ref url. > > The inclusion of the validator makes it possible to reference specific > versions of the target resource and the hash provides us with at least > some level of verifiability. > > It's an idea, at least. Whether or not it's a good one remains to be seen > ;-) > > - James > > On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: > > It strikes me that the Tag URI scheme defined in RFC 4151, and used by > Atom, > > addresses the problem of "time bounded" names. Of course, the Tag URI > system > > currently has no authoritative resolution mechanism. However, it seems > that > > one could define and create such a thing. Thus, one could choose to > either: > > > > Use "http://www.example.com/index.html" to access whatever resource was > > currently so named, or > > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via > the > > Wayback Machine, or something like it, the resource as it was on Sept 15, > > 2001. > > > > The same would work, of course, for email addresses: > > > > "bob@example.com" would indicate the person currently assigned the name > > "bob" by the mail server currently serving "example.com" > > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current > > address for whoever had been named "bob@example.com" in 2001. That > address > > might be something completely different, of it might resolve to whoever > was > > currently assigned the name (and had been since 2001). > > > > Finally, Henry S. Thompson's concern might be address by support > something > > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS > > response that one would have received had you made the request "whois > > example.com" on 2001-09-15. > > > > Does Tag URI address your needs? If not, what is missing? If so, then > would > > it be worth the effort to define a Tag URI registration and resolution > > mechanism? > > > > In any case, I am pleased to see this discussion of persistence as an > > important quality for names. I've long thought that too many of those who > > investigate the properties of naming systems are overly focused on just > the > > three edges of Zooko's Triangle (Memorability, Global, Security) when we > > really should also address a fourth edge: Persistence. (We should speak > of a > > pyramid, not a triangle...) For more on this, see an old posting of mine > on > > "The Persistence of Identity (Updating Zooko's Pyramid)" at: > > http://www.wyman.us/main/2006/12/the_persistence.html > > > > bob wyman > > > > > > > > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker > > wrote: > >> > >> So I made a post to the IETF list yesterday in which I gave a high > >> level view of the Internet 2020 project and the three goals of > >> Security, Access and Autonomy. > >> > >> The goal of Autonomy being to make the Internet user independent of > >> institutional control points like ICANN and the corporations trying to > >> establish themselves as control points. > >> > >> ICANN is of course the one we have had concerns about for the longest > >> time and the autonomy problem is that I don't buy a DNS name, I can > >> only rent it. And that means that names that are DNS bound can always > >> be reassigned in the future. Which is one of the reasons why HTTP urls > >> are unsatisfactory. > >> > >> Larry Masinter has of course raised this sort of concern before and > >> proposed dated URLs. But this morning a different approach to the > >> problem occurred to me: > >> > >> Lets take a URL at a web site and imagine I download a page on 1st Jan > >> 2010: > >> http://www.cnn.com/whatever.html > >> > >> Now what if I wanted to connect up today to the same party that I > >> connected to last time. This is not the same as the URN or the dated > >> URL problem. I want to connect up to the same entity regardless of > >> whom ICANN happen to sell the domain name to next. > >> > >> How about one of the following: > >> > >> http://www.cnn.com.2010/whatever.html > >> http://www.cnn.com.1.2010/whatever.html > >> http://www.cnn.com.1.1.2010/whatever.html > >> > >> DNS labels are not allowed to be all numbers but the DNS protocol > >> works for them. In fact they seem to work with my existing software > >> which was not a design goal but would be cool. > >> > >> > >> Now resolving such names would of course require a new infrastructure, > >> quite possibly a subscription infrastructure that would track the > >> changing ownership of the names over time. And this infrastructure > >> would probably involve Certificate Transparency like services and > >> DNSSEC. > >> > >> But we could use this to provide persistence for Web content and for > >> Web services which would be incredibly cool. > >> > >> > >> We can also apply the same idea to email addresses: > >> > >> phill@hallambaker.com could be anyone. > >> phill@hallambaker.com.16.5.2014 is uniquely my account. > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --f46d044402f4d5cf9304f9eb3f6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
James,
Since your "point in time reference,"= by including an Entity Tag or Validator, requires knowledge of the resourc= e's attributes at the particular moment of interest, it would only work= if people anticipated the need to reference the resource at some future ti= me and stored the pit: values. It wouldn't help someone who knew nothin= g about the attributes of example.org on= a particular date but was attempting to discover them.=C2=A0

In those cases where one did anticipate the need to hav= e a time independent name for a resource, the hash you propose, since it is= generated from timestamp, vaildator and ref-url, essentially contains all = the information (with some loss) of the other components, thus, it seems th= at one could economize by simply discarding those other bits.

Wouldn't pit:sha-256-32:f83b2add have much the same utility as=C2=A0pit:2014-05:b0= 717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if ones interest is only in the s= pecific instance of the resource so named?

bob wyman




On We= d, May 21, 2014 at 11:39 AM, James M Snell <jasnell@gmail.com> wrote:
Ah, tag URI's... those bring me back. Wa= s it really nine years ago
already!? While tag URI's *might* work structurally, I can see a
number of issues using them for this purpose -- not the least of which
is the fact that tag URI's provide no reliable verification. I've often considered that a variation on the "Naming Things With Hashes&qu= ot;
approach (RFC 6920) could be leveraged... essentially, wrap things
like HTTP URI within a hashed, timestamped URI syntax that can provide
reliable point-in-time linking.

It gets a bit ugly visually and certainly wouldn't be intended for
human readability, but something along the lines of (just a strawman)

pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add

Where:

=C2=A0 pit =3D=3D "point in time reference"
=C2=A0 2014-05 is the point in time being asserted
=C2=A0 b0717f9a is, for lack of a better term, an Entity Tag or Validator to be matched against the fetched resource (it can, for instance,
appear as the Entity Tag in the HTTP response)
=C2=A0 http%3A%2F%2Fexample.org%2Ffoo is the actual resource being
referenced at the given point in time.
=C2=A0 and sha-256-32:f83b2add is the hash generated from the timestamp, validator and ref url.

The inclusion of the validator makes it possible to reference specific
versions of the target resource and the hash provides us with at least
some level of verifiability.

It's an idea, at least. Whether or not it's a good one remains to b= e seen ;-)

- James

On Wed, May 21, 2014 at 8:00 AM, Bob Wyman <bob@wyman.us> wrote:
> It strikes me that the Tag URI scheme defined in RFC 4151, and used by= Atom,
> addresses the problem of "time bounded" names. Of course, th= e Tag URI system
> currently has no authoritative resolution mechanism. However, it seems= that
> one could define and create such a thing. Thus, one could choose to ei= ther:
>
> Use "http://www.example.com/index.html" to access whatever resource= was
> currently so named, or
> Use "tag:www= .example.com,2001-09-15:/index.html to access, perhaps via the
> Wayback Machine, or something like it, the resource as it was on Sept = 15,
> 2001.
>
> The same would work, of course, for email addresses:
>
> "bob@example.com" wou= ld indicate the person currently assigned the name
> "bob" by the mail server currently serving "example.com"
> "tag:bob@example.com= ,2001-09-15" would attempt to resolve to a current
> address for whoever had been named "bob@example.com" in 2001. That address
> might be something completely different, of it might resolve to whoeve= r was
> currently assigned the name (and had been since 2001).
>
> Finally, Henry S. Thompson's concern might be address by support s= omething
> like "whois tag:= example.com,2001-09-15" which would retrieve the WHOIS
> response that one would have received had you made the request "w= hois
> example.com"= on 2001-09-15.
>
> Does Tag URI address your needs? If not, what is missing? If so, then = would
> it be worth the effort to define a Tag URI registration and resolution=
> mechanism?
>
> In any case, I am pleased to see this discussion of persistence as an<= br> > important quality for names. I've long thought that too many of th= ose who
> investigate the properties of naming systems are overly focused on jus= t the
> three edges of Zooko's Triangle (Memorability, Global, Security) w= hen we
> really should also address a fourth edge: Persistence. (We should spea= k of a
> pyramid, not a triangle...) For more on this, see an old posting of mi= ne =C2=A0on
> "The Persistence of Identity (Updating Zooko's Pyramid)"= at:
> http://www.wyman.us/main/2006/12/the_persistence.html
>
> bob wyman
>
>
>
> On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker
> <phill@hallambaker.com= > wrote:
>>
>> So I made a post to the IETF list yesterday in which I gave a high=
>> level view of the Internet 2020 project and the three goals of
>> Security, Access and Autonomy.
>>
>> The goal of Autonomy being to make the Internet user independent o= f
>> institutional control points like ICANN and the corporations tryin= g to
>> establish themselves as control points.
>>
>> ICANN is of course the one we have had concerns about for the long= est
>> time and the autonomy problem is that I don't buy a DNS name, = I can
>> only rent it. And that means that names that are DNS bound can alw= ays
>> be reassigned in the future. Which is one of the reasons why HTTP = urls
>> are unsatisfactory.
>>
>> Larry Masinter has of course raised this sort of concern before an= d
>> proposed dated URLs. But this morning a different approach to the<= br> >> problem occurred to me:
>>
>> Lets take a URL at a web site and imagine I download a page on 1st= Jan
>> 2010:
>> htt= p://www.cnn.com/whatever.html
>>
>> Now what if I wanted to connect up today to the same party that I<= br> >> connected to last time. This is not the same as the URN or the dat= ed
>> URL problem. I want to connect up to the same entity regardless of=
>> whom ICANN happen to sell the domain name to next.
>>
>> How about one of the following:
>>
>> http://www.cnn.com.2010/whatever.html
>> http://www.cnn.com.1.2010/whatever.html
>> http://www.cnn.com.1.1.2010/whatever.html
>>
>> DNS labels are not allowed to be all numbers but the DNS protocol<= br> >> works for them. In fact they seem to work with my existing softwar= e
>> which was not a design goal but would be cool.
>>
>>
>> Now resolving such names would of course require a new infrastruct= ure,
>> quite possibly a subscription infrastructure that would track the<= br> >> changing ownership of the names over time. And this infrastructure=
>> would probably involve Certificate Transparency like services and<= br> >> DNSSEC.
>>
>> But we could use this to provide persistence for Web content and f= or
>> Web services which would be incredibly cool.
>>
>>
>> We can also apply the same idea to email addresses:
>>
>> phill@hallambaker.com= could be anyone.
>> phill@hallambaker.com.16.5.2014 is uniquely my account.
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org=
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--f46d044402f4d5cf9304f9eb3f6f-- From nobody Wed May 21 10:05:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7879C1A0859 for ; Wed, 21 May 2014 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no 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 bkRIKRkBuWpK for ; Wed, 21 May 2014 10:05:50 -0700 (PDT) Received: from orthanc.ca (unknown [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDD71A085A for ; Wed, 21 May 2014 10:05:50 -0700 (PDT) Received: from [192.168.42.6] (d66-183-221-35.bchsia.telus.net [66.183.221.35]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s4LH5jPY005512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 May 2014 10:05:47 -0700 (PDT) (envelope-from lyndon@orthanc.ca) From: Lyndon Nerenberg Content-Type: multipart/signed; boundary="Apple-Mail=_66DAA08C-C9C6-4739-A7E4-1DE5731450EE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 21 May 2014 10:05:44 -0700 References: <20140521033348.13532.qmail@joyce.lan> To: IETF Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DUAprRhrO-E2ET3FgxQLO5DFMPs Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:05:51 -0000 --Apple-Mail=_66DAA08C-C9C6-4739-A7E4-1DE5731450EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In the third paragraph of section 4: "... or alice@examp1e.com rather than alice@example.com." This doesn't read right, to me at least. I think I know what was = intended here, but this looks like a cut/paste error crept in along the = way. --lyndon --Apple-Mail=_66DAA08C-C9C6-4739-A7E4-1DE5731450EE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTfNzoAAoJEG8PnXiV/JnUpQ8QAIpi8eLsQKsRFS5ZBUHkueFk GJ6myGGSOUJRA6Mw/Zvp5FPu+uXT2dQy2Ae3flWrZrozIAdJPHwxe3TBhdFu50sa +V5LLyofG+dxI/6N/tR634PIBGThopx6vzPlOJoxhIsn2nFXkvFVypQ+aCFHRv6k jAv8w98iF/Hg+9/qqe9BnzLeJ4/NJfvVYjOROvbtV5nVGSvC2jmDK2JdXlQm2a5g A0rCBzCnSYNH1FSZbp5ZHndgkSYzvWOz+4D+CFgUYNsN7jTiV+p1jFcpeygHGv3o s2cjS9sy57wAmBTRsOq8RE6LzsLMtqFL4DTmlK7FMaYVCIRui2qvTzBginUseDmV vptZeD5wTg+hhQZ5VBNQPejiSmCU49zScsOpP0ufnS3q1k+P3XW82q0hyt39lj2j qUeVDoKLGv0cXE6ZPlARiBUUye+2OLlZmi0tDLBrCCphlcN0ht0DIY5EN8cYkki3 ltClFhL2nO6towMNPgDz4SUp1hREavYzJwMpm7++GEDAeEYIcbRJTaHEzA8fpGM2 QLKVGvb+/uy+K5irSKF+ygPz34hNnSXc2rE4oBijXFtxCyCYjI1xq61CJT9IZEwY 2gipBPqx7d56Pb5qSUR5t265tu5DEeg9z4Cg29YYpXpAzAtsixHG4WoENDP1QtA/ aysusHVv+1HEzuD/8uFe =TOoB -----END PGP SIGNATURE----- --Apple-Mail=_66DAA08C-C9C6-4739-A7E4-1DE5731450EE-- From nobody Wed May 21 10:41:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508CC1A00E9 for ; Wed, 21 May 2014 10:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JbHSFwvMB76J for ; Wed, 21 May 2014 10:41:10 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E022D1A00ED for ; Wed, 21 May 2014 10:41:09 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so2368852wgg.24 for ; Wed, 21 May 2014 10:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LibdN08Fq3kToxd2L3XK13dqYKXqrS4iTeTfXC1gOqM=; b=May2PsnhQJ5IsdSzqFnrJnGM+zhfQ8agGpr6Rncq/hlOvr9x6hB/ChMJLBkDq+SmWy OH4RKPZ+5HLfrpBLyl0aVAP7GAvNQr72jEqfsUe0Du1JW/vJg6uYRTJpdVqmcqihFNBA J1voktofyQL6dSNRJwkyGnUzgOzFkr8UWy5Er1Orw1a43Id1S6udd7I3+2bejXvQscv+ IGdzhISbstZ43RbuTfa6dI3Jx5gD4t1TV0qwr5nkxGt6UGOh9y5NqOY8vIX6E36oBdy8 eZ/6eEullWMOiFkxf4uKgsqADOauCw9fvvnbhuCXTqy1YRIYy4jql9lrByw7MmNTcWWn 1iYg== X-Received: by 10.180.7.198 with SMTP id l6mr11779976wia.52.1400694067859; Wed, 21 May 2014 10:41:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.223.68 with HTTP; Wed, 21 May 2014 10:40:47 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 21 May 2014 10:40:47 -0700 Message-ID: To: Bob Wyman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QrS4kDroNBreHsWgO7by2JtTDkg Cc: Phillip Hallam-Baker , General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:41:12 -0000 Truncating the pit reference would (a) make it harder to dereference and (b) make it identical to the existing "naming things with hashes" spec ;-) ... The key difference with pit would be to allow the time-bound reference to be largely self-contained. But, you're right, it would require specific knowledge of the resource being referenced unless we allowed for a modified version that omitted the validator -- in which case, the timestamp becomes the validator (ala If-Unmodified-Since). On Wed, May 21, 2014 at 9:11 AM, Bob Wyman wrote: > James, > Since your "point in time reference," by including an Entity Tag or > Validator, requires knowledge of the resource's attributes at the particular > moment of interest, it would only work if people anticipated the need to > reference the resource at some future time and stored the pit: values. It > wouldn't help someone who knew nothing about the attributes of example.org > on a particular date but was attempting to discover them. > > In those cases where one did anticipate the need to have a time independent > name for a resource, the hash you propose, since it is generated from > timestamp, vaildator and ref-url, essentially contains all the information > (with some loss) of the other components, thus, it seems that one could > economize by simply discarding those other bits. > > Wouldn't pit:sha-256-32:f83b2add have much the same utility as > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if > ones interest is only in the specific instance of the resource so named? > > bob wyman > > > > > On Wed, May 21, 2014 at 11:39 AM, James M Snell wrote: >> >> Ah, tag URI's... those bring me back. Was it really nine years ago >> already!? While tag URI's *might* work structurally, I can see a >> number of issues using them for this purpose -- not the least of which >> is the fact that tag URI's provide no reliable verification. I've >> often considered that a variation on the "Naming Things With Hashes" >> approach (RFC 6920) could be leveraged... essentially, wrap things >> like HTTP URI within a hashed, timestamped URI syntax that can provide >> reliable point-in-time linking. >> >> It gets a bit ugly visually and certainly wouldn't be intended for >> human readability, but something along the lines of (just a strawman) >> >> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add >> >> Where: >> >> pit == "point in time reference" >> 2014-05 is the point in time being asserted >> b0717f9a is, for lack of a better term, an Entity Tag or Validator >> to be matched against the fetched resource (it can, for instance, >> appear as the Entity Tag in the HTTP response) >> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being >> referenced at the given point in time. >> and sha-256-32:f83b2add is the hash generated from the timestamp, >> validator and ref url. >> >> The inclusion of the validator makes it possible to reference specific >> versions of the target resource and the hash provides us with at least >> some level of verifiability. >> >> It's an idea, at least. Whether or not it's a good one remains to be seen >> ;-) >> >> - James >> >> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: >> > It strikes me that the Tag URI scheme defined in RFC 4151, and used by >> > Atom, >> > addresses the problem of "time bounded" names. Of course, the Tag URI >> > system >> > currently has no authoritative resolution mechanism. However, it seems >> > that >> > one could define and create such a thing. Thus, one could choose to >> > either: >> > >> > Use "http://www.example.com/index.html" to access whatever resource was >> > currently so named, or >> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via >> > the >> > Wayback Machine, or something like it, the resource as it was on Sept >> > 15, >> > 2001. >> > >> > The same would work, of course, for email addresses: >> > >> > "bob@example.com" would indicate the person currently assigned the name >> > "bob" by the mail server currently serving "example.com" >> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current >> > address for whoever had been named "bob@example.com" in 2001. That >> > address >> > might be something completely different, of it might resolve to whoever >> > was >> > currently assigned the name (and had been since 2001). >> > >> > Finally, Henry S. Thompson's concern might be address by support >> > something >> > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS >> > response that one would have received had you made the request "whois >> > example.com" on 2001-09-15. >> > >> > Does Tag URI address your needs? If not, what is missing? If so, then >> > would >> > it be worth the effort to define a Tag URI registration and resolution >> > mechanism? >> > >> > In any case, I am pleased to see this discussion of persistence as an >> > important quality for names. I've long thought that too many of those >> > who >> > investigate the properties of naming systems are overly focused on just >> > the >> > three edges of Zooko's Triangle (Memorability, Global, Security) when we >> > really should also address a fourth edge: Persistence. (We should speak >> > of a >> > pyramid, not a triangle...) For more on this, see an old posting of mine >> > on >> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: >> > http://www.wyman.us/main/2006/12/the_persistence.html >> > >> > bob wyman >> > >> > >> > >> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker >> > wrote: >> >> >> >> So I made a post to the IETF list yesterday in which I gave a high >> >> level view of the Internet 2020 project and the three goals of >> >> Security, Access and Autonomy. >> >> >> >> The goal of Autonomy being to make the Internet user independent of >> >> institutional control points like ICANN and the corporations trying to >> >> establish themselves as control points. >> >> >> >> ICANN is of course the one we have had concerns about for the longest >> >> time and the autonomy problem is that I don't buy a DNS name, I can >> >> only rent it. And that means that names that are DNS bound can always >> >> be reassigned in the future. Which is one of the reasons why HTTP urls >> >> are unsatisfactory. >> >> >> >> Larry Masinter has of course raised this sort of concern before and >> >> proposed dated URLs. But this morning a different approach to the >> >> problem occurred to me: >> >> >> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >> >> 2010: >> >> http://www.cnn.com/whatever.html >> >> >> >> Now what if I wanted to connect up today to the same party that I >> >> connected to last time. This is not the same as the URN or the dated >> >> URL problem. I want to connect up to the same entity regardless of >> >> whom ICANN happen to sell the domain name to next. >> >> >> >> How about one of the following: >> >> >> >> http://www.cnn.com.2010/whatever.html >> >> http://www.cnn.com.1.2010/whatever.html >> >> http://www.cnn.com.1.1.2010/whatever.html >> >> >> >> DNS labels are not allowed to be all numbers but the DNS protocol >> >> works for them. In fact they seem to work with my existing software >> >> which was not a design goal but would be cool. >> >> >> >> >> >> Now resolving such names would of course require a new infrastructure, >> >> quite possibly a subscription infrastructure that would track the >> >> changing ownership of the names over time. And this infrastructure >> >> would probably involve Certificate Transparency like services and >> >> DNSSEC. >> >> >> >> But we could use this to provide persistence for Web content and for >> >> Web services which would be incredibly cool. >> >> >> >> >> >> We can also apply the same idea to email addresses: >> >> >> >> phill@hallambaker.com could be anyone. >> >> phill@hallambaker.com.16.5.2014 is uniquely my account. >> >> >> >> _______________________________________________ >> >> apps-discuss mailing list >> >> apps-discuss@ietf.org >> >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > From nobody Wed May 21 10:46:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C401C1A0116 for ; Wed, 21 May 2014 10:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 V5wgLl-aaIso for ; Wed, 21 May 2014 10:46:00 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460601A0685 for ; Wed, 21 May 2014 10:46:00 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so2360917wgh.32 for ; Wed, 21 May 2014 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HK9JSix+rjr2fieEZeips1nxs/m0SKxGausAWPBg8gQ=; b=KRAfT4RDR6se7v0myrh0rzjaj3cPu/59cUKAizL6uA9SvTNCuOmN7+/488HAlggdp1 r5+P496rpKtxZxwz/ZRSz39EEW3otRGfnO+vbgLn+z9LuVFqKfV96aSsk666VixSrtBr 1npNeegcxEsL0AdYROXFwRWmsMz3HWD+igpV9fzLRr+HV87zD+MXB0hpWcykGBbrAe6L 4FOri0KIC8oR/K8j18aC82UdS3e0qycnzUCrHmtkfbiqxBvY/DfBDTJg0zZTxRAcFCH8 aKOCcdP+yxiopt8zSkPFz/pEtKv8jBXNYc2NNf68xfGPwVpyXCFMa8EXZ6n5IQkTaTvJ 5drA== X-Received: by 10.180.212.77 with SMTP id ni13mr11642848wic.5.1400694358169; Wed, 21 May 2014 10:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.223.68 with HTTP; Wed, 21 May 2014 10:45:38 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 21 May 2014 10:45:38 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/seePinQAM4eVdfYtkFUfJm6s3XU Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:46:02 -0000 Storage is cheap yes, the potential practical/legal/privacy ramifications of such archives, however, may not be. The ability to dereference a resource's state, at a given point in time, without requiring the resource state to be duplicated and stored by a non-authoritative third party, would be an ideal solution. On Wed, May 21, 2014 at 10:18 AM, Phillip Hallam-Baker wrote: > What I would like to see for archival storage is a mechanism that > allows a document submission system to archive copies of the linked > documents. > > Storage is cheap. Copyright is not always an obstruction. > > So for example, say I am writing an RFC, I submit the document to the > IETF, the publication system sees that it references docs X, Y, Z and > archive copies of them. > > > > On Wed, May 21, 2014 at 12:11 PM, Bob Wyman wrote: >> James, >> Since your "point in time reference," by including an Entity Tag or >> Validator, requires knowledge of the resource's attributes at the particular >> moment of interest, it would only work if people anticipated the need to >> reference the resource at some future time and stored the pit: values. It >> wouldn't help someone who knew nothing about the attributes of example.org >> on a particular date but was attempting to discover them. >> >> In those cases where one did anticipate the need to have a time independent >> name for a resource, the hash you propose, since it is generated from >> timestamp, vaildator and ref-url, essentially contains all the information >> (with some loss) of the other components, thus, it seems that one could >> economize by simply discarding those other bits. >> >> Wouldn't pit:sha-256-32:f83b2add have much the same utility as >> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if >> ones interest is only in the specific instance of the resource so named? >> >> bob wyman >> >> >> >> >> On Wed, May 21, 2014 at 11:39 AM, James M Snell wrote: >>> >>> Ah, tag URI's... those bring me back. Was it really nine years ago >>> already!? While tag URI's *might* work structurally, I can see a >>> number of issues using them for this purpose -- not the least of which >>> is the fact that tag URI's provide no reliable verification. I've >>> often considered that a variation on the "Naming Things With Hashes" >>> approach (RFC 6920) could be leveraged... essentially, wrap things >>> like HTTP URI within a hashed, timestamped URI syntax that can provide >>> reliable point-in-time linking. >>> >>> It gets a bit ugly visually and certainly wouldn't be intended for >>> human readability, but something along the lines of (just a strawman) >>> >>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add >>> >>> Where: >>> >>> pit == "point in time reference" >>> 2014-05 is the point in time being asserted >>> b0717f9a is, for lack of a better term, an Entity Tag or Validator >>> to be matched against the fetched resource (it can, for instance, >>> appear as the Entity Tag in the HTTP response) >>> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being >>> referenced at the given point in time. >>> and sha-256-32:f83b2add is the hash generated from the timestamp, >>> validator and ref url. >>> >>> The inclusion of the validator makes it possible to reference specific >>> versions of the target resource and the hash provides us with at least >>> some level of verifiability. >>> >>> It's an idea, at least. Whether or not it's a good one remains to be seen >>> ;-) >>> >>> - James >>> >>> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: >>> > It strikes me that the Tag URI scheme defined in RFC 4151, and used by >>> > Atom, >>> > addresses the problem of "time bounded" names. Of course, the Tag URI >>> > system >>> > currently has no authoritative resolution mechanism. However, it seems >>> > that >>> > one could define and create such a thing. Thus, one could choose to >>> > either: >>> > >>> > Use "http://www.example.com/index.html" to access whatever resource was >>> > currently so named, or >>> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via >>> > the >>> > Wayback Machine, or something like it, the resource as it was on Sept >>> > 15, >>> > 2001. >>> > >>> > The same would work, of course, for email addresses: >>> > >>> > "bob@example.com" would indicate the person currently assigned the name >>> > "bob" by the mail server currently serving "example.com" >>> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current >>> > address for whoever had been named "bob@example.com" in 2001. That >>> > address >>> > might be something completely different, of it might resolve to whoever >>> > was >>> > currently assigned the name (and had been since 2001). >>> > >>> > Finally, Henry S. Thompson's concern might be address by support >>> > something >>> > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS >>> > response that one would have received had you made the request "whois >>> > example.com" on 2001-09-15. >>> > >>> > Does Tag URI address your needs? If not, what is missing? If so, then >>> > would >>> > it be worth the effort to define a Tag URI registration and resolution >>> > mechanism? >>> > >>> > In any case, I am pleased to see this discussion of persistence as an >>> > important quality for names. I've long thought that too many of those >>> > who >>> > investigate the properties of naming systems are overly focused on just >>> > the >>> > three edges of Zooko's Triangle (Memorability, Global, Security) when we >>> > really should also address a fourth edge: Persistence. (We should speak >>> > of a >>> > pyramid, not a triangle...) For more on this, see an old posting of mine >>> > on >>> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: >>> > http://www.wyman.us/main/2006/12/the_persistence.html >>> > >>> > bob wyman >>> > >>> > >>> > >>> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker >>> > wrote: >>> >> >>> >> So I made a post to the IETF list yesterday in which I gave a high >>> >> level view of the Internet 2020 project and the three goals of >>> >> Security, Access and Autonomy. >>> >> >>> >> The goal of Autonomy being to make the Internet user independent of >>> >> institutional control points like ICANN and the corporations trying to >>> >> establish themselves as control points. >>> >> >>> >> ICANN is of course the one we have had concerns about for the longest >>> >> time and the autonomy problem is that I don't buy a DNS name, I can >>> >> only rent it. And that means that names that are DNS bound can always >>> >> be reassigned in the future. Which is one of the reasons why HTTP urls >>> >> are unsatisfactory. >>> >> >>> >> Larry Masinter has of course raised this sort of concern before and >>> >> proposed dated URLs. But this morning a different approach to the >>> >> problem occurred to me: >>> >> >>> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >>> >> 2010: >>> >> http://www.cnn.com/whatever.html >>> >> >>> >> Now what if I wanted to connect up today to the same party that I >>> >> connected to last time. This is not the same as the URN or the dated >>> >> URL problem. I want to connect up to the same entity regardless of >>> >> whom ICANN happen to sell the domain name to next. >>> >> >>> >> How about one of the following: >>> >> >>> >> http://www.cnn.com.2010/whatever.html >>> >> http://www.cnn.com.1.2010/whatever.html >>> >> http://www.cnn.com.1.1.2010/whatever.html >>> >> >>> >> DNS labels are not allowed to be all numbers but the DNS protocol >>> >> works for them. In fact they seem to work with my existing software >>> >> which was not a design goal but would be cool. >>> >> >>> >> >>> >> Now resolving such names would of course require a new infrastructure, >>> >> quite possibly a subscription infrastructure that would track the >>> >> changing ownership of the names over time. And this infrastructure >>> >> would probably involve Certificate Transparency like services and >>> >> DNSSEC. >>> >> >>> >> But we could use this to provide persistence for Web content and for >>> >> Web services which would be incredibly cool. >>> >> >>> >> >>> >> We can also apply the same idea to email addresses: >>> >> >>> >> phill@hallambaker.com could be anyone. >>> >> phill@hallambaker.com.16.5.2014 is uniquely my account. >>> >> >>> >> _______________________________________________ >>> >> apps-discuss mailing list >>> >> apps-discuss@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >>> > >>> > >>> > _______________________________________________ >>> > apps-discuss mailing list >>> > apps-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>> > >> >> From nobody Wed May 21 10:58:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19E71A0897 for ; Wed, 21 May 2014 10:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no 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 Efg0DcPGaNSa for ; Wed, 21 May 2014 10:58:33 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D701A0191 for ; Wed, 21 May 2014 10:58:32 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so2311697wgh.28 for ; Wed, 21 May 2014 10:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cD4WomlOaOd5dstaE+2w42yCiLOMXBQaehvTqj70fI4=; b=rADvEVcBbUa3qaZHCJ/2w6FhhEUPYBPjzVCORyiDuOTMNdsRJFpMMSy0yPjWf1cWMB J8isF9RPyVENunzmISrWPknpQOFA5tupp2rkDmLCXXa7mXcFm0NK5G7PMrT/CbJ/wQKC LZi901FZRZWtAgDRJwLZ0nodkMhQnicvsg8z5N2Xl+VMoHxdnlruAO2ud39fuYtl2DDi Cl+IKEBfRta+C94ClNUtFM6213EaN0iRfVvresN0Hq4lYicArlw+uTpuu3U3hpLwWXEm NvhjnsT+5vPsHTduzYxNvcw70bZCjTR8c9HbHhxUvUj/Pw66ZKkenITlVxLqvdQ+pKMe KWWA== MIME-Version: 1.0 X-Received: by 10.180.91.1 with SMTP id ca1mr11843969wib.32.1400695111022; Wed, 21 May 2014 10:58:31 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.134.230 with HTTP; Wed, 21 May 2014 10:58:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 13:58:30 -0400 X-Google-Sender-Auth: HpAkzSDpODtRq21REXz0YBZOi9A Message-ID: From: Bob Wyman To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d043d67df87fe8204f9ecbe6c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Xg00Jfd7p7sm5Fq_Z4AHxzPn3ls Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:58:36 -0000 --f46d043d67df87fe8204f9ecbe6c Content-Type: text/plain; charset=UTF-8 "allows a document submission system to archive copies of the linked documents." Would you only want to copy the documents linked to directly? What about the documents that they link to? How would you decide how "deep" you wanted links to be followed? And, even if copyright wasn't an issue, what about my "right to be forgotten?" I assume that you wouldn't want to force a fresh copy every time that a document is referenced unless it has changed since the last copy. What I think you would probably prefer is building your archive as a web of documents. Each document would have one or more versions and inter-document links would be modified so that they referenced specific versions of other documents. Something like tag uri or hash codes would serve your needs in this case. Of course, given a system like this, you'd probably realize that you only need to copy the documents if you can't trust them to remain accessible somewhere else. Generally, for instance, we can trust the IETF to keep copies of RFC's on-line. So, you wouldn't need to actually copy referenced RFC's -- you would accomplish the same semantic purpose by convincing the IETF to adopt some agreed upon method to identify unique versions of documents. The same goes for other sites. If copyright is an issue, this is all you could hope for... But, this leaves us with an interesting question... Does a document author have the right to have some version of a document be "forgotten?" If you've linked to a document that I wrote and I later discover that I've said something profoundly stupid in that document, do I have the right to erase it and thus prevent anyone from reading the evidence of my stupidity in the future? Perhaps Europeans would say "Yes" and thus insist that you must not copy on reference. On the other hand, others might say "No"... bob wyman On Wed, May 21, 2014 at 1:18 PM, Phillip Hallam-Baker wrote: > What I would like to see for archival storage is a mechanism that > allows a document submission system to archive copies of the linked > documents. > > Storage is cheap. Copyright is not always an obstruction. > > So for example, say I am writing an RFC, I submit the document to the > IETF, the publication system sees that it references docs X, Y, Z and > archive copies of them. > > > > On Wed, May 21, 2014 at 12:11 PM, Bob Wyman wrote: > > James, > > Since your "point in time reference," by including an Entity Tag or > > Validator, requires knowledge of the resource's attributes at the > particular > > moment of interest, it would only work if people anticipated the need to > > reference the resource at some future time and stored the pit: values. It > > wouldn't help someone who knew nothing about the attributes of > example.org > > on a particular date but was attempting to discover them. > > > > In those cases where one did anticipate the need to have a time > independent > > name for a resource, the hash you propose, since it is generated from > > timestamp, vaildator and ref-url, essentially contains all the > information > > (with some loss) of the other components, thus, it seems that one could > > economize by simply discarding those other bits. > > > > Wouldn't pit:sha-256-32:f83b2add have much the same utility as > > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add > if > > ones interest is only in the specific instance of the resource so named? > > > > bob wyman > > > > > > > > > > On Wed, May 21, 2014 at 11:39 AM, James M Snell > wrote: > >> > >> Ah, tag URI's... those bring me back. Was it really nine years ago > >> already!? While tag URI's *might* work structurally, I can see a > >> number of issues using them for this purpose -- not the least of which > >> is the fact that tag URI's provide no reliable verification. I've > >> often considered that a variation on the "Naming Things With Hashes" > >> approach (RFC 6920) could be leveraged... essentially, wrap things > >> like HTTP URI within a hashed, timestamped URI syntax that can provide > >> reliable point-in-time linking. > >> > >> It gets a bit ugly visually and certainly wouldn't be intended for > >> human readability, but something along the lines of (just a strawman) > >> > >> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add > >> > >> Where: > >> > >> pit == "point in time reference" > >> 2014-05 is the point in time being asserted > >> b0717f9a is, for lack of a better term, an Entity Tag or Validator > >> to be matched against the fetched resource (it can, for instance, > >> appear as the Entity Tag in the HTTP response) > >> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being > >> referenced at the given point in time. > >> and sha-256-32:f83b2add is the hash generated from the timestamp, > >> validator and ref url. > >> > >> The inclusion of the validator makes it possible to reference specific > >> versions of the target resource and the hash provides us with at least > >> some level of verifiability. > >> > >> It's an idea, at least. Whether or not it's a good one remains to be > seen > >> ;-) > >> > >> - James > >> > >> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: > >> > It strikes me that the Tag URI scheme defined in RFC 4151, and used by > >> > Atom, > >> > addresses the problem of "time bounded" names. Of course, the Tag URI > >> > system > >> > currently has no authoritative resolution mechanism. However, it seems > >> > that > >> > one could define and create such a thing. Thus, one could choose to > >> > either: > >> > > >> > Use "http://www.example.com/index.html" to access whatever resource > was > >> > currently so named, or > >> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps > via > >> > the > >> > Wayback Machine, or something like it, the resource as it was on Sept > >> > 15, > >> > 2001. > >> > > >> > The same would work, of course, for email addresses: > >> > > >> > "bob@example.com" would indicate the person currently assigned the > name > >> > "bob" by the mail server currently serving "example.com" > >> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a > current > >> > address for whoever had been named "bob@example.com" in 2001. That > >> > address > >> > might be something completely different, of it might resolve to > whoever > >> > was > >> > currently assigned the name (and had been since 2001). > >> > > >> > Finally, Henry S. Thompson's concern might be address by support > >> > something > >> > like "whois tag:example.com,2001-09-15" which would retrieve the > WHOIS > >> > response that one would have received had you made the request "whois > >> > example.com" on 2001-09-15. > >> > > >> > Does Tag URI address your needs? If not, what is missing? If so, then > >> > would > >> > it be worth the effort to define a Tag URI registration and resolution > >> > mechanism? > >> > > >> > In any case, I am pleased to see this discussion of persistence as an > >> > important quality for names. I've long thought that too many of those > >> > who > >> > investigate the properties of naming systems are overly focused on > just > >> > the > >> > three edges of Zooko's Triangle (Memorability, Global, Security) when > we > >> > really should also address a fourth edge: Persistence. (We should > speak > >> > of a > >> > pyramid, not a triangle...) For more on this, see an old posting of > mine > >> > on > >> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: > >> > http://www.wyman.us/main/2006/12/the_persistence.html > >> > > >> > bob wyman > >> > > >> > > >> > > >> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker > >> > wrote: > >> >> > >> >> So I made a post to the IETF list yesterday in which I gave a high > >> >> level view of the Internet 2020 project and the three goals of > >> >> Security, Access and Autonomy. > >> >> > >> >> The goal of Autonomy being to make the Internet user independent of > >> >> institutional control points like ICANN and the corporations trying > to > >> >> establish themselves as control points. > >> >> > >> >> ICANN is of course the one we have had concerns about for the longest > >> >> time and the autonomy problem is that I don't buy a DNS name, I can > >> >> only rent it. And that means that names that are DNS bound can always > >> >> be reassigned in the future. Which is one of the reasons why HTTP > urls > >> >> are unsatisfactory. > >> >> > >> >> Larry Masinter has of course raised this sort of concern before and > >> >> proposed dated URLs. But this morning a different approach to the > >> >> problem occurred to me: > >> >> > >> >> Lets take a URL at a web site and imagine I download a page on 1st > Jan > >> >> 2010: > >> >> http://www.cnn.com/whatever.html > >> >> > >> >> Now what if I wanted to connect up today to the same party that I > >> >> connected to last time. This is not the same as the URN or the dated > >> >> URL problem. I want to connect up to the same entity regardless of > >> >> whom ICANN happen to sell the domain name to next. > >> >> > >> >> How about one of the following: > >> >> > >> >> http://www.cnn.com.2010/whatever.html > >> >> http://www.cnn.com.1.2010/whatever.html > >> >> http://www.cnn.com.1.1.2010/whatever.html > >> >> > >> >> DNS labels are not allowed to be all numbers but the DNS protocol > >> >> works for them. In fact they seem to work with my existing software > >> >> which was not a design goal but would be cool. > >> >> > >> >> > >> >> Now resolving such names would of course require a new > infrastructure, > >> >> quite possibly a subscription infrastructure that would track the > >> >> changing ownership of the names over time. And this infrastructure > >> >> would probably involve Certificate Transparency like services and > >> >> DNSSEC. > >> >> > >> >> But we could use this to provide persistence for Web content and for > >> >> Web services which would be incredibly cool. > >> >> > >> >> > >> >> We can also apply the same idea to email addresses: > >> >> > >> >> phill@hallambaker.com could be anyone. > >> >> phill@hallambaker.com.16.5.2014 is uniquely my account. > >> >> > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > > > > > --f46d043d67df87fe8204f9ecbe6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"allows a document submission system to archive copies of the linked= =C2=A0do= cuments."
Would you only want to copy the documents = linked to directly? What about the documents that they link to?=C2=A0How would you decide how &quo= t;deep" you wanted links to be followed?=C2=A0And, even if copyright wasn't an issue, wha= t about my "right to be forgotten?"

I assume that you woul= dn't want to force a fresh copy every time that a document is reference= d unless it has changed since the last copy. What I think you would probabl= y prefer is building your archive as a web of documents. Each document woul= d have one or more versions and inter-document links would be modified so t= hat they referenced specific versions of other documents. Something like ta= g uri or hash codes would serve your needs in this case.

Of course, given a system like this, you'd probably r= ealize that you only need to copy the documents if you can't trust them= to remain accessible somewhere else. Generally, for instance, we can trust= the IETF to keep copies of RFC's on-line. So, you wouldn't need to= actually copy referenced RFC's -- you would accomplish the same semant= ic purpose by convincing the IETF to adopt some agreed upon method to ident= ify unique versions of documents. The same goes for other sites. If copyrig= ht is an issue, this is all you could hope for...

But, this leaves us with an interesting question... Does = a document author have the right to have some version of a document be &quo= t;forgotten?" If you've linked to a document that I wrote and I la= ter discover that I've said something profoundly stupid in that documen= t, do I have the right to erase it and thus prevent anyone from reading the= evidence of my stupidity in the future? Perhaps Europeans would say "= Yes" and thus insist that you must not copy on reference. On the other= hand, others might say "No"...

bob wyman


On Wed, May 21, 2014 at 1:18 PM, Phillip Hallam-Ba= ker <phill@hallambaker.com> wrote:
What I would like to see for archival storage is a mechani= sm that
allows a document submission system to archive copies of the linked
documents.

Storage is cheap. Copyright is not always an obstruction.

So for example, say I am writing an RFC, I submit the document to the
IETF, the publication system sees that it references docs X, Y, Z and
archive copies of them.



On Wed, May 21, 2014 at 12:11 PM, Bob Wyman <bob@wyman.us> wrote:
> James,
> Since your "point in time reference," by including an Entity= Tag or
> Validator, requires knowledge of the resource's attributes at the = particular
> moment of interest, it would only work if people anticipated the need = to
> reference the resource at some future time and stored the pit: values.= It
> wouldn't help someone who knew nothing about the attributes of example.org
> on a particular date but was attempting to discover them.
>
> In those cases where one did anticipate the need to have a time indepe= ndent
> name for a resource, the hash you propose, since it is generated from<= br> > timestamp, vaildator and ref-url, essentially contains all the informa= tion
> (with some loss) of the other components, thus, it seems that one coul= d
> economize by simply discarding those other bits.
>
> Wouldn't pit:sha-256-32:f83b2add have much the same utility as
> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2ad= d if
> ones interest is only in the specific instance of the resource so name= d?
>
> bob wyman
>
>
>
>
> On Wed, May 21, 2014 at 11:39 AM, James M Snell <jasnell@gmail.com> wrote:
>>
>> Ah, tag URI's... those bring me back. Was it really nine years= ago
>> already!? While tag URI's *might* work structurally, I can see= a
>> number of issues using them for this purpose -- not the least of w= hich
>> is the fact that tag URI's provide no reliable verification. I= 've
>> often considered that a variation on the "Naming Things With = Hashes"
>> approach (RFC 6920) could be leveraged... essentially, wrap things=
>> like HTTP URI within a hashed, timestamped URI syntax that can pro= vide
>> reliable point-in-time linking.
>>
>> It gets a bit ugly visually and certainly wouldn't be intended= for
>> human readability, but something along the lines of (just a strawm= an)
>>
>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83= b2add
>>
>> Where:
>>
>> =C2=A0 pit =3D=3D "point in time reference"
>> =C2=A0 2014-05 is the point in time being asserted
>> =C2=A0 b0717f9a is, for lack of a better term, an Entity Tag or Va= lidator
>> to be matched against the fetched resource (it can, for instance,<= br> >> appear as the Entity Tag in the HTTP response)
>> =C2=A0 http%3A%2F%2Fexample.org%2Ffoo is the actual resource being=
>> referenced at the given point in time.
>> =C2=A0 and sha-256-32:f83b2add is the hash generated from the time= stamp,
>> validator and ref url.
>>
>> The inclusion of the validator makes it possible to reference spec= ific
>> versions of the target resource and the hash provides us with at l= east
>> some level of verifiability.
>>
>> It's an idea, at least. Whether or not it's a good one rem= ains to be seen
>> ;-)
>>
>> - James
>>
>> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman <bob@wyman.us> wrote:
>> > It strikes me that the Tag URI scheme defined in RFC 4151, an= d used by
>> > Atom,
>> > addresses the problem of "time bounded" names. Of c= ourse, the Tag URI
>> > system
>> > currently has no authoritative resolution mechanism. However,= it seems
>> > that
>> > one could define and create such a thing. Thus, one could cho= ose to
>> > either:
>> >
>> > Use "http://www.example.com/index.html" to access whatever= resource was
>> > currently so named, or
>> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via
>> > the
>> > Wayback Machine, or something like it, the resource as it was= on Sept
>> > 15,
>> > 2001.
>> >
>> > The same would work, of course, for email addresses:
>> >
>> > "bob@example.com&= quot; would indicate the person currently assigned the name
>> > "bob" by the mail server currently serving "example.com"
>> > "tag:bob@exampl= e.com,2001-09-15" would attempt to resolve to a current
>> > address for whoever had been named "bob@example.com" in 2001. That
>> > address
>> > might be something completely different, of it might resolve = to whoever
>> > was
>> > currently assigned the name (and had been since 2001).
>> >
>> > Finally, Henry S. Thompson's concern might be address by = support
>> > something
>> > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS >> > response that one would have received had you made the reques= t "whois
>> > example.com<= /a>" on 2001-09-15.
>> >
>> > Does Tag URI address your needs? If not, what is missing? If = so, then
>> > would
>> > it be worth the effort to define a Tag URI registration and r= esolution
>> > mechanism?
>> >
>> > In any case, I am pleased to see this discussion of persisten= ce as an
>> > important quality for names. I've long thought that too m= any of those
>> > who
>> > investigate the properties of naming systems are overly focus= ed on just
>> > the
>> > three edges of Zooko's Triangle (Memorability, Global, Se= curity) when we
>> > really should also address a fourth edge: Persistence. (We sh= ould speak
>> > of a
>> > pyramid, not a triangle...) For more on this, see an old post= ing of mine
>> > on
>> > "The Persistence of Identity (Updating Zooko's Pyram= id)" at:
>> >
http://www.wyman.us/main/2006/12/the_persistence.htm= l
>> >
>> > bob wyman
>> >
>> >
>> >
>> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker
>> > <phill@hallambake= r.com> wrote:
>> >>
>> >> So I made a post to the IETF list yesterday in which I ga= ve a high
>> >> level view of the Internet 2020 project and the three goa= ls of
>> >> Security, Access and Autonomy.
>> >>
>> >> The goal of Autonomy being to make the Internet user inde= pendent of
>> >> institutional control points like ICANN and the corporati= ons trying to
>> >> establish themselves as control points.
>> >>
>> >> ICANN is of course the one we have had concerns about for= the longest
>> >> time and the autonomy problem is that I don't buy a D= NS name, I can
>> >> only rent it. And that means that names that are DNS boun= d can always
>> >> be reassigned in the future. Which is one of the reasons = why HTTP urls
>> >> are unsatisfactory.
>> >>
>> >> Larry Masinter has of course raised this sort of concern = before and
>> >> proposed dated URLs. But this morning a different approac= h to the
>> >> problem occurred to me:
>> >>
>> >> Lets take a URL at a web site and imagine I download a pa= ge on 1st Jan
>> >> 2010:
>> >> http://www.cnn.com/whatever.html
>> >>
>> >> Now what if I wanted to connect up today to the same part= y that I
>> >> connected to last time. This is not the same as the URN o= r the dated
>> >> URL problem. I want to connect up to the same entity rega= rdless of
>> >> whom ICANN happen to sell the domain name to next.
>> >>
>> >> How about one of the following:
>> >>
>> >> http://www.cnn.com.2010/whatever.html
>> >> http://www.cnn.com.1.2010/whatever.html
>> >> http://www.cnn.com.1.1.2010/whatever.html
>> >>
>> >> DNS labels are not allowed to be all numbers but the DNS = protocol
>> >> works for them. In fact they seem to work with my existin= g software
>> >> which was not a design goal but would be cool.
>> >>
>> >>
>> >> Now resolving such names would of course require a new in= frastructure,
>> >> quite possibly a subscription infrastructure that would t= rack the
>> >> changing ownership of the names over time. And this infra= structure
>> >> would probably involve Certificate Transparency like serv= ices and
>> >> DNSSEC.
>> >>
>> >> But we could use this to provide persistence for Web cont= ent and for
>> >> Web services which would be incredibly cool.
>> >>
>> >>
>> >> We can also apply the same idea to email addresses:
>> >>
>> >> phill@hallambake= r.com could be anyone.
>> >> phill@hallambaker.com.16.5.2014 is uniquely my account. >> >>
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@iet= f.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>
>> >
>> >
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> >
apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br> >> >
>
>

--f46d043d67df87fe8204f9ecbe6c-- From nobody Wed May 21 11:21:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9531D1A0346 for ; Wed, 21 May 2014 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 23YbRaqGEjxs for ; Wed, 21 May 2014 11:20:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EF61A0280 for ; Wed, 21 May 2014 11:20:58 -0700 (PDT) Received: (qmail 50599 invoked from network); 21 May 2014 18:20:56 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 May 2014 18:20:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165fa.537cee88.k1405; i=johnl@user.iecc.com; bh=ps543wl9nTSDMQ7IRSrFO83X4raGnK0xQygfsKjJEyI=; b=XXykWZ/Dx1a2lDF7jfqSdPrKCeQMshwJ/WRwafgkOusVW1Czq1y3wADX3QA77KxHaxaoM5up+2WR/Tvp1UQFMMEORvihBbSFjxo+6ZJZ/XfyRKUKKyh0HSFOy1f2hVLmwQMT1syyY8uiUujc0tKcbrS6mFYmDRAQEEUThDV/v+NJor3fpV1W8EZUSpnuh33AOLVpUDZXsjXvbIEl/CDDL7ouU6SHJ0ym2cGPjf5NZ6dncMv76WyV1F9z8HCiW3c1 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=165fa.537cee88.k1405; olt=johnl@user.iecc.com; bh=ps543wl9nTSDMQ7IRSrFO83X4raGnK0xQygfsKjJEyI=; b=B/nkM3AZN2rI4CKU47dMa0iuf9RkGTLd735vfYmPS/p7hZwjy1eUS9ueVEW9LutqZ1oHCbVcaLsuaY2DqIvMwiMnXqAnNtvVEgure9Z0HPckVq5aOqX3PTNPNUw5V3z08W86wOndHRbI9aZfp4Rj67AyaGIzo+iFaVnne0apdiLtadVoKBlLoeKoLvUUm2U1xZxkKQJMZLyghopUj+qmapaj1VrwF4PWN2mh+3X308aoCYsVvwagGjvASkEa4ziy Date: 21 May 2014 18:20:31 -0000 Message-ID: <20140521182031.91639.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dC-tnAzdXOfgM4iGKPpVDjwd5CA Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:20:59 -0000 In article <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >In the third paragraph of section 4: > > "... or alice@examp1e.com rather than alice@example.com." > >This doesn't read right, to me at least. The domain names aren't the same. R's, John From nobody Wed May 21 11:30:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8D1A06EE for ; Wed, 21 May 2014 11:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no 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 k4TFBTGRXBi9 for ; Wed, 21 May 2014 11:30:26 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E481A06E2 for ; Wed, 21 May 2014 11:30:26 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so8116853wiw.9 for ; Wed, 21 May 2014 11:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PWcqo+Tqvagimc9sJRhmi9P2+JOzYlsJvG4g6CoWPgs=; b=cv+ClPKyfp29Q2VqUZghxXUjWfsohdS3qEVVO9ggZKnTYqKC75J1Rd25+NIWTa0L2z UIqxwXJ2McThK2rQisbxrsylwAMiS57z1nECNDmg3azLKOzNatEBxHHrBH0KeDIvrWEW jW29/5v4CqZsLka4iOr1hQTYY/dznukiDzf1NjtrfjHwlyiYqjC5rpkww3/LrdQnYzoG O45G1VQ5XvGQlbQchnGwvoF+mIUv9aZ1hviBkT0TaWvZr4BF5OTXu98fEigYWexx7n8V ErZXfQDmVz1H7NNPseJhXM6+TrLqvPwUHHrFNlGdKxbb92GGshOy4jmxVPoC8LW5DQmn wobQ== MIME-Version: 1.0 X-Received: by 10.194.142.205 with SMTP id ry13mr4230838wjb.69.1400697024109; Wed, 21 May 2014 11:30:24 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.134.230 with HTTP; Wed, 21 May 2014 11:30:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 14:30:24 -0400 X-Google-Sender-Auth: 1Z-EtGcK4GvJ2CPf94XGqlUBA2o Message-ID: From: Bob Wyman To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e0122f1b68f635b04f9ed3096 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XKMHoJRtzsNjZ6Ct09ijsEPdzH4 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:30:29 -0000 --089e0122f1b68f635b04f9ed3096 Content-Type: text/plain; charset=UTF-8 If your primary concern is "papers" that would be actively archived by their authors upon publication, could you use something like the "Handle System" defined in RFC 3650 , RFC 3651 and RFC 3652 and which is based, in part, on Robert Kahn and Robert Wilensky's ideas for "A Framework for Distributed Object Services "? Another existing system that you might consider is the Document Object Identifier system defined by ISO 26324 . That system provides for persistent identifiers which are independent of location and time and defines a resolutionprocess to dereference these things. (See www.doi.org for more info) bob wyman On Wed, May 21, 2014 at 1:59 PM, Phillip Hallam-Baker wrote: > One simple approach would be to offer a service to allow authors to > intern their own papers into the archive on publication. > > Most of the links in my papers are to other academic and/or > professional papers. The people that publish them have much the same > copyright interest as I do. It is likely that 80%+ of the material > could be covered by a CC type license. > > > In the traditional paper based publication model, editors act as the > gate keeper on both quality and for persistence. But now space is > cheap we can change the model. > > So lets imagine we have a consortium of five university departments > that agree to maintain and publish a complete copy of an archive > repository that people can post to for free with only minimal > restrictions to keep out the kiddie porn, bomb making instructions, > etc. > > If I am writing a paper that I want to be published and be available > for free I can submit it to the archive. And then other people can > link to it as a resource. > > > Most university departments had some sort of monograph series back in > the paper days. This would be similar. > > Now obviously there are going to be papers that rely on resources that > are copyright. But remember that the purpose of copyright is to allow > authors to extract revenues. So a link to a NYT article that hits > their paywall is fine. The NYT has a business model that will support > publication of their content indefinitely. > > We could also posit some sort of permanent repository that provides > payments to the authors based on readership on the iTunes or Kindle > model. If people link to those resources they will stay in print. > > > So when we look at the persistence problem, I think the copyright > problems solve themselves because they come with a business model. Its > the free content that has the issues. > > > > On Wed, May 21, 2014 at 1:45 PM, James M Snell wrote: > > Storage is cheap yes, the potential practical/legal/privacy > > ramifications of such archives, however, may not be. The ability to > > dereference a resource's state, at a given point in time, without > > requiring the resource state to be duplicated and stored by a > > non-authoritative third party, would be an ideal solution. > > > > On Wed, May 21, 2014 at 10:18 AM, Phillip Hallam-Baker > > wrote: > >> What I would like to see for archival storage is a mechanism that > >> allows a document submission system to archive copies of the linked > >> documents. > >> > >> Storage is cheap. Copyright is not always an obstruction. > >> > >> So for example, say I am writing an RFC, I submit the document to the > >> IETF, the publication system sees that it references docs X, Y, Z and > >> archive copies of them. > >> > >> > >> > >> On Wed, May 21, 2014 at 12:11 PM, Bob Wyman wrote: > >>> James, > >>> Since your "point in time reference," by including an Entity Tag or > >>> Validator, requires knowledge of the resource's attributes at the > particular > >>> moment of interest, it would only work if people anticipated the need > to > >>> reference the resource at some future time and stored the pit: values. > It > >>> wouldn't help someone who knew nothing about the attributes of > example.org > >>> on a particular date but was attempting to discover them. > >>> > >>> In those cases where one did anticipate the need to have a time > independent > >>> name for a resource, the hash you propose, since it is generated from > >>> timestamp, vaildator and ref-url, essentially contains all the > information > >>> (with some loss) of the other components, thus, it seems that one could > >>> economize by simply discarding those other bits. > >>> > >>> Wouldn't pit:sha-256-32:f83b2add have much the same utility as > >>> > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if > >>> ones interest is only in the specific instance of the resource so > named? > >>> > >>> bob wyman > >>> > >>> > >>> > >>> > >>> On Wed, May 21, 2014 at 11:39 AM, James M Snell > wrote: > >>>> > >>>> Ah, tag URI's... those bring me back. Was it really nine years ago > >>>> already!? While tag URI's *might* work structurally, I can see a > >>>> number of issues using them for this purpose -- not the least of which > >>>> is the fact that tag URI's provide no reliable verification. I've > >>>> often considered that a variation on the "Naming Things With Hashes" > >>>> approach (RFC 6920) could be leveraged... essentially, wrap things > >>>> like HTTP URI within a hashed, timestamped URI syntax that can provide > >>>> reliable point-in-time linking. > >>>> > >>>> It gets a bit ugly visually and certainly wouldn't be intended for > >>>> human readability, but something along the lines of (just a strawman) > >>>> > >>>> > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add > >>>> > >>>> Where: > >>>> > >>>> pit == "point in time reference" > >>>> 2014-05 is the point in time being asserted > >>>> b0717f9a is, for lack of a better term, an Entity Tag or Validator > >>>> to be matched against the fetched resource (it can, for instance, > >>>> appear as the Entity Tag in the HTTP response) > >>>> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being > >>>> referenced at the given point in time. > >>>> and sha-256-32:f83b2add is the hash generated from the timestamp, > >>>> validator and ref url. > >>>> > >>>> The inclusion of the validator makes it possible to reference specific > >>>> versions of the target resource and the hash provides us with at least > >>>> some level of verifiability. > >>>> > >>>> It's an idea, at least. Whether or not it's a good one remains to be > seen > >>>> ;-) > >>>> > >>>> - James > >>>> > >>>> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: > >>>> > It strikes me that the Tag URI scheme defined in RFC 4151, and used > by > >>>> > Atom, > >>>> > addresses the problem of "time bounded" names. Of course, the Tag > URI > >>>> > system > >>>> > currently has no authoritative resolution mechanism. However, it > seems > >>>> > that > >>>> > one could define and create such a thing. Thus, one could choose to > >>>> > either: > >>>> > > >>>> > Use "http://www.example.com/index.html" to access whatever > resource was > >>>> > currently so named, or > >>>> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps > via > >>>> > the > >>>> > Wayback Machine, or something like it, the resource as it was on > Sept > >>>> > 15, > >>>> > 2001. > >>>> > > >>>> > The same would work, of course, for email addresses: > >>>> > > >>>> > "bob@example.com" would indicate the person currently assigned the > name > >>>> > "bob" by the mail server currently serving "example.com" > >>>> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a > current > >>>> > address for whoever had been named "bob@example.com" in 2001. That > >>>> > address > >>>> > might be something completely different, of it might resolve to > whoever > >>>> > was > >>>> > currently assigned the name (and had been since 2001). > >>>> > > >>>> > Finally, Henry S. Thompson's concern might be address by support > >>>> > something > >>>> > like "whois tag:example.com,2001-09-15" which would retrieve the > WHOIS > >>>> > response that one would have received had you made the request > "whois > >>>> > example.com" on 2001-09-15. > >>>> > > >>>> > Does Tag URI address your needs? If not, what is missing? If so, > then > >>>> > would > >>>> > it be worth the effort to define a Tag URI registration and > resolution > >>>> > mechanism? > >>>> > > >>>> > In any case, I am pleased to see this discussion of persistence as > an > >>>> > important quality for names. I've long thought that too many of > those > >>>> > who > >>>> > investigate the properties of naming systems are overly focused on > just > >>>> > the > >>>> > three edges of Zooko's Triangle (Memorability, Global, Security) > when we > >>>> > really should also address a fourth edge: Persistence. (We should > speak > >>>> > of a > >>>> > pyramid, not a triangle...) For more on this, see an old posting of > mine > >>>> > on > >>>> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: > >>>> > http://www.wyman.us/main/2006/12/the_persistence.html > >>>> > > >>>> > bob wyman > >>>> > > >>>> > > >>>> > > >>>> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker > >>>> > wrote: > >>>> >> > >>>> >> So I made a post to the IETF list yesterday in which I gave a high > >>>> >> level view of the Internet 2020 project and the three goals of > >>>> >> Security, Access and Autonomy. > >>>> >> > >>>> >> The goal of Autonomy being to make the Internet user independent of > >>>> >> institutional control points like ICANN and the corporations > trying to > >>>> >> establish themselves as control points. > >>>> >> > >>>> >> ICANN is of course the one we have had concerns about for the > longest > >>>> >> time and the autonomy problem is that I don't buy a DNS name, I can > >>>> >> only rent it. And that means that names that are DNS bound can > always > >>>> >> be reassigned in the future. Which is one of the reasons why HTTP > urls > >>>> >> are unsatisfactory. > >>>> >> > >>>> >> Larry Masinter has of course raised this sort of concern before and > >>>> >> proposed dated URLs. But this morning a different approach to the > >>>> >> problem occurred to me: > >>>> >> > >>>> >> Lets take a URL at a web site and imagine I download a page on 1st > Jan > >>>> >> 2010: > >>>> >> http://www.cnn.com/whatever.html > >>>> >> > >>>> >> Now what if I wanted to connect up today to the same party that I > >>>> >> connected to last time. This is not the same as the URN or the > dated > >>>> >> URL problem. I want to connect up to the same entity regardless of > >>>> >> whom ICANN happen to sell the domain name to next. > >>>> >> > >>>> >> How about one of the following: > >>>> >> > >>>> >> http://www.cnn.com.2010/whatever.html > >>>> >> http://www.cnn.com.1.2010/whatever.html > >>>> >> http://www.cnn.com.1.1.2010/whatever.html > >>>> >> > >>>> >> DNS labels are not allowed to be all numbers but the DNS protocol > >>>> >> works for them. In fact they seem to work with my existing software > >>>> >> which was not a design goal but would be cool. > >>>> >> > >>>> >> > >>>> >> Now resolving such names would of course require a new > infrastructure, > >>>> >> quite possibly a subscription infrastructure that would track the > >>>> >> changing ownership of the names over time. And this infrastructure > >>>> >> would probably involve Certificate Transparency like services and > >>>> >> DNSSEC. > >>>> >> > >>>> >> But we could use this to provide persistence for Web content and > for > >>>> >> Web services which would be incredibly cool. > >>>> >> > >>>> >> > >>>> >> We can also apply the same idea to email addresses: > >>>> >> > >>>> >> phill@hallambaker.com could be anyone. > >>>> >> phill@hallambaker.com.16.5.2014 is uniquely my account. > >>>> >> > >>>> >> _______________________________________________ > >>>> >> apps-discuss mailing list > >>>> >> apps-discuss@ietf.org > >>>> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>> > > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > apps-discuss mailing list > >>>> > apps-discuss@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/apps-discuss > >>>> > > >>> > >>> > --089e0122f1b68f635b04f9ed3096 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If your primary concern is "papers" that would b= e actively archived by their authors upon publication, could you use someth= ing like the "Handle System" defined in=C2=A0RFC 3650,=C2=A0RFC 3651=C2=A0and=C2=A0RFC 3652=C2=A0and which is based, in part, on Robert K= ahn and Robert Wilensky's ideas for "A Framework for Distributed Object Services"?=

Another existing system that you might consider is the =C2= =A0Docum= ent Object Identifier system defined by ISO 26324=C2=A0.=C2=A0That system provides for= persistent identifiers which are independent of location and time and defi= nes a resolut= ion process to dereference these things. (See www.doi.org for more info)

bob wyman



On Wed, Ma= y 21, 2014 at 1:59 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
One simple approach would be to offer a serv= ice to allow authors to
intern their own papers into the archive on publication.

Most of the links in my papers are to other academic and/or
professional papers. The people that publish them have much the same
copyright interest as I do. It is likely that 80%+ of the material
could be covered by a CC type license.


In the traditional paper based publication model, editors act as the
gate keeper on both quality and for persistence. But now space is
cheap we can change the model.

So lets imagine we have a consortium of five university departments
that agree to maintain and publish a complete copy of an archive
repository that people can post to for free with only minimal
restrictions to keep out the kiddie porn, bomb making instructions,
etc.

If I am writing a paper that I want to be published and be available
for free I can submit it to the archive. And then other people can
link to it as a resource.


Most university departments had some sort of monograph series back in
the paper days. This would be similar.

Now obviously there are going to be papers that rely on resources that
are copyright. But remember that the purpose of copyright is to allow
authors to extract revenues. So a link to a NYT article that hits
their paywall is fine. The NYT has a business model that will support
publication of their content indefinitely.

We could also posit some sort of permanent repository that provides
payments to the authors based on readership on the iTunes or Kindle
model. If people link to those resources they will stay in print.


So when we look at the persistence problem, I think the copyright
problems solve themselves because they come with a business model. Its
the free content that has the issues.



On Wed, May 21, 2014 at 1:45 PM, James M Snell <
jasnell@gmail.com> wrote:
> Storage is cheap yes, the potential practical/legal/privacy
> ramifications of such archives, however, may not be. The ability to > dereference a resource's state, at a given point in time, without<= br> > requiring the resource state to be duplicated and stored by a
> non-authoritative third party, would be an ideal solution.
>
> On Wed, May 21, 2014 at 10:18 AM, Phillip Hallam-Baker
> <phill@hallambaker.com= > wrote:
>> What I would like to see for archival storage is a mechanism that<= br> >> allows a document submission system to archive copies of the linke= d
>> documents.
>>
>> Storage is cheap. Copyright is not always an obstruction.
>>
>> So for example, say I am writing an RFC, I submit the document to = the
>> IETF, the publication system sees that it references docs X, Y, Z = and
>> archive copies of them.
>>
>>
>>
>> On Wed, May 21, 2014 at 12:11 PM, Bob Wyman <bob@wyman.us> wrote:
>>> James,
>>> Since your "point in time reference," by including a= n Entity Tag or
>>> Validator, requires knowledge of the resource's attributes= at the particular
>>> moment of interest, it would only work if people anticipated t= he need to
>>> reference the resource at some future time and stored the pit:= values. It
>>> wouldn't help someone who knew nothing about the attribute= s of example.org
>>> on a particular date but was attempting to discover them.
>>>
>>> In those cases where one did anticipate the need to have a tim= e independent
>>> name for a resource, the hash you propose, since it is generat= ed from
>>> timestamp, vaildator and ref-url, essentially contains all the= information
>>> (with some loss) of the other components, thus, it seems that = one could
>>> economize by simply discarding those other bits.
>>>
>>> Wouldn't pit:sha-256-32:f83b2add have much the same utilit= y as
>>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32= :f83b2add if
>>> ones interest is only in the specific instance of the resource= so named?
>>>
>>> bob wyman
>>>
>>>
>>>
>>>
>>> On Wed, May 21, 2014 at 11:39 AM, James M Snell <jasnell@gmail.com> wrote:
>>>>
>>>> Ah, tag URI's... those bring me back. Was it really ni= ne years ago
>>>> already!? While tag URI's *might* work structurally, I= can see a
>>>> number of issues using them for this purpose -- not the le= ast of which
>>>> is the fact that tag URI's provide no reliable verific= ation. I've
>>>> often considered that a variation on the "Naming Thin= gs With Hashes"
>>>> approach (RFC 6920) could be leveraged... essentially, wra= p things
>>>> like HTTP URI within a hashed, timestamped URI syntax that= can provide
>>>> reliable point-in-time linking.
>>>>
>>>> It gets a bit ugly visually and certainly wouldn't be = intended for
>>>> human readability, but something along the lines of (just = a strawman)
>>>>
>>>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-25= 6-32:f83b2add
>>>>
>>>> Where:
>>>>
>>>> =C2=A0 pit =3D=3D "point in time reference"
>>>> =C2=A0 2014-05 is the point in time being asserted
>>>> =C2=A0 b0717f9a is, for lack of a better term, an Entity T= ag or Validator
>>>> to be matched against the fetched resource (it can, for in= stance,
>>>> appear as the Entity Tag in the HTTP response)
>>>> =C2=A0 http%3A%2F%2Fexample.org%2Ffoo is the actual resour= ce being
>>>> referenced at the given point in time.
>>>> =C2=A0 and sha-256-32:f83b2add is the hash generated from = the timestamp,
>>>> validator and ref url.
>>>>
>>>> The inclusion of the validator makes it possible to refere= nce specific
>>>> versions of the target resource and the hash provides us w= ith at least
>>>> some level of verifiability.
>>>>
>>>> It's an idea, at least. Whether or not it's a good= one remains to be seen
>>>> ;-)
>>>>
>>>> - James
>>>>
>>>> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman <bob@wyman.us> wrote:
>>>> > It strikes me that the Tag URI scheme defined in RFC = 4151, and used by
>>>> > Atom,
>>>> > addresses the problem of "time bounded" nam= es. Of course, the Tag URI
>>>> > system
>>>> > currently has no authoritative resolution mechanism. = However, it seems
>>>> > that
>>>> > one could define and create such a thing. Thus, one c= ould choose to
>>>> > either:
>>>> >
>>>> > Use "http://www.example.com/index.html" to access = whatever resource was
>>>> > currently so named, or
>>>> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps= via
>>>> > the
>>>> > Wayback Machine, or something like it, the resource a= s it was on Sept
>>>> > 15,
>>>> > 2001.
>>>> >
>>>> > The same would work, of course, for email addresses:<= br> >>>> >
>>>> > "bob@example.= com" would indicate the person currently assigned the name
>>>> > "bob" by the mail server currently serving = "example.com"= ;
>>>> > "tag:bo= b@example.com,2001-09-15" would attempt to resolve to a current >>>> > address for whoever had been named "bob@example.com" in 2001. That
>>>> > address
>>>> > might be something completely different, of it might = resolve to whoever
>>>> > was
>>>> > currently assigned the name (and had been since 2001)= .
>>>> >
>>>> > Finally, Henry S. Thompson's concern might be add= ress by support
>>>> > something
>>>> > like "whois tag:example.com,2001-09-15" which would retrieve the = WHOIS
>>>> > response that one would have received had you made th= e request "whois
>>>> > exam= ple.com" on 2001-09-15.
>>>> >
>>>> > Does Tag URI address your needs? If not, what is miss= ing? If so, then
>>>> > would
>>>> > it be worth the effort to define a Tag URI registrati= on and resolution
>>>> > mechanism?
>>>> >
>>>> > In any case, I am pleased to see this discussion of p= ersistence as an
>>>> > important quality for names. I've long thought th= at too many of those
>>>> > who
>>>> > investigate the properties of naming systems are over= ly focused on just
>>>> > the
>>>> > three edges of Zooko's Triangle (Memorability, Gl= obal, Security) when we
>>>> > really should also address a fourth edge: Persistence= . (We should speak
>>>> > of a
>>>> > pyramid, not a triangle...) For more on this, see an = old posting of mine
>>>> > on
>>>> > "The Persistence of Identity (Updating Zooko'= ;s Pyramid)" at:
>>>> > http://www.wyman.us/main/2006/12/the_persist= ence.html
>>>> >
>>>> > bob wyman
>>>> >
>>>> >
>>>> >
>>>> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker=
>>>> > <phill@ha= llambaker.com> wrote:
>>>> >>
>>>> >> So I made a post to the IETF list yesterday in wh= ich I gave a high
>>>> >> level view of the Internet 2020 project and the t= hree goals of
>>>> >> Security, Access and Autonomy.
>>>> >>
>>>> >> The goal of Autonomy being to make the Internet u= ser independent of
>>>> >> institutional control points like ICANN and the c= orporations trying to
>>>> >> establish themselves as control points.
>>>> >>
>>>> >> ICANN is of course the one we have had concerns a= bout for the longest
>>>> >> time and the autonomy problem is that I don't= buy a DNS name, I can
>>>> >> only rent it. And that means that names that are = DNS bound can always
>>>> >> be reassigned in the future. Which is one of the = reasons why HTTP urls
>>>> >> are unsatisfactory.
>>>> >>
>>>> >> Larry Masinter has of course raised this sort of = concern before and
>>>> >> proposed dated URLs. But this morning a different= approach to the
>>>> >> problem occurred to me:
>>>> >>
>>>> >> Lets take a URL at a web site and imagine I downl= oad a page on 1st Jan
>>>> >> 2010:
>>>> >> http://www.cnn.com/whatever.html
>>>> >>
>>>> >> Now what if I wanted to connect up today to the s= ame party that I
>>>> >> connected to last time. This is not the same as t= he URN or the dated
>>>> >> URL problem. I want to connect up to the same ent= ity regardless of
>>>> >> whom ICANN happen to sell the domain name to next= .
>>>> >>
>>>> >> How about one of the following:
>>>> >>
>>>> >> http://www.cnn.com.2010/whatever.html
>>>> >> http://www.cnn.com.1.2010/whatever.html
>>>> >> http://www.cnn.com.1.1.2010/whatever.html
>>>> >>
>>>> >> DNS labels are not allowed to be all numbers but = the DNS protocol
>>>> >> works for them. In fact they seem to work with my= existing software
>>>> >> which was not a design goal but would be cool. >>>> >>
>>>> >>
>>>> >> Now resolving such names would of course require = a new infrastructure,
>>>> >> quite possibly a subscription infrastructure that= would track the
>>>> >> changing ownership of the names over time. And th= is infrastructure
>>>> >> would probably involve Certificate Transparency l= ike services and
>>>> >> DNSSEC.
>>>> >>
>>>> >> But we could use this to provide persistence for = Web content and for
>>>> >> Web services which would be incredibly cool.
>>>> >>
>>>> >>
>>>> >> We can also apply the same idea to email addresse= s:
>>>> >>
>>>> >> phill@ha= llambaker.com could be anyone.
>>>> >> phill@hallambaker.com.16.5.2014 is uniquely my ac= count.
>>>> >>
>>>> >> _______________________________________________ >>>> >> apps-discuss mailing list
>>>> >> apps-dis= cuss@ietf.org
>>>> >> https://www.ietf.org/mailman/listinfo/apps-= discuss
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > apps-discuss mailing list
>>>> > apps-discuss= @ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/apps-disc= uss
>>>> >
>>>
>>>

--089e0122f1b68f635b04f9ed3096-- From nobody Wed May 21 12:17:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D0D1A0763 for ; Wed, 21 May 2014 12:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 otO-KI_UtjJN for ; Wed, 21 May 2014 12:17:07 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404311A0732 for ; Wed, 21 May 2014 12:17:07 -0700 (PDT) Received: from [192.168.42.6] (d66-183-221-35.bchsia.telus.net [66.183.221.35]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s4LJH1Fh006031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 May 2014 12:17:03 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_0FBBAAFC-BDF6-4D03-A3EE-452FAB7C859C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Lyndon Nerenberg In-Reply-To: <20140521182031.91639.qmail@joyce.lan> Date: Wed, 21 May 2014 12:17:01 -0700 Message-Id: <8DE4AC31-5E4C-4CF3-80F7-35591C6362D8@orthanc.ca> References: <20140521182031.91639.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uMYwz5CCkUZPLM2SY471vCHiYQI Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:17:14 -0000 --Apple-Mail=_0FBBAAFC-BDF6-4D03-A3EE-452FAB7C859C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On May 21, 2014, at 11:20 AM, John Levine wrote: >> "... or alice@examp1e.com rather than alice@example.com." >> >> This doesn't read right, to me at least. > > The domain names aren't the same. Doh. I guess I need a bigger terminal font :-P --Apple-Mail=_0FBBAAFC-BDF6-4D03-A3EE-452FAB7C859C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTfPutAAoJEG8PnXiV/JnUeGMP/17luHqoVkgGv5iEvDPvqjQc G1MGhJDE+p2STWdza9e/+SD2+c+uGg4HWj/9DSALBSPoe1EgA733TswFbYYZpiFY mKG0waSKLrbL39YNPeX0XI2SPO7vuVt7tr5lhSIkAyfCYs7xIGRJiw0OOdU25OOj XFcj7gWxCZqg+PhJ4m35L0kuXwSB4VLsp0C7bqOCGTPqSv7n/RkIBO0XWcLEEpJ1 U9OaJ3+YCos8eVOoGIC1DTgaUxSpVm6DWX6yjEx7UEOzrWfpq/7A7HKHewMr7TYB NbmyspJfNS9QvVoGlK2qYQoGJ8OAvxFUAQnH5TpFEzImBA88Aex4XkfrbcVF1/TA O0NFOTxxhczuM0U/4Vj5fvufAEgXmAiGTbydAq5xMnfkcPINUhGA6G2LOLIy+yQZ gKPckzMxkEZsNedCuKS25FdMht24pYt1/LhTQKlC455Ymtlu6UzXSbw1iw5aBHTy UHi9z5r0lDtFvtEcwwTSz1ryaase1e4ydP+mmP0lGHDfBPKpQeRPtvdEgTjB245p YJnNTqlv0VCcRHaqJwfrgy94jSJnL9adAP3525dx6o8+kZXaUujL/6MXJa6loQdF x5oXYaDi3XxV0D4lQGmWQNS0aVhhqJ5i9ZoHeEJai5pM87FDuRqLJ6atbQ3elmBU 6LS+7cet1M2aIhwO5FCf =9RTg -----END PGP SIGNATURE----- --Apple-Mail=_0FBBAAFC-BDF6-4D03-A3EE-452FAB7C859C-- From nobody Wed May 21 13:54:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D741B1A03B7 for ; Wed, 21 May 2014 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 TLbs2lkm1sur for ; Wed, 21 May 2014 13:54:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 275DF1A03BE for ; Wed, 21 May 2014 13:54:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521205444.368.83172.idtracker@ietfa.amsl.com> Date: Wed, 21 May 2014 13:54:44 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-9buGGHjMrReOLXEobyFwfzu8nI Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:54:46 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-multipart-form-data", set due date to June 2014 from April 2014. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Wed May 21 15:20:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF81A03BC; Wed, 21 May 2014 15:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 19mJHydR05GL; Wed, 21 May 2014 15:20:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 022531A03C6; Wed, 21 May 2014 15:20:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521222037.31039.37550.idtracker@ietfa.amsl.com> Date: Wed, 21 May 2014 15:20:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lCuqza8t_0e03f5UQu75BnHhxAc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 22:20:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-04.txt Pages : 13 Date : 2014-05-21 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 21 15:31:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D61A03C6 for ; Wed, 21 May 2014 15:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no 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 pwsUV--PFWUw for ; Wed, 21 May 2014 15:31:28 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3971A02BC for ; Wed, 21 May 2014 15:31:27 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:56216 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WnF2f-0005wL-2l for apps-discuss@ietf.org; Thu, 22 May 2014 00:31:24 +0200 Message-ID: <537D28F8.3030202@rename-it.nl> Date: Thu, 22 May 2014 00:30:16 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140521222037.31039.37550.idtracker@ietfa.amsl.com> In-Reply-To: <20140521222037.31039.37550.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rne-S8f6pK_bq3369xs-Hge7KeE Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 22:31:30 -0000 Hi, On 5/22/2014 12:20 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Sieve Email Filtering: Detecting Duplicate Deliveries > Author : Stephan Bosch > Filename : draft-ietf-appsawg-sieve-duplicate-04.txt > Pages : 13 > Date : 2014-05-21 > > Abstract: > This document defines a new test command "duplicate" for the "Sieve" > email filtering language. This test adds the ability to detect > duplications. The main application for this new test is handling > duplicate deliveries commonly caused by mailing list subscriptions or > redirected mail addresses. The detection is normally performed by > matching the message ID to an internal list of message IDs from > previously delivered messages. For more complex applications, the > "duplicate" test can also use the content of a specific header or > other parts of the message. I received no new reviews since -03, but I made a few changes still. The text itself hasn't changed much, but, as I was working on adding one final bit, I did restructure it. These are the resulting changes: * Described the situation in which several "duplicate" tests evaluate the same ID value with different ":seconds" and ":last" arguments. Marked the resulting behavior as undefined. * Split test description into several sub-sections to give it more structure. Most notably I moved paragraphs relating to the description of the ":seconds" and ":last" arguments to a subsection near the end. I think the overall structure is better now. * Moved the statement about the limit on the number of entries in the tracking list completely to the "Security Considerations" section. After restructuring, it did not a have a place elsewhere anymore. This also implicitly resolves a comment from a while ago on the mailing list. This is likely the final version. But, if you still have comments or concerns, please let us know. Regards, Stephan. From nobody Wed May 21 15:44:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5261A0845 for ; Wed, 21 May 2014 08:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.046 X-Spam-Level: ** X-Spam-Status: No, score=2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no 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 Guj-X0OLBIGT for ; Wed, 21 May 2014 08:08:32 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03ED1A0858 for ; Wed, 21 May 2014 08:08:28 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so2109441wgh.28 for ; Wed, 21 May 2014 08:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+OyZkTVSGvIm0m8ZuqQl5LwLScG8kBKMJ3cdJA/1eaE=; b=d8w9BkVKN1cbAqfiABLfnfkTD+QL2+R7aXTmWSgYScx3Fu2UYgFOXkGilbISCHF8Es ja+iNxSkoIUq4YzzxzcI8XV2HfJ/EoJUdb/xFWznVzcvqokfXnDm8llxqeiQCafPTF/r 8srKI9d2qNFYiJu7Jt8FfoQZ61QXU6bzjpgyKn5P7jwfFvcxU0EKZ8S2IjmJRFo+9/jm o8M9+hVZzJUJgJuaL2o/GTibUXbtgcmKTFsjaUSGkt7sDh3Mdgxk9IbfGzOdS2ckhTZ5 j+aoYD4nL3wqzNui8lWe85uE124a6BnmdmU92atHk+U0Sh2pEr4Dzi+7+iKk7SJjk5/C hbuA== MIME-Version: 1.0 X-Received: by 10.194.158.132 with SMTP id wu4mr2401567wjb.96.1400684906548; Wed, 21 May 2014 08:08:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Wed, 21 May 2014 08:08:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 11:08:26 -0400 X-Google-Sender-Auth: kWPpsAuJC37q4RN5GXTBdtPh9dY Message-ID: From: Phillip Hallam-Baker To: Bob Wyman Content-Type: multipart/alternative; boundary=089e011837d24c18de04f9ea5e22 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nhypXih68Cy9C0_IOW7mZosqK4I X-Mailman-Approved-At: Wed, 21 May 2014 15:42:55 -0700 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:08:34 -0000 --089e011837d24c18de04f9ea5e22 Content-Type: text/plain; charset=UTF-8 The tag system is interesting. But there are two separate issues here 1) Access to archival content, return the content that would have been returned at date X. 2) Access to the resource that the owner of the domain in question continues to intend to provide. Providing the first means having to have a wayback machine type archive. Providing the second would require a capability that does not yet exist but could be built on top of Trans+DNSSEC. So for example, let use imagine that Wyman Oil decides to offer you $20K for wyman.us. And you want the biggest RepRap on the block so of course you take the money. Currently I have no way to reach you with an email. But under the proposal if you checkpointed your DNS name in 2013 and kept the pointers up to date, I could send you a message via bob@wyman.us.2013 No, I don't know if this would be an attractive service or a practical one. But it possibly solves one of the main problems I have had with enterprise PKI which is the mess that happens when companies merge or split or shed divisions. On Wed, May 21, 2014 at 11:00 AM, Bob Wyman wrote: > It strikes me that the Tag URI scheme defined in RFC 4151, and > used by Atom , addresses the problem > of "time bounded" names. Of course, the Tag URI system currently has no > authoritative resolution mechanism. However, it seems that one could > define and create such a thing. Thus, one could choose to either: > > - Use "http://www.example.com/index.html" to access whatever resource > was currently so named, or > - Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps > via the Wayback Machine , or > something like it, the resource as it was on Sept 15, 2001. > > The same would work, of course, for email addresses: > > - "bob@example.com" would indicate the person currently assigned the > name "bob" by the mail server currently serving "example.com" > - "tag:bob@example.com,2001-09-15" would attempt to resolve to a > current address for whoever had been named "bob@example.com" in 2001. > That address might be something completely different, of it might resolve > to whoever was currently assigned the name (and had been since 2001). > > Finally, Henry S. Thompson's concern might be address by support something > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS > response that one would have received had you made the request "whois > example.com" on 2001-09-15. > > Does Tag URI address your needs? If not, what is missing? If so, then > would it be worth the effort to define a Tag URI registration and > resolution mechanism? > > In any case, I am pleased to see this discussion of persistence as an > important quality for names. I've long thought that too many of those who > investigate the properties of naming systems are overly focused on just the > three edges of Zooko's Triangle(Memorability, Global, Security) when we really should also address a > fourth edge: Persistence. (We should speak of a pyramid, not a triangle...) > For more on this, see an old posting of mine on "The Persistence of > Identity (Updating Zooko's Pyramid)" at: > http://www.wyman.us/main/2006/12/the_persistence.html > [image: Pyramid, not triangle, of identity attributes] > > bob wyman > > > > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> So I made a post to the IETF list yesterday in which I gave a high >> level view of the Internet 2020 project and the three goals of >> Security, Access and Autonomy. >> >> The goal of Autonomy being to make the Internet user independent of >> institutional control points like ICANN and the corporations trying to >> establish themselves as control points. >> >> ICANN is of course the one we have had concerns about for the longest >> time and the autonomy problem is that I don't buy a DNS name, I can >> only rent it. And that means that names that are DNS bound can always >> be reassigned in the future. Which is one of the reasons why HTTP urls >> are unsatisfactory. >> >> Larry Masinter has of course raised this sort of concern before and >> proposed dated URLs. But this morning a different approach to the >> problem occurred to me: >> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >> 2010: >> http://www.cnn.com/whatever.html >> >> Now what if I wanted to connect up today to the same party that I >> connected to last time. This is not the same as the URN or the dated >> URL problem. I want to connect up to the same entity regardless of >> whom ICANN happen to sell the domain name to next. >> >> How about one of the following: >> >> http://www.cnn.com.2010/whatever.html >> http://www.cnn.com.1.2010/whatever.html >> http://www.cnn.com.1.1.2010/whatever.html >> >> DNS labels are not allowed to be all numbers but the DNS protocol >> works for them. In fact they seem to work with my existing software >> which was not a design goal but would be cool. >> >> >> Now resolving such names would of course require a new infrastructure, >> quite possibly a subscription infrastructure that would track the >> changing ownership of the names over time. And this infrastructure >> would probably involve Certificate Transparency like services and >> DNSSEC. >> >> But we could use this to provide persistence for Web content and for >> Web services which would be incredibly cool. >> >> >> We can also apply the same idea to email addresses: >> >> phill@hallambaker.com could be anyone. >> phill@hallambaker.com.16.5.2014 is uniquely my account. >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > --089e011837d24c18de04f9ea5e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The tag system is interesting. But there are two separate = issues here

1) Access to archival content, return the co= ntent that would have been returned at date X.

2) = Access to the resource that the owner of the domain in question continues t= o intend to provide.


Providing the first means having to have= a wayback machine type archive.

Providing the sec= ond would require a capability that does not yet exist but could be built o= n top of Trans+DNSSEC.


So for example, let use imagine that Wym= an Oil decides to offer you $20K for wyman.us. And you want the biggest RepRap on the block so of course you take the = money.=C2=A0

Currently I have no way to reach you with an email. But= under the proposal if you checkpointed your DNS name in 2013 and kept the = pointers up to date, I could send you a message via=C2=A0bob@wyman.us.2013


No, I don't know if this would be an= attractive service or a practical one. But it possibly solves one of the m= ain problems I have had with enterprise PKI which is the mess that happens = when companies merge or split or shed divisions.=C2=A0



On Wed, May 21, 2014 at 11:00 AM, Bob Wyman <<= a href=3D"mailto:bob@wyman.us" target=3D"_blank">bob@wyman.us> wrote:
It strikes me that the Tag = URI scheme defined in=C2=A0RFC 4151,=C2=A0and used by Atom, addresses the problem of &q= uot;time bounded" names. Of course, the Tag URI system currently has <= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">no authoritative resolution mechanis= m.=C2=A0However, it seems that one could define and create such a th= ing. Thus, one could choose to either:
The same would work, of course, for email addresses:
<= div>
  • "bob@= example.com" would indicate the person currently assigned the name= "bob" by the mail server currently serving "example.com"
  • "tag:bo= b@example.com,2001-09-15" would attempt to resolve to a current ad= dress for whoever had been named "bob@example.com" in 2001. That address might be s= omething completely different, of it might resolve to whoever was currently= assigned the name (and had been since 2001).
Finally, Henry S. Thompson's concern might be address by supp= ort something like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS re= sponse that one would have received had you made the request "whois example.com" on 200= 1-09-15.

Does Tag URI address your needs? If not, what is missin= g? If so, then would it be worth the effort to define a Tag URI registratio= n and resolution mechanism?

In any case, I a= m pleased to see this discussion of persistence as an important quality for= names. I've long thought that too many of those who investigate the pr= operties of naming systems are overly focused on just the three edges of Zooko's Triangle (Memorability, Global, Security) when we really= should also address a fourth edge: Persistence. (We should speak of a pyra= mid, not a triangle...) For more on this, see an old posting of mine =C2=A0= on "The Persistence of Identity (Updating Zooko's Pyramid)" a= t:=C2=A0http://www.wyman.us/main/2006/12/the_persistence.html= =C2=A0
3D"=

bob wyman



On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker <phill@hall= ambaker.com> wrote:
So I made= a post to the IETF list yesterday in which I gave a high
level view of the Internet 2020 project and the three goals of
Security, Access and Autonomy.

The goal of Autonomy being to make the Internet user independent of
institutional control points like ICANN and the corporations trying to
establish themselves as control points.

ICANN is of course the one we have had concerns about for the longest
time and the autonomy problem is that I don't buy a DNS name, I can
only rent it. And that means that names that are DNS bound can always
be reassigned in the future. Which is one of the reasons why HTTP urls
are unsatisfactory.

Larry Masinter has of course raised this sort of concern before and
proposed dated URLs. But this morning a different approach to the
problem occurred to me:

Lets take a URL at a web site and imagine I download a page on 1st Jan 2010= :
http://www.c= nn.com/whatever.html

Now what if I wanted to connect up today to the same party that I
connected to last time. This is not the same as the URN or the dated
URL problem. I want to connect up to the same entity regardless of
whom ICANN happen to sell the domain name to next.

How about one of the following:

http://= www.cnn.com.2010/whatever.html
http:= //www.cnn.com.1.2010/whatever.html
htt= p://www.cnn.com.1.1.2010/whatever.html

DNS labels are not allowed to be all numbers but the DNS protocol
works for them. In fact they seem to work with my existing software
which was not a design goal but would be cool.


Now resolving such names would of course require a new infrastructure,
quite possibly a subscription infrastructure that would track the
changing ownership of the names over time. And this infrastructure
would probably involve Certificate Transparency like services and
DNSSEC.

But we could use this to provide persistence for Web content and for
Web services which would be incredibly cool.


We can also apply the same idea to email addresses:

phill@hallambake= r.com could be anyone.
phill@hallambaker.com.16.5.2014 is uniquely my account.

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--089e011837d24c18de04f9ea5e22-- From nobody Wed May 21 15:44:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5191A0468 for ; Tue, 20 May 2014 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001] autolearn=no 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 usCjybVxojWq for ; Tue, 20 May 2014 07:59:50 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C021A0153 for ; Tue, 20 May 2014 07:59:50 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so1116263wiw.14 for ; Tue, 20 May 2014 07:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cETwtCVk48B4hZfROxyvwiyAX+5YaNRuEFCn2rnamFY=; b=0xmxUeZm8LeJfW/F3nLXWgXoM2joN6yLN3eebHyw86/SKn93Tm5LMV4CCXKVNppk31 kXgUcAbSkodxywTSHXiRglAesANr9F/CudOKqW5z90dtLtsyZQhRheWzWhRsZyJ2eyF1 yvw3UoY3woFb56QeCVc3kSZj2IYVVtLkOvngCwP9hXjSSyc+hjvM8Wu8nTWkKt02JQVY U4hJWJ6n/xGgby1kyATSKlhvYxSEPPvM1d623hIjAL1OeAoE//bdbbt4GxA15S+eADvc UA/U4GfRQSkh5WoePae3G82iHG8Q9t3uww1sptPZlhXYQ9Kx08cyMmIPimcg9FYa+9Vo LjhQ== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr2974122wjr.76.1400597988449; Tue, 20 May 2014 07:59:48 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Tue, 20 May 2014 07:59:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 10:59:48 -0400 X-Google-Sender-Auth: N3arSGFNT8alRyrprtIvaHpveOU Message-ID: From: Phillip Hallam-Baker To: "Henry S. Thompson" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KnRMZmJsQOC3kGLj1Rj9YC_bnEY X-Mailman-Approved-At: Wed, 21 May 2014 15:42:50 -0700 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:59:52 -0000 X-List-Received-Date: Tue, 20 May 2014 14:59:52 -0000 X-List-Received-Date: Tue, 20 May 2014 14:59:52 -0000 Henry is totally correct that there is no way to do this at the moment. But TRANS is currently looking at a mechanism that would create a fixed time series of X.509v3 PKIX certificates. It is a fairly straightforward matter to extend that model to DNSSEC. Basically we just output a traditional X.509 certificate (supported by all the DNSSEC libraries I know of because they are typically built on SSL libs). Then we enter that cert into the log. What nobody has proposed so far is what use TRANS+DNSSEC would be. Supporting persistent DNS name claims is that application. If I enter my DNS name in a TRANS log then my claim to the DNSSEC name lasts as long as I keep the key. As with a few of my projects, it requires work in areas A and B to produce a result that is applicable in area C. Here the mechanism is in PKI and DNS space but the utility appears in application space. On Tue, May 20, 2014 at 4:08 AM, Henry S. Thompson wrote: > Phillip Hallam-Baker writes: > >> . . . > >> http://www.cnn.com.2010/whatever.html >> http://www.cnn.com.1.2010/whatever.html >> http://www.cnn.com.1.1.2010/whatever.html > > This reminds me of one of the rather odd failings of the Internet > infrastructure: There is as far as I know no where to go to find the > answer to questions of the form implicit in the above proposal, that > is "Who was the owner of the cnn.com domain on 2010_01_01?". > > We really ought to get a requirement of public archiving of domain > name 'ownership' records into the contractual requirements on > registrars. . . > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed May 21 15:44:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D686F1A070A for ; Wed, 21 May 2014 10:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 Joi7VMs_n8h1 for ; Wed, 21 May 2014 10:18:52 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A536C1A0346 for ; Wed, 21 May 2014 10:18:51 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so2318999wes.20 for ; Wed, 21 May 2014 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MMNAUIaUGl6xLFVbdQhEkn0sc7irqWzzI4P+9uZSri0=; b=dxdJkwfrJAZEpgB6CV+xQ0d7xL+1vbp6JbmHD3+apQQIVmjvFzOpo72+oVtQtnUY2I euLSB38894UzkEeORJ/NkBkhPmFmX9MiUUg5QyyJ2pwJJxZSs24YkqVSygAeC9PGGQoq W/CKbyR9OQFgkMv+ekmn17pbDR2DFRNpa7OCtZl4+nQTd4osFGM1OQ4P7k+R/lS54G17 LUT7M4Sf0RUFCtATcvEjEhBSznBinrsLXQ3WWhGo8STpNVfoQOV51dAZSBgsfBe2JycD qtivUtzVXscoWE3zBc6E4Q4qUgAhldTlbucWNlv4b1NbsZ+sNkphftDwWW3mA+KVugop rNWw== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr11652483wib.32.1400692729335; Wed, 21 May 2014 10:18:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Wed, 21 May 2014 10:18:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 13:18:49 -0400 X-Google-Sender-Auth: t_muruhRFA7f2spw90RG3A39c0E Message-ID: From: Phillip Hallam-Baker To: Bob Wyman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5YYE1JA4TcBVXBB15S12aBpLw2g X-Mailman-Approved-At: Wed, 21 May 2014 15:43:02 -0700 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:18:54 -0000 What I would like to see for archival storage is a mechanism that allows a document submission system to archive copies of the linked documents. Storage is cheap. Copyright is not always an obstruction. So for example, say I am writing an RFC, I submit the document to the IETF, the publication system sees that it references docs X, Y, Z and archive copies of them. On Wed, May 21, 2014 at 12:11 PM, Bob Wyman wrote: > James, > Since your "point in time reference," by including an Entity Tag or > Validator, requires knowledge of the resource's attributes at the particular > moment of interest, it would only work if people anticipated the need to > reference the resource at some future time and stored the pit: values. It > wouldn't help someone who knew nothing about the attributes of example.org > on a particular date but was attempting to discover them. > > In those cases where one did anticipate the need to have a time independent > name for a resource, the hash you propose, since it is generated from > timestamp, vaildator and ref-url, essentially contains all the information > (with some loss) of the other components, thus, it seems that one could > economize by simply discarding those other bits. > > Wouldn't pit:sha-256-32:f83b2add have much the same utility as > pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if > ones interest is only in the specific instance of the resource so named? > > bob wyman > > > > > On Wed, May 21, 2014 at 11:39 AM, James M Snell wrote: >> >> Ah, tag URI's... those bring me back. Was it really nine years ago >> already!? While tag URI's *might* work structurally, I can see a >> number of issues using them for this purpose -- not the least of which >> is the fact that tag URI's provide no reliable verification. I've >> often considered that a variation on the "Naming Things With Hashes" >> approach (RFC 6920) could be leveraged... essentially, wrap things >> like HTTP URI within a hashed, timestamped URI syntax that can provide >> reliable point-in-time linking. >> >> It gets a bit ugly visually and certainly wouldn't be intended for >> human readability, but something along the lines of (just a strawman) >> >> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add >> >> Where: >> >> pit == "point in time reference" >> 2014-05 is the point in time being asserted >> b0717f9a is, for lack of a better term, an Entity Tag or Validator >> to be matched against the fetched resource (it can, for instance, >> appear as the Entity Tag in the HTTP response) >> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being >> referenced at the given point in time. >> and sha-256-32:f83b2add is the hash generated from the timestamp, >> validator and ref url. >> >> The inclusion of the validator makes it possible to reference specific >> versions of the target resource and the hash provides us with at least >> some level of verifiability. >> >> It's an idea, at least. Whether or not it's a good one remains to be seen >> ;-) >> >> - James >> >> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: >> > It strikes me that the Tag URI scheme defined in RFC 4151, and used by >> > Atom, >> > addresses the problem of "time bounded" names. Of course, the Tag URI >> > system >> > currently has no authoritative resolution mechanism. However, it seems >> > that >> > one could define and create such a thing. Thus, one could choose to >> > either: >> > >> > Use "http://www.example.com/index.html" to access whatever resource was >> > currently so named, or >> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via >> > the >> > Wayback Machine, or something like it, the resource as it was on Sept >> > 15, >> > 2001. >> > >> > The same would work, of course, for email addresses: >> > >> > "bob@example.com" would indicate the person currently assigned the name >> > "bob" by the mail server currently serving "example.com" >> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current >> > address for whoever had been named "bob@example.com" in 2001. That >> > address >> > might be something completely different, of it might resolve to whoever >> > was >> > currently assigned the name (and had been since 2001). >> > >> > Finally, Henry S. Thompson's concern might be address by support >> > something >> > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS >> > response that one would have received had you made the request "whois >> > example.com" on 2001-09-15. >> > >> > Does Tag URI address your needs? If not, what is missing? If so, then >> > would >> > it be worth the effort to define a Tag URI registration and resolution >> > mechanism? >> > >> > In any case, I am pleased to see this discussion of persistence as an >> > important quality for names. I've long thought that too many of those >> > who >> > investigate the properties of naming systems are overly focused on just >> > the >> > three edges of Zooko's Triangle (Memorability, Global, Security) when we >> > really should also address a fourth edge: Persistence. (We should speak >> > of a >> > pyramid, not a triangle...) For more on this, see an old posting of mine >> > on >> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: >> > http://www.wyman.us/main/2006/12/the_persistence.html >> > >> > bob wyman >> > >> > >> > >> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker >> > wrote: >> >> >> >> So I made a post to the IETF list yesterday in which I gave a high >> >> level view of the Internet 2020 project and the three goals of >> >> Security, Access and Autonomy. >> >> >> >> The goal of Autonomy being to make the Internet user independent of >> >> institutional control points like ICANN and the corporations trying to >> >> establish themselves as control points. >> >> >> >> ICANN is of course the one we have had concerns about for the longest >> >> time and the autonomy problem is that I don't buy a DNS name, I can >> >> only rent it. And that means that names that are DNS bound can always >> >> be reassigned in the future. Which is one of the reasons why HTTP urls >> >> are unsatisfactory. >> >> >> >> Larry Masinter has of course raised this sort of concern before and >> >> proposed dated URLs. But this morning a different approach to the >> >> problem occurred to me: >> >> >> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >> >> 2010: >> >> http://www.cnn.com/whatever.html >> >> >> >> Now what if I wanted to connect up today to the same party that I >> >> connected to last time. This is not the same as the URN or the dated >> >> URL problem. I want to connect up to the same entity regardless of >> >> whom ICANN happen to sell the domain name to next. >> >> >> >> How about one of the following: >> >> >> >> http://www.cnn.com.2010/whatever.html >> >> http://www.cnn.com.1.2010/whatever.html >> >> http://www.cnn.com.1.1.2010/whatever.html >> >> >> >> DNS labels are not allowed to be all numbers but the DNS protocol >> >> works for them. In fact they seem to work with my existing software >> >> which was not a design goal but would be cool. >> >> >> >> >> >> Now resolving such names would of course require a new infrastructure, >> >> quite possibly a subscription infrastructure that would track the >> >> changing ownership of the names over time. And this infrastructure >> >> would probably involve Certificate Transparency like services and >> >> DNSSEC. >> >> >> >> But we could use this to provide persistence for Web content and for >> >> Web services which would be incredibly cool. >> >> >> >> >> >> We can also apply the same idea to email addresses: >> >> >> >> phill@hallambaker.com could be anyone. >> >> phill@hallambaker.com.16.5.2014 is uniquely my account. >> >> >> >> _______________________________________________ >> >> apps-discuss mailing list >> >> apps-discuss@ietf.org >> >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > From nobody Wed May 21 15:44:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24331A0897 for ; Wed, 21 May 2014 11:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 m1ac43W9CADO for ; Wed, 21 May 2014 10:59:59 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D151A085B for ; Wed, 21 May 2014 10:59:58 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so3143031wiw.10 for ; Wed, 21 May 2014 10:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jpGGCyYaBtGhu3rYShZ7rMwyOfRG2WXqkM3Aicj0hnU=; b=T8PfUbCRLmQvfMhXc+aTbe2eZeLPjbKyhhYSCgB3iukq7QgeR9bhot0qziRc6znlZw t6Otnnuj4SPZVKr1lybdPValZhSMZByWzdYQCeprt4qXlh0gNCP2KclXm7dZ50U7me9h /FLCT3fUEOOnd74zFCbMgTnGs0xY+zyWPTRWmc6dc8U/UCQIFOfjEPtvzy+mQ3zW33AJ GffjQ8kVMm12UoyuuH31Vc6ZlIpZH97bNSGUOb7PxrAoWv+RZOqFePHY2nlv89D6AtLP wvT376Bo4OlPUiJVnAwFwoxI8xbuuYHpGhW+eDoJmji0F8WPGf6N7/JJzR3nfsNaufEx 1qLA== MIME-Version: 1.0 X-Received: by 10.180.91.1 with SMTP id ca1mr11850754wib.32.1400695196830; Wed, 21 May 2014 10:59:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Wed, 21 May 2014 10:59:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 13:59:56 -0400 X-Google-Sender-Auth: CJnWzwRJc_imDmZFQAwv6y4MJJI Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fqt3VzJoeRADAyZ-NWtJ0BvI-no X-Mailman-Approved-At: Wed, 21 May 2014 15:43:04 -0700 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Time bound DNS names. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:00:01 -0000 One simple approach would be to offer a service to allow authors to intern their own papers into the archive on publication. Most of the links in my papers are to other academic and/or professional papers. The people that publish them have much the same copyright interest as I do. It is likely that 80%+ of the material could be covered by a CC type license. In the traditional paper based publication model, editors act as the gate keeper on both quality and for persistence. But now space is cheap we can change the model. So lets imagine we have a consortium of five university departments that agree to maintain and publish a complete copy of an archive repository that people can post to for free with only minimal restrictions to keep out the kiddie porn, bomb making instructions, etc. If I am writing a paper that I want to be published and be available for free I can submit it to the archive. And then other people can link to it as a resource. Most university departments had some sort of monograph series back in the paper days. This would be similar. Now obviously there are going to be papers that rely on resources that are copyright. But remember that the purpose of copyright is to allow authors to extract revenues. So a link to a NYT article that hits their paywall is fine. The NYT has a business model that will support publication of their content indefinitely. We could also posit some sort of permanent repository that provides payments to the authors based on readership on the iTunes or Kindle model. If people link to those resources they will stay in print. So when we look at the persistence problem, I think the copyright problems solve themselves because they come with a business model. Its the free content that has the issues. On Wed, May 21, 2014 at 1:45 PM, James M Snell wrote: > Storage is cheap yes, the potential practical/legal/privacy > ramifications of such archives, however, may not be. The ability to > dereference a resource's state, at a given point in time, without > requiring the resource state to be duplicated and stored by a > non-authoritative third party, would be an ideal solution. > > On Wed, May 21, 2014 at 10:18 AM, Phillip Hallam-Baker > wrote: >> What I would like to see for archival storage is a mechanism that >> allows a document submission system to archive copies of the linked >> documents. >> >> Storage is cheap. Copyright is not always an obstruction. >> >> So for example, say I am writing an RFC, I submit the document to the >> IETF, the publication system sees that it references docs X, Y, Z and >> archive copies of them. >> >> >> >> On Wed, May 21, 2014 at 12:11 PM, Bob Wyman wrote: >>> James, >>> Since your "point in time reference," by including an Entity Tag or >>> Validator, requires knowledge of the resource's attributes at the particular >>> moment of interest, it would only work if people anticipated the need to >>> reference the resource at some future time and stored the pit: values. It >>> wouldn't help someone who knew nothing about the attributes of example.org >>> on a particular date but was attempting to discover them. >>> >>> In those cases where one did anticipate the need to have a time independent >>> name for a resource, the hash you propose, since it is generated from >>> timestamp, vaildator and ref-url, essentially contains all the information >>> (with some loss) of the other components, thus, it seems that one could >>> economize by simply discarding those other bits. >>> >>> Wouldn't pit:sha-256-32:f83b2add have much the same utility as >>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add if >>> ones interest is only in the specific instance of the resource so named? >>> >>> bob wyman >>> >>> >>> >>> >>> On Wed, May 21, 2014 at 11:39 AM, James M Snell wrote: >>>> >>>> Ah, tag URI's... those bring me back. Was it really nine years ago >>>> already!? While tag URI's *might* work structurally, I can see a >>>> number of issues using them for this purpose -- not the least of which >>>> is the fact that tag URI's provide no reliable verification. I've >>>> often considered that a variation on the "Naming Things With Hashes" >>>> approach (RFC 6920) could be leveraged... essentially, wrap things >>>> like HTTP URI within a hashed, timestamped URI syntax that can provide >>>> reliable point-in-time linking. >>>> >>>> It gets a bit ugly visually and certainly wouldn't be intended for >>>> human readability, but something along the lines of (just a strawman) >>>> >>>> pit:2014-05:b0717f9a:http%3A%2F%2Fexample.org%2Ffoo:sha-256-32:f83b2add >>>> >>>> Where: >>>> >>>> pit == "point in time reference" >>>> 2014-05 is the point in time being asserted >>>> b0717f9a is, for lack of a better term, an Entity Tag or Validator >>>> to be matched against the fetched resource (it can, for instance, >>>> appear as the Entity Tag in the HTTP response) >>>> http%3A%2F%2Fexample.org%2Ffoo is the actual resource being >>>> referenced at the given point in time. >>>> and sha-256-32:f83b2add is the hash generated from the timestamp, >>>> validator and ref url. >>>> >>>> The inclusion of the validator makes it possible to reference specific >>>> versions of the target resource and the hash provides us with at least >>>> some level of verifiability. >>>> >>>> It's an idea, at least. Whether or not it's a good one remains to be seen >>>> ;-) >>>> >>>> - James >>>> >>>> On Wed, May 21, 2014 at 8:00 AM, Bob Wyman wrote: >>>> > It strikes me that the Tag URI scheme defined in RFC 4151, and used by >>>> > Atom, >>>> > addresses the problem of "time bounded" names. Of course, the Tag URI >>>> > system >>>> > currently has no authoritative resolution mechanism. However, it seems >>>> > that >>>> > one could define and create such a thing. Thus, one could choose to >>>> > either: >>>> > >>>> > Use "http://www.example.com/index.html" to access whatever resource was >>>> > currently so named, or >>>> > Use "tag:www.example.com,2001-09-15:/index.html to access, perhaps via >>>> > the >>>> > Wayback Machine, or something like it, the resource as it was on Sept >>>> > 15, >>>> > 2001. >>>> > >>>> > The same would work, of course, for email addresses: >>>> > >>>> > "bob@example.com" would indicate the person currently assigned the name >>>> > "bob" by the mail server currently serving "example.com" >>>> > "tag:bob@example.com,2001-09-15" would attempt to resolve to a current >>>> > address for whoever had been named "bob@example.com" in 2001. That >>>> > address >>>> > might be something completely different, of it might resolve to whoever >>>> > was >>>> > currently assigned the name (and had been since 2001). >>>> > >>>> > Finally, Henry S. Thompson's concern might be address by support >>>> > something >>>> > like "whois tag:example.com,2001-09-15" which would retrieve the WHOIS >>>> > response that one would have received had you made the request "whois >>>> > example.com" on 2001-09-15. >>>> > >>>> > Does Tag URI address your needs? If not, what is missing? If so, then >>>> > would >>>> > it be worth the effort to define a Tag URI registration and resolution >>>> > mechanism? >>>> > >>>> > In any case, I am pleased to see this discussion of persistence as an >>>> > important quality for names. I've long thought that too many of those >>>> > who >>>> > investigate the properties of naming systems are overly focused on just >>>> > the >>>> > three edges of Zooko's Triangle (Memorability, Global, Security) when we >>>> > really should also address a fourth edge: Persistence. (We should speak >>>> > of a >>>> > pyramid, not a triangle...) For more on this, see an old posting of mine >>>> > on >>>> > "The Persistence of Identity (Updating Zooko's Pyramid)" at: >>>> > http://www.wyman.us/main/2006/12/the_persistence.html >>>> > >>>> > bob wyman >>>> > >>>> > >>>> > >>>> > On Fri, May 16, 2014 at 3:40 PM, Phillip Hallam-Baker >>>> > wrote: >>>> >> >>>> >> So I made a post to the IETF list yesterday in which I gave a high >>>> >> level view of the Internet 2020 project and the three goals of >>>> >> Security, Access and Autonomy. >>>> >> >>>> >> The goal of Autonomy being to make the Internet user independent of >>>> >> institutional control points like ICANN and the corporations trying to >>>> >> establish themselves as control points. >>>> >> >>>> >> ICANN is of course the one we have had concerns about for the longest >>>> >> time and the autonomy problem is that I don't buy a DNS name, I can >>>> >> only rent it. And that means that names that are DNS bound can always >>>> >> be reassigned in the future. Which is one of the reasons why HTTP urls >>>> >> are unsatisfactory. >>>> >> >>>> >> Larry Masinter has of course raised this sort of concern before and >>>> >> proposed dated URLs. But this morning a different approach to the >>>> >> problem occurred to me: >>>> >> >>>> >> Lets take a URL at a web site and imagine I download a page on 1st Jan >>>> >> 2010: >>>> >> http://www.cnn.com/whatever.html >>>> >> >>>> >> Now what if I wanted to connect up today to the same party that I >>>> >> connected to last time. This is not the same as the URN or the dated >>>> >> URL problem. I want to connect up to the same entity regardless of >>>> >> whom ICANN happen to sell the domain name to next. >>>> >> >>>> >> How about one of the following: >>>> >> >>>> >> http://www.cnn.com.2010/whatever.html >>>> >> http://www.cnn.com.1.2010/whatever.html >>>> >> http://www.cnn.com.1.1.2010/whatever.html >>>> >> >>>> >> DNS labels are not allowed to be all numbers but the DNS protocol >>>> >> works for them. In fact they seem to work with my existing software >>>> >> which was not a design goal but would be cool. >>>> >> >>>> >> >>>> >> Now resolving such names would of course require a new infrastructure, >>>> >> quite possibly a subscription infrastructure that would track the >>>> >> changing ownership of the names over time. And this infrastructure >>>> >> would probably involve Certificate Transparency like services and >>>> >> DNSSEC. >>>> >> >>>> >> But we could use this to provide persistence for Web content and for >>>> >> Web services which would be incredibly cool. >>>> >> >>>> >> >>>> >> We can also apply the same idea to email addresses: >>>> >> >>>> >> phill@hallambaker.com could be anyone. >>>> >> phill@hallambaker.com.16.5.2014 is uniquely my account. >>>> >> >>>> >> _______________________________________________ >>>> >> apps-discuss mailing list >>>> >> apps-discuss@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > apps-discuss mailing list >>>> > apps-discuss@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/apps-discuss >>>> > >>> >>> From nobody Wed May 21 16:07:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10B01A03C9 for ; Wed, 21 May 2014 16:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tuEUj1HBfWoj for ; Wed, 21 May 2014 16:07:33 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8031A03C7 for ; Wed, 21 May 2014 16:07:33 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so2627207wgg.33 for ; Wed, 21 May 2014 16:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zYwxsGZZnnIVRS2/cW9vEmsdsne18ew1sh2m/nG+HAs=; b=UPfAI9Y8EySexXRuaIKkvOEP8gVoeTzYbOJJv/JqcERCU51J7x29yO8SfhTHXzvBGN HzwRsaC1+biLqToNgcz2IbzTB5ExAav7MvROjAsV96/wg+8GhwsXnapfz1q9wEoBTmQb BR24qiwfvaZogfdTxuKvMGIDd62XuH9aYNhPPY4SsmqvW8c3Iqxs2RRID+OD67KVN48l CqHTQbH7fIFoG725SnwbBZGZFAWTHc8601yTzvDaSDJBUszXBpXj/8DZ8Z6VInilTgku 5bpKJs/48j3CoeeTIPIxxcyJELApPiPwdcmE26ZTkZa9ANtzMJwqTQihVny+WWHt9b51 1bUg== MIME-Version: 1.0 X-Received: by 10.180.92.103 with SMTP id cl7mr12981691wib.26.1400713651270; Wed, 21 May 2014 16:07:31 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 21 May 2014 16:07:31 -0700 (PDT) Date: Wed, 21 May 2014 16:07:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04388e499dba9104f9f10ffa Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sckiLQde_WstPJE85e2od7aJIcY Subject: [apps-discuss] draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 23:07:35 -0000 --f46d04388e499dba9104f9f10ffa Content-Type: text/plain; charset=UTF-8 Colleagues, The above draft is in "Parked" state and is in need of new authors/editors to carry it through to completion. We put out a call for this after the London meeting, and there were a few inquiries about what's involved but no commitment to pick up the torch and run with it. The draft expires tomorrow. Do we have any takers? Last call... -MSK --f46d04388e499dba9104f9f10ffa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The above draft is in "= Parked" state and is in need of new authors/editors to carry it throug= h to completion.=C2=A0 We put out a call for this after the London meeting,= and there were a few inquiries about what's involved but no commitment= to pick up the torch and run with it.

The draft expires tomorrow.=C2=A0 Do we have any takers?=C2=A0 Last cal= l...

-MSK
--f46d04388e499dba9104f9f10ffa-- From nobody Wed May 21 16:51:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA0B1A06B2 for ; Wed, 21 May 2014 16:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 LyrZCzULXKeQ for ; Wed, 21 May 2014 16:51:53 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A731A06B1 for ; Wed, 21 May 2014 16:51:53 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so8497886wiv.7 for ; Wed, 21 May 2014 16:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mpbnrwGb7GhmQzeG012z3vR7OpQoRTnMFTdzDhHo+sA=; b=pnd/lsVcsIpJH7bMP157f0Saj3bhPAL4dJHdQ7KTLwDGn6fH9hJkehq9PcfkqsZIB+ zVL7IOcQqlMYcNCe3ubb06Z4FcUTnu8E7Q0L66cdub+qbIOpsnf+DsfEBbTRh2AVwF+X gwGkYz8WeEtpnYo5ZyNNlZYIbi1bxeU8QM65Q2LohZ5fwYmIMrw2iyYNK0qb1L1p7CjB pgPxRXc9TnxUk6HarY8LYANwaZaW/3AzJZMJVzNJG/nMcTw4WObO2tVL2t90DOqy+Msl Z5LTYgoR4hbTCiKoQ9pDazz7ChKkiyLBzYCuQaVw3ItIFso+IR3Eclk8Ry/kig2HViQM 1+ow== X-Received: by 10.194.63.46 with SMTP id d14mr46687578wjs.24.1400716311169; Wed, 21 May 2014 16:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.223.68 with HTTP; Wed, 21 May 2014 16:51:31 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 21 May 2014 16:51:31 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/28hJeqRviSTgAzVGpuXP6kk4-0Y Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 23:51:54 -0000 For those who may wish to move this forward, the source xml for the xml2rfc tool can be found here: https://github.com/jasnell/specs/blob/master/mature/draft-ietf-appsawg-json-merge-patch-02.xml On Wed, May 21, 2014 at 4:07 PM, Murray S. Kucherawy wrote: > Colleagues, > > The above draft is in "Parked" state and is in need of new authors/editors > to carry it through to completion. We put out a call for this after the > London meeting, and there were a few inquiries about what's involved but no > commitment to pick up the torch and run with it. > > The draft expires tomorrow. Do we have any takers? Last call... > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu May 22 00:04:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2951A00F9 for ; Thu, 22 May 2014 00:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 bsI__lzZ7Kvn for ; Thu, 22 May 2014 00:04:51 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4BB1A00E8 for ; Thu, 22 May 2014 00:04:51 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3860FFA007F; Thu, 22 May 2014 07:04:48 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1400742287-6320-6320/11/68; Thu, 22 May 2014 07:04:47 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 22 May 2014 09:04:47 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <6f688bb5-9ac5-486a-a58d-97fea2ae553f@gulbrandsen.priv.no> In-Reply-To: <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> References: <20140521033348.13532.qmail@joyce.lan> <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/utae5mdn4EaehLBaDtvJkzN_1oY Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 07:04:53 -0000 On Wednesday, May 21, 2014 7:05:44 PM CEST, Lyndon Nerenberg wrote: > In the third paragraph of section 4: > > "... or alice@examp1e.com rather than alice@example.com." > > This doesn't read right, to me at least. I think I know what > was intended here, but this looks like a cut/paste error crept > in along the way. examp-one-e-dot-com rather than... Not a terribly plausible typo, though. Might be better to use alice@examplee.com or alice@examlpe.com. I've read through the draft and think it's fine. Arnt From nobody Thu May 22 00:33:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A521A0123 for ; Thu, 22 May 2014 00:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 NxgOyzCNxlIm for ; Thu, 22 May 2014 00:33:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3381A0108 for ; Thu, 22 May 2014 00:33:39 -0700 (PDT) Received: from Vostro3500 ([178.115.131.111]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M92ZJ-1Waxyk3gAn-00CSKL; Thu, 22 May 2014 09:33:36 +0200 From: "Markus Lanthaler" To: "'Murray S. Kucherawy'" , "'IETF Apps Discuss'" References: In-Reply-To: Date: Thu, 22 May 2014 09:33:33 +0200 Message-ID: <0aa301cf7590$25172d10$6f458730$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMIczJr6hB3oU6Sr9v2qa7OQsLYn5jaN4iA Content-Language: de X-Provags-ID: V03:K0:8Q+AYf1sC4Wq3X95jifbMp+Dhfjt8K/ln1AnknDL7aA31B3RhFw IPtl311xcviJ6e4aSsxPFsj4zTQGfLRohQasBX44ZFfYxegh4aeicYSrUNkVIo7bmc4enGD l36OaXc6ija1iPg8HeWTE323/qS1ikH5N39RruIyBt35PKyjrZ4YkG2Wxm8yfmhFbZyovPi N6eCSzBlqvN8KhW6MDbxg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YXovE7ef6OQxeiHt5bytEq2kOws Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 07:33:42 -0000 On Thursday, May 22, 2014 1:08 AM, Murray S. Kucherawy wrote: > Colleagues, > The above draft is in "Parked" state and is in need of new > authors/editors to carry it through to completion. We put out a call This is a quite important spec IMO as it documents what a lot of people = are already doing (with application/json though). > for this after the London meeting, and there were a few inquiries > about what's involved but no commitment to pick up the torch and run > with it. >=20 > The draft expires tomorrow. Do we have any takers? Last call... I have the same question :-) I would like to help but my time is = unfortunately quite constrained at the moment. Are there any major = issues that I've missed? -- Markus Lanthaler @markuslanthaler From nobody Thu May 22 02:14:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89B1A015A for ; Thu, 22 May 2014 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 UBNcHya-WMvp for ; Thu, 22 May 2014 02:14:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCE31A0060 for ; Thu, 22 May 2014 02:14:04 -0700 (PDT) Received: from DB3PRD0710HT005.eurprd07.prod.outlook.com (10.255.75.40) by AM2PR07MB0754.eurprd07.prod.outlook.com (25.160.57.26) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 09:14:01 +0000 Received: from pc6 (31.51.16.131) by pod51017.outlook.com (10.255.75.40) with Microsoft SMTP Server (TLS) id 14.16.459.0; Thu, 22 May 2014 09:14:01 +0000 Message-ID: <019a01cf759d$cd0c89e0$4001a8c0@gateway.2wire.net> From: t.petch To: John Levine , References: <20140521182031.91639.qmail@joyce.lan> Date: Thu, 22 May 2014 10:11:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [31.51.16.131] X-Forefront-PRVS: 021975AE46 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(199002)(189002)(13464003)(51704005)(51444003)(79102001)(93916002)(62966002)(74502001)(92566001)(31966008)(21056001)(50986999)(47776003)(44716002)(20776003)(62236002)(61296002)(81816999)(80022001)(99396002)(33646001)(92726001)(81686999)(19580405001)(23756003)(76482001)(15975445006)(46102001)(81342001)(83322001)(89996001)(50226001)(85852003)(77982001)(87286001)(101416001)(83072002)(84392001)(44736004)(14496001)(102836001)(4396001)(76176999)(66066001)(81542001)(86362001)(74662001)(87936001)(64706001)(88136002)(77156001)(50466002)(575784001)(19580395003)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AM2PR07MB0754; H:DB3PRD0710HT005.eurprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Qv0e6A5pG22HUMogHCNb_AqFI8o Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 09:14:07 -0000 John Some (mostly) editorial thought. "that it will never accept email" would prefer "that it does not accept email" ie you are making this RR an irrevocable commitment for all eternity such that noone can ever change their mind and later accept mail - which I find too much (I would not say 'currently does not' that simply sets off too many hares) /aserver/a server/ "with a 554 response" since 5321.MailFrom is clearly a reference to RFC5321, then this must be a reference to RFC554, no? I think you should add a [reference] here (I know, you know, those on this list know, but we should be making it clear for a wider audience) /the perpetrators /The perpetrators / "5321.MailFrom " since 554 is not a reference to an RFC, then 5321 is not an RFC either, no:-) I think you should add a [reference] the first time this is used. s.4 I think needs more work. I imagine that the perpetrators of abusive mail will react. Using a non-existent return address is part of the abuse that they revel in; one reaction could then be to switch to addresses that do not have any MX, null or otherwise. I am unsure where this then leads, but think it needs consideration. NULL MX benefits the good guys, but most of the e-mail system is about the bad guys who look for a way to cause yet more harm and this may give them ways of doing so. Almost any RFC that has anything to do with an RR appears as an update to RFC1035. I think that this should too. Should the copyright refer to material from pre-2008 or is Mark Delany (whose material dates from 2005) happy to waive his rights? Tom Petch ----- Original Message ----- From: "John Levine" To: Sent: Wednesday, May 21, 2014 7:20 PM > In article <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> you write: > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >In the third paragraph of section 4: > > > > "... or alice@examp1e.com rather than alice@example.com." > > > >This doesn't read right, to me at least. > > The domain names aren't the same. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu May 22 06:31:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A781A01B6 for ; Thu, 22 May 2014 06:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no 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 8XWzlpM-V8yZ for ; Thu, 22 May 2014 06:31:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F5D1A0147 for ; Thu, 22 May 2014 06:31:27 -0700 (PDT) Received: (qmail 21908 invoked from network); 22 May 2014 13:31:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=5593.537dfc2c.k1405; bh=ynQjYOJRV7E5l2/LVvzuoTVLNZfi0fIzuKhMm/P/63U=; b=XnVxnSQ7LsACsXQ4OwP1i9CF91rloUK5IRLAIGASEvi7dCf1JcUfQZP2b/KwgNiWSF6YIA280qzz0a4R8rrKVqdyQrUopwsILuPsK8COo3OUY8xUxAviM0xTU3Zi/KOP8AiJErcWeaApi4nStJPqnAo2cztsbtB0iW+8vka88VBoz3eeumg8Q1E6/xo7xHbu3oxfoX3/nMfVipwt3A78vOOOu/KrkfvJZsD447hrhcdBXajSJocEYYNCBDxXdI6A DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=5593.537dfc2c.k1405; bh=ynQjYOJRV7E5l2/LVvzuoTVLNZfi0fIzuKhMm/P/63U=; b=LjCv89G63HJLnPJ7+m/w/c7jrt6pcMuw27ti5E6pHZ9oApsacyxvgBRYvA7C8uSfkYU8ggXBpHk4NuJUoERVzD/7tHh8fHCuXYE5c0k0m3wKA5ZN46KdtJ+E0AmuTEsk3vkmRtjOaM2pBns2m7wPeDtTLHBuzLhdhwOlbNcwSSUk5RTcw3v1Lc1qYXTmi00MIkHrbmNaSnKNp6V+q6doHxfBPOTL2Jh+QG4ZBoyvUjsR3mogKjMJxkBnapEuUfts Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 22 May 2014 13:31:24 -0000 Date: 22 May 2014 09:31:23 -0400 Message-ID: From: "John R Levine" To: "t.petch" In-Reply-To: <019a01cf759d$cd0c89e0$4001a8c0@gateway.2wire.net> References: <20140521182031.91639.qmail@joyce.lan> <019a01cf759d$cd0c89e0$4001a8c0@gateway.2wire.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6B2Nglu-yggbXAORIPCJu6YE5Q0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:31:29 -0000 Thanks, I'll work these in when I do the next draft. In practice, these days spammers usually use return addresses in real domains, so that isn't a particularly strong factor either way. The place where I see it being useful is more for people who don't know their own address and imagine that every domain name starts with www. R's, John On Thu, 22 May 2014, t.petch wrote: > John > > Some (mostly) editorial thought. > > "that it will never accept email" > would prefer > "that it does not accept email" > ie you are making this RR an irrevocable commitment for all eternity > such that noone can ever change their mind and later accept mail - which > I find too much (I would not say 'currently does not' that simply sets > off too many hares) > > /aserver/a server/ > > "with a 554 response" > since 5321.MailFrom is clearly a reference to RFC5321, then this must be > a reference to RFC554, no? I think you should add a [reference] here (I > know, you know, those on this list know, but we should be making it > clear for a wider audience) > > /the perpetrators /The perpetrators / > > "5321.MailFrom " > since 554 is not a reference to an RFC, then 5321 is not an RFC either, > no:-) I think you should add a [reference] the first time this is used. > > s.4 I think needs more work. > > I imagine that the perpetrators of abusive mail will react. Using a > non-existent return address is part of the abuse that they revel in; one > reaction could then be to switch to addresses that do not have any MX, > null or otherwise. I am unsure where this then leads, but think it > needs consideration. NULL MX benefits the good guys, but most of the > e-mail system is about the bad guys who look for a way to cause yet more > harm and this may give them ways of doing so. > > > Almost any RFC that has anything to do with an RR appears as an update > to RFC1035. I think that this should too. > > Should the copyright refer to material from pre-2008 or is Mark Delany > (whose material dates from 2005) happy to waive his rights? > > Tom Petch > > ----- Original Message ----- > From: "John Levine" > To: > Sent: Wednesday, May 21, 2014 7:20 PM > >> In article <3B32785F-BF53-47C5-A785-F984D0A090DF@orthanc.ca> you > write: >>> -=-=-=-=-=- >>> -=-=-=-=-=- >>> >>> In the third paragraph of section 4: >>> >>> "... or alice@examp1e.com rather than alice@example.com." >>> >>> This doesn't read right, to me at least. >> >> The domain names aren't the same. >> >> R's, >> John >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu May 22 07:11:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7370D1A017A for ; Thu, 22 May 2014 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nshCM8nfah13 for ; Thu, 22 May 2014 07:11:43 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF401A01BA for ; Thu, 22 May 2014 07:11:43 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 576DDFA007F; Thu, 22 May 2014 14:11:40 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1400767899-6320-6320/11/73; Thu, 22 May 2014 14:11:39 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 22 May 2014 16:11:39 +0200 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <3ba6961c-1ec8-45bd-b63a-59d7541a7cda@gulbrandsen.priv.no> In-Reply-To: References: <20140521182031.91639.qmail@joyce.lan> <019a01cf759d$cd0c89e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SgYXnEt_y8Kt7y21_WVBJ4jXUIU Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:11:49 -0000 It doesn't really matter whether it's useful. What you're doing is documenting current practice, whether sound or not. (Unless it's past practice by now?) Arnt From nobody Thu May 22 09:41:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3C1A00E2; Wed, 21 May 2014 23:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ahg4w6u7KTC1; Wed, 21 May 2014 23:44:00 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B2EBF1A00DD; Wed, 21 May 2014 23:44:00 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4F4012B454E; Thu, 22 May 2014 07:43:59 +0100 (BST) Received: from Gorry-2.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5016F2B4075; Thu, 22 May 2014 07:43:58 +0100 (BST) Message-ID: <537D9CAC.8000200@erg.abdn.ac.uk> Date: Thu, 22 May 2014 07:43:56 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, tsvwg-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/it5gKqzPemHkZqH5f5fREcazulk X-Mailman-Approved-At: Thu, 22 May 2014 09:41:30 -0700 Subject: [apps-discuss] TSVWG WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 06:44:02 -0000 Apps people, The TSV WG has started a WGLC on the above document and would be interested in receiving feedback on this draft. The document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. Please use the tsvwg@ietf.org list for discussion. James, David, and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org -------------------------------------------------------------------------- Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) From: "Gorry Fairhurst" Date: Thu, May 22, 2014 7:35 am To: tsvwg@ietf.org -------------------------------------------------------------------------- This email announces the start of a working group last call to confirm publication of "Recommendations for Transport Port Uses". The TSV WG is requesting feedback on this document with the intention to proceed to publish this as a BCP. Please send any comments to the TSVWG list (tsvwg@ietf.org). The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 The last call will run for TWO weeks, ending midnight 6th June. James, David, and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org From joejob357@gmail.com Thu May 22 06:08:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5BE1A001A for ; Thu, 22 May 2014 06:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 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 CzWHpBqQNiR6 for ; Thu, 22 May 2014 06:08:43 -0700 (PDT) Received: from mail-ob0-x244.google.com (mail-ob0-x244.google.com [IPv6:2607:f8b0:4003:c01::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B6B1A0091 for ; Thu, 22 May 2014 06:08:43 -0700 (PDT) Received: by mail-ob0-f196.google.com with SMTP id wo20so1138527obc.7 for ; Thu, 22 May 2014 06:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=L0aQag+VGPZqsBCFVg8NtrPgX1/aS9nglNp32Q3AWec=; b=uSDqP4z3NPd9hvok0Zj7b9q8NhadG5zRwpSnE9JDx/GoiT+/QxEgq83/8SfVCh5l9z VZasXjnNfgItze4YHgrM1+z5FWl8rsLKBDroOSsnDUun/ceZd6UOlHHHlqyRaqAi9xmw qW77kYzQ+F6TNTkfOjzJUP38g7D2PxfKHXJXyHHcA7iQSGvhUooQMiPLfq0jjxN2TpdY BzVflIEMDT1Ez2zibBYOEah5WkQF+UkZl+EhDuDSd9bQ+nSSTnb8cRFcroxVYBPJrIVG HF74T2OPAKFOQ5oxpaqjC5nJqAmyYxu/EcspjhU9aF1jaZ5b2lKHecaDQ+3wa4au2Ww5 w0qg== MIME-Version: 1.0 X-Received: by 10.60.84.204 with SMTP id b12mr23749907oez.8.1400764122198; Thu, 22 May 2014 06:08:42 -0700 (PDT) Received: by 10.76.94.48 with HTTP; Thu, 22 May 2014 06:08:42 -0700 (PDT) Date: Thu, 22 May 2014 14:08:42 +0100 Message-ID: From: Joe Job To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e01184b28eaf94804f9fccf64 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YEXhVpm4Nyh_NUYerbM7sus_KmU X-Mailman-Approved-At: Thu, 22 May 2014 09:42:19 -0700 Subject: [apps-discuss] Teaching a Bot How to Create a Resource X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:10:01 -0000 --089e01184b28eaf94804f9fccf64 Content-Type: text/plain; charset=UTF-8 Forgive me if this question is inappropriate for this list, but I've been reading standards documents for days trying to answer this question to no avail. Consider an automated API client that wants to create a resource knowing: * The API's "billboard URL" * That to create a resource without knowing its URL you POST * The resource's media type. How does the client discover the URL to POST to? The principles of Web Linking don't appear to be much help here for two reasons: * Links implicitly describe a representation received with GET. The URL to which a new representation can be POSTed is unlikely to respond to a GET with the same media type it creates. * There doesn't seem to be a link relation that captures the idea of a target URL that creates a resource of a different type than the context URL. `create-form` is registered as "The target IRI points to a resource where a submission form can be obtained.", but RFC6861 defines that it "indicates a target resource that represents a form that can be used to append a new member to the link context." ( http://tools.ietf.org/html/rfc6861#section-3.1) The latter definition implies the context is a collection and the form will create a member of that collection, whereas in this example the client does not want to create a member of the billboard URL's collection---nor is there such a collection---but a member of a collection linked from the billboard URL. If we use IANA's description, and gloss over what a generic form is, then the billboard URL could link to its sub-resources with this relation. In this case, the client only needs to distinguish between links with this relation. With `Accept-Post`, the client could proceed by visiting each link with the `create-form` relation, then comparing its desired media type to those advertised by the resource. However, in general the media type alone isn't sufficient to describe a resource, hence the `type`, `profile`, `describedby`, and similar relations. In my case I'll probably use JSON-LD as the media type, and a schema from schema.org to describe the resource. Then the client needs to know only an opaque schema identifier and the media type. This fits perfectly with the example in RFC6903 of rel `type`, but how do I declare a resource that can mint instances of this media type and rel type combination? A resource describes itself as having these properties is implicitly describing its GETable representation, or "form". `Accept-Post` doesn't seem to help here because its granularity is the media type. The closest I can come is having the client crawl the API until it finds a resource with the right media type and rel `type`, follow a `create-form` link from there, then POST to that URL. I'm hoping there's a more elegant solution. -Ben --089e01184b28eaf94804f9fccf64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forgive me if this question is inappropriate for this= list, but I've been reading standards documents for days trying to ans= wer this question to no avail.

Consider an automated API client that= wants to create a resource knowing:

* The API's "billboard URL"
* That to create a resourc= e without knowing its URL you POST
* The resource's media type.
<= br>How does the client discover the URL to POST to? The principles of Web L= inking don't appear to be much help here for two reasons:

* Links implicitly describe a representation received with GET. The URL= to which a new representation can be POSTed is unlikely to respond to a GE= T with the same media type it creates.
* There doesn't seem to be a = link relation that captures the idea of a target URL that creates a resourc= e of a different type than the context URL. `create-form` is registered as = "The target IRI points to a resource where a submission form can be ob= tained.", but RFC6861 defines that it "indicates a target resourc= e that represents a form that can be used to append a new member to the lin= k context." (http://tools.ietf.org/html/rfc6861#section-3.1) The latter definition= implies the context is a collection and the form will create a member of t= hat collection, whereas in this example the client does not want to create = a member of the billboard URL's collection---nor is there such a collec= tion---but a member of a collection linked from the billboard URL. If we us= e IANA's description, and gloss over what a generic form is, then the b= illboard URL could link to its sub-resources with this relation. In this ca= se, the client only needs to distinguish between links with this relation.<= br>
With `Accept-Post`, the client could proceed by visiting each link with= the `create-form` relation, then comparing its desired media type to those= advertised by the resource.

However, in general the media type alon= e isn't sufficient to describe a resource, hence the `type`, `profile`,= `describedby`, and similar relations. In my case I'll probably use JSO= N-LD as the media type, and a schema from sch= ema.org to describe the resource. Then the client needs to know only an= opaque schema identifier and the media type. This fits perfectly with the = example in RFC6903 of rel `type`, but how do I declare a resource that can = mint instances of this media type and rel type combination? A resource desc= ribes itself as having these properties is implicitly describing its GETabl= e representation, or "form". `Accept-Post` doesn't seem to he= lp here because its granularity is the media type. The closest I can come i= s having the client crawl the API until it finds a resource with the right = media type and rel `type`, follow a `create-form` link from there, then POS= T to that URL. I'm hoping there's a more elegant solution.

-Ben
--089e01184b28eaf94804f9fccf64-- From nobody Thu May 22 09:46:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA921A020F for ; Thu, 22 May 2014 09:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 2BgG0XXtEiVP for ; Thu, 22 May 2014 09:46:07 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1297F1A022A for ; Thu, 22 May 2014 09:46:05 -0700 (PDT) Received: from mobile-166-137-176-122.mycingular.net ([166.137.176.122] helo=dretair11.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WnW82-00051y-MU; Thu, 22 May 2014 09:46:03 -0700 Message-ID: <537E29C7.7090701@berkeley.edu> Date: Thu, 22 May 2014 09:45:59 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Job , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XBIeZvk2VAY8tOLEgIIftFlFnFc Subject: Re: [apps-discuss] Teaching a Bot How to Create a Resource X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:46:09 -0000 hello joe. On 2014-05-22, 6:08, Joe Job wrote: > * Links implicitly describe a representation received with GET. The URL > to which a new representation can be POSTed is unlikely to respond to a > GET with the same media type it creates. maybe of interest to you: Accept-Patch: http://tools.ietf.org/html/rfc5789#section-3.1 Accept-Post: http://tools.ietf.org/html/draft-wilde-accept-post-02 cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Thu May 22 10:27:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170781A024B for ; Thu, 22 May 2014 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 wGh0StkyTtfs for ; Thu, 22 May 2014 10:27:22 -0700 (PDT) Received: from mout-xforward.gmx.net (mout-xforward.gmx.net [82.165.159.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB161A0248 for ; Thu, 22 May 2014 10:27:22 -0700 (PDT) Received: from Vostro3500 ([77.119.128.31]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lmazv-1XMaLF0gOB-00aGm3; Thu, 22 May 2014 19:27:18 +0200 From: "Markus Lanthaler" To: References: In-Reply-To: Date: Thu, 22 May 2014 19:27:17 +0200 Message-ID: <0ba001cf75e3$15992de0$40cb89a0$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJfTH4S+dE1tod/TrPAlnNFHSpU0ZotKvvA Content-Language: de X-Provags-ID: V03:K0:iHtL/yb5HXXlIF0TuOgH3nacvWu/i1JbnRWkCCn+jqkP7yUdgfm 2hSrsoDg+kfcoRNSXI6ove84EQ7swyQsgu71IvWM/i3Suj/sKyoq9YQNJnwzFETZGMUBcTY Lkjh2Ypp2qSgQBpFmepGdNO/0C8I+NScffbsM/W4SCg+3N86h1WY375J6zsXTe7gnMRp9zL vx/DqnnLv6EI8v6zqinyQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YIPc7x708cPiP9LEiZzhVE4HwLA Cc: 'Joe Job' Subject: Re: [apps-discuss] Teaching a Bot How to Create a Resource X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:27:25 -0000 On Thursday, May 22, 2014 3:09 PM, Joe Job wrote: > Consider an automated API client that wants to create a resource > knowing: >=20 > * The API's "billboard URL" > * That to create a resource without knowing its URL you POST > * The resource's media type. >=20 > How does the client discover the URL to POST to? The principles of Web > Linking don't appear to be much help here for two reasons: >=20 [...] >=20 > However, in general the media type alone isn't sufficient to describe > a resource, hence the `type`, `profile`, `describedby`, and similar > relations. In my case I'll probably use JSON-LD as the media type, and > a schema from schema.org to describe the resource. Then the client > needs to know only an opaque schema identifier and the media type. > This fits perfectly with the example in RFC6903 of rel `type`, but how > do I declare a resource that can mint instances of this media type and > rel type combination?=20 You should probably have a look at Hydra [1] (there's a little demo at = [2]). If you find it interesting, you should join the Hydra W3C = Community Group [3] which is working on its further development. There's = also a mailing list dedicated to Hydra at W3C [4]. HTH, Markus [1] http://bit.ly/HydraED [2] http://bit.ly/hydra-api-demo [3] http://bit.ly/HydraCG [4] public-hydra@w3.org -- Markus Lanthaler @markuslanthaler From nobody Thu May 22 11:16:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5D1A024F for ; Thu, 22 May 2014 11:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 kUMb0m7tPEII for ; Thu, 22 May 2014 11:16:35 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ADF1A024B for ; Thu, 22 May 2014 11:16:34 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so3840747wes.16 for ; Thu, 22 May 2014 11:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jbMTtsRj63ph38ytQ9a6XmNLAD7Jny5mXwvyYMM+WVk=; b=Ib9ALAFWuZ+jJYedZN89Syd3tcM5PDXqDsVB/HWpcybCeF9/X7yAaUW0nzJXgusyji I5E3WT4Z+JncRVD+YsfHs+P+8qxaNp+jXJMUh73jbYJKPRXvp6mF1sDIqqickgrhqUK8 ZPcOvAlwQY+YjB5f4cSBEWTBT+7Jko/4DZl3YFwAx95wM8Si0/HCnlKkLFxhDEVjK8P1 qHyLJkVYIsvoM1ma2yfKiSTmG0tcah13UXnEpDE5NZnojSyttImmheoVk4M91A/Y/SYO BNL1pYbPhv1Pzi9kLiuTO8qguyIgza7bXhf1BfrzHgYiMTwLxJYM/FHSkmU829f5gfqm ShlA== X-Gm-Message-State: ALoCoQkG9bOXAgJ9Hq/QawAwKwX+9v5AA/kU7/hwxEo/TzR70PAM0AeA2gswR6kmL/4MZOhZK4oR MIME-Version: 1.0 X-Received: by 10.180.80.232 with SMTP id u8mr18045563wix.13.1400782592362; Thu, 22 May 2014 11:16:32 -0700 (PDT) Sender: mark@coactus.com Received: by 10.194.23.71 with HTTP; Thu, 22 May 2014 11:16:31 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: Date: Thu, 22 May 2014 14:16:31 -0400 X-Google-Sender-Auth: iSaTCgJ9mIKRscRlEOD8WkMxmnE Message-ID: From: Mark Baker To: Joe Job Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2YSwiO-u8qVNLjyxvtQZhg1wtQ4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Teaching a Bot How to Create a Resource X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:16:36 -0000 On Thu, May 22, 2014 at 9:08 AM, Joe Job wrote: > Forgive me if this question is inappropriate for this list, but I've been > reading standards documents for days trying to answer this question to no > avail. > > Consider an automated API client that wants to create a resource knowing: > > * The API's "billboard URL" > * That to create a resource without knowing its URL you POST The thing is, if you're using POST then your client will only know whether a resource was created if it receives a 201 response. Otherwise it's just data into the ether, per POST's rather opaque semantics. If your client really needs to explicitly request the creation of a resource, you need an HTTP method for that. Have you tried working out a PUT based solution? From nobody Fri May 23 00:21:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE921A00E1; Fri, 23 May 2014 00:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 enY6cMIrDu8m; Fri, 23 May 2014 00:21:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AAA1A00FD; Fri, 23 May 2014 00:21:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523072149.24698.33345.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 00:21:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/igy5jOM2U2xXL8KLy_-5yi-C7Bo Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 07:21:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-05.txt Pages : 13 Date : 2014-05-23 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 00:27:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377321A0110 for ; Fri, 23 May 2014 00:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no 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 Qm0iGeZm_yGS for ; Fri, 23 May 2014 00:27:24 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0811A00DA for ; Fri, 23 May 2014 00:27:23 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:54092 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Wnjsp-0000Sl-Vj for apps-discuss@ietf.org; Fri, 23 May 2014 09:27:20 +0200 Message-ID: <537EF7EA.9070705@rename-it.nl> Date: Fri, 23 May 2014 09:25:30 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140523072149.24698.33345.idtracker@ietfa.amsl.com> In-Reply-To: <20140523072149.24698.33345.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D5LQbNzFR4DOsUwBm_YnUsTixWI Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 07:27:26 -0000 On 5/23/2014 9:21 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Sieve Email Filtering: Detecting Duplicate Deliveries > Author : Stephan Bosch > Filename : draft-ietf-appsawg-sieve-duplicate-05.txt > Pages : 13 > Date : 2014-05-23 > > Abstract: > This document defines a new test command "duplicate" for the "Sieve" > email filtering language. This test adds the ability to detect > duplications. The main application for this new test is handling > duplicate deliveries commonly caused by mailing list subscriptions or > redirected mail addresses. The detection is normally performed by > matching the message ID to an internal list of message IDs from > previously delivered messages. For more complex applications, the > "duplicate" test can also use the content of a specific header or > other parts of the message. Made a few small changes: * Revised the new paragraph about multiple "duplicate" commands evaluating the same ID value based on comment by Ned. * Changed NOT RECOMMENDED to SHOULD NOT based on Idnits warning. Regards, Stephan. From nobody Fri May 23 01:09:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C801A03AD for ; Fri, 23 May 2014 01:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 bfVb_aDsHdP2 for ; Fri, 23 May 2014 01:09:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7801A03C0 for ; Fri, 23 May 2014 01:09:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523080907.25571.42983.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 01:09:07 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZgKbxO8dnIpCqhpWihPG8PLa3CI Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 08:09:09 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-sieve-duplicate", resolved as "Done". URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Fri May 23 06:48:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07011A04B8; Fri, 23 May 2014 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 1sGHuDuu0PaU; Fri, 23 May 2014 06:48:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5580A1A04B7; Fri, 23 May 2014 06:48:12 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s4NDlvLJ011180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 May 2014 08:47:58 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s4NDlvBk020367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 May 2014 08:47:57 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s4NDlv79013281; Fri, 23 May 2014 08:47:57 -0500 (CDT) Message-ID: <537F520E.3060501@bell-labs.com> Date: Fri, 23 May 2014 08:50:06 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-mmusic-latching@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Sa1nSGCnWk-CIay0JEuF4tBK1oo Cc: IESG IESG , mmusic Subject: [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:48:20 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mmusic-latching-05 Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Reviewer: Vijay K. Gurbani Review Date: May 23-2014 IETF Last Call Date: May-28-2014 IESG Telechat Date: May-29-2014 Summary: This draft is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication. The draft captures excellent discussions on latching and provides a great overview on what it is, how it works, and despite its simplicity, why not to use it. However, the tone of the draft should change from colloquial to something more objective (various examples of this in the Nits section). Major: 0 Minor: numerous (see below) Nits: numerous (see below) Minor: - S1, second to last paragraph: Not sure I understand what you mean by The SIP signaling-layer component of HNT is typically more implementation-specific and deployment-specific than the SDP and media components. SDP is as much of a standard as SIP is, no? Maybe you mean to say that because of the complexity of representing SIP messages, the SIP portion of a RTC component's stack may vary between implementations and deploy- ments. SDP, being a simpler protocol (at least syntactically), is not exposed to such vagaries. Yes? - S3, second paragraph: "newly introduced media relay" --- newly introduced to who? Perhaps you mean "a media relay incorporated into session establishment"? Is this paragraph saying that the SBC and media relay may be co-located on the same host? - S4, the descriptional steps below the text "The latching mechanism works as follows:" will be improved if you used "UAC" or "UAS" instead of "UA" (I recognize that in SIP it is not necessary that the UAC make the first offer, but these steps are for illustrative purposes and it helps to be as clear as we can for neophyte readers). Even much better if you could cast the actors in terms of the principals Alice and Bob that appear in Figures 2. So, something like "After receving an offer from Alice (UAC) who is behind a NAT" is preferable (I think) to "After receiving an offer from a NATed UA". - S4, the numbered steps in Figure 2: change UAC to Alice in all of the steps, and change UAS to Bob in all of the steps. Easier for neophyte readers to follow. Alternatively, you may put "(UAC)" above Alice and "(UAS)" above Bob to impart the same semantics. - S4, Figure 2: the text between step 12 and step 13 ("(SBC latches to source IP address and port seen in (10))" --- what is this referring to? Is it referring to the latching created by Alice? or Bob? It is not clear, specially since I am not sure if the "(10)" in the text I quote is a typo or not. Maybe you meant "(7)" or maybe "(2)"? - S4, Figure 2, step 13: Much as you do in step 11, you should spell out the "dest" field here as well. So, s/RTP/RTP, dest=198.51.100.2:22007/ - S5, first paragraph, line 12: s/onto packets/onto media packets/ - S5, first paragraph, line 14: "... a range of IP addresses belonging to the same network..." Here, "same" as which one? I suspect you mean the attacker's network. But being explicit is better here. - S5, first paragraph, towards the end: "widen the gap for potential attackers..." Here, I suspect you mean that it provides the attackers more IP address from which to mount attacks, i.e., advantage: attackers. Yes? - S5, second paragraph: s/In all/All/ - S5, second paragraph: s/disturb media/impact media/ - S5, third paragraph: s/since the SBC will not latch onto the attacker's packets./since the SBC will not latch onto the attacker's media packets, not having seen the corresponding signaling packets first./ - S5, third paragraph: I am not sure I understand case (2). Why would an SBC latch on to an attacker if it is using restricted latching? Teasing this case further, if the legitimate user hangs up the call because it is not getting any media packets, then a BYE should go through the SBC causing it to discard latched states, thereby preventing any more media packets from going to the attacker. Assuming that the attacker had inserted itself as a man-in-the-middle and was relaying packets to the UA, then sure, the legitimate user will not hang up and continue conversing. The case of a non-human user (answering machine) is redundant since the behaviour of the user (non-human or otherwise) is essentially the same. - S5, fourth paragraph: "For example, in cases where end-to-end encryption is used it would still be possible for an attacker to hijack a session despite the use of SRTP and perform a denial of service attack. However, media integrity would not be compromised." Can you explain more broadly how the above would work? If we assume that the endpoints exchange keys end-to-end and create secure channels end-to-end, how would the attacker hijack a session? (Heartbleed and all such mechanisms aside, of course. If we assume keys are derived end-to-end and don't follow the hop-by-hop model, how would the attacker prevail?) Nits: - Abstract, 3rd paragraph: s/components of the HNT components/components of HNT/ In fact, the entire 3rd paragraph could be written more succinctly as follows: Latching, one of the components of HNT, has a number of security issues detailed in this document. Based on the known threats, the IETF advises against use of this mechanism on the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol. - S1, second paragraph: s/They use IP/These protocols use IP/ - S1, second paragraph: s/as, in the/as, and in the/ - S1, fourth paragraph: s/some manufacturers sometimes/a number of manufacturers sometimes/ - S1, fifth paragraph: s/creation time/publication/ - S1, fifth paragraph: s/in the foreseeable/for the foreseeable/ - S1, sixth paragraph: s/are not novel to experts/are well known in the community/ - S1, seventh paragraph: s/In no way does this document/This document does not/ - S4, first paragraph: s/couple/tuple/ - S4, Figure 3: why not use the principals Alice and Bob here as well instead of "XMPP Client 1" and "XMPP Client 2"? - S5, last sentence of second-to-last paragraph: s/However it is sometimes argued that, neither S/MIME nor [RFC4474] are widely deployed and that this may not be a real concern./However, neither S/MIME or [RFC4474] are widely deployed, thus not being able to sign/verify requests appear not to be a concern at this time./ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri May 23 07:40:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447411A017A for ; Fri, 23 May 2014 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fpE1aeN7UZLn for ; Fri, 23 May 2014 07:40:02 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE501A0168 for ; Fri, 23 May 2014 07:40:02 -0700 (PDT) Received: from [192.168.2.116] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 984FFCB46 for ; Fri, 23 May 2014 10:40:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <20140521033348.13532.qmail@joyce.lan> Date: Fri, 23 May 2014 10:39:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <565A03A1-A2DB-43E9-989F-E18469428ABB@eudaemon.net> References: <20140521033348.13532.qmail@joyce.lan> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SsPcYDG_u2Pmun3IWacco7HyWPc Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:40:04 -0000 On May 20, 2014, at 11:33 PM, John Levine wrote: > I finally updated the draft, based on the thorough Dave Crocker did > in February: >=20 > http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ Grammar nits: - 2nd sentence is missing a word: "Unfortunately this means that the = A/AAAA record is taken to be (the) mail server address even when that = address does not accept mail." - Section 2 "aserver" should be "a server". Minor suggestions: - Section 2 ends with "This document defines a NULL MX that will cause = all mail delivery attempts to a domain to fail immediately." Maybe tack = on an extra sentence of "NULL MX performs this function without = requiring domains to create SMTP listeners dedicated to preventing = delivery attempts." - Section 3 says NULL MX "offers many resource savings", but then lists = only 1. Suggested change (I'm replacing "It" with "An SMTP server"): An SMTP server can choose to reject email during the SMTP = conversation if presented with an undeliverable 5321.Mail=46rom domain. = Similarly, when requested by an SMTP client to deliver a message to an = undeliverable RFC5321.RcptTo, the SMTP server can immediately report = delivery failure. Guidance for reply code when attempting to deliver to NULL MX domain? There is a section 6 "Domains that do not send email", and it contains = guidance for SMTP servers that reject mail due to MAIL FROM containing a = domain that has a NULL MX record. Should there be similar guidance on = which reply code to propagate in the case where delivery is rejected due = to attempting to deliver to a domain where NULL MX is present? AFAICT = this would mean a 550 reply, with bonus points if a mention to an = enhanced status code of RFC 3463 section 3.2, X.1.2 "Bad destination = system address" (http://tools.ietf.org/html/rfc3463#section-3.2) could = be folded in. =3D- Tim From nobody Fri May 23 17:13:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F771A0271 for ; Fri, 23 May 2014 17:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E61TJ8z0aGmX for ; Fri, 23 May 2014 17:13:38 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id A5C9B1A026B for ; Fri, 23 May 2014 17:13:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C52B940948C for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yyMAaxAskTi for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A50B2409563 for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9899C40951F for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qQWd3zDVYhIm for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 7E6DA40948C for ; Fri, 23 May 2014 19:13:36 -0500 (CDT) Date: Fri, 23 May 2014 19:13:35 -0500 (CDT) From: Franck Martin To: apps-discuss@ietf.org Message-ID: <1461564554.134575.1400890415415.JavaMail.zimbra@peachymango.org> In-Reply-To: <1673847916.134570.1400890384346.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_134574_442565445.1400890415414" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Authentication-Results header extensibility Thread-Index: dVTom2RvmsdknCQwJeZngWnLZ1t4vA== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HbueRV3U0cXEBUUuZ0GXl6fHLH8 Subject: [apps-discuss] Authentication-Results header extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:13:40 -0000 ------=_Part_134574_442565445.1400890415414 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Where are we in bringing more flexibility to extensions to the grammar of the Authentication-Results header? ------=_Part_134574_442565445.1400890415414 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Where are we in bringing more flexibility to extensions to the grammar of the Authentication-Results header?
------=_Part_134574_442565445.1400890415414-- From nobody Fri May 23 17:19:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3B1A0271 for ; Fri, 23 May 2014 17:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hqGfeMB_71Ep for ; Fri, 23 May 2014 17:19:27 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3435B1A026B for ; Fri, 23 May 2014 17:19:27 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B6261D04508; Fri, 23 May 2014 20:19:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1400890763; bh=Okw/yvL8ntVS6GjJjzPSaiUhnnPISH4J5Pi62I1qljs=; h=In-Reply-To:References:Subject:From:Date:To:From; b=cKwDDuPxZXw4dlOifxaN11IaUdK+nf9E4XQ73aQ2laO5JrBdJ+NVZ6c6I7ah0E3Z5 p9JZH/8eyWvlB0rKvQq3WXMEzcbOf0B22CM0seijdlJj13aoM4IxyKqXAoJqR8qlgF ay9LYIy5AtGONWwxmXKD0O+iQqyIe4C/qNEO/h/Y= Received: from [IPV6:2600:1003:b11d:fbb7:64a6:c3be:fe05:367c] (unknown [IPv6:2600:1003:b11d:fbb7:64a6:c3be:fe05:367c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 50EA7D044CF; Fri, 23 May 2014 20:19:22 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <1461564554.134575.1400890415415.JavaMail.zimbra@peachymango.org> References: <1461564554.134575.1400890415415.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Fri, 23 May 2014 20:19:24 -0400 To: apps-discuss@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Uks9q8PjsrwAdbG8vP1eQUr7OBE Subject: Re: [apps-discuss] Authentication-Results header extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:19:28 -0000 On May 23, 2014 8:13:35 PM EDT, Franck Martin wrote: >Where are we in bringing more flexibility to extensions to the grammar >of the Authentication-Results header? I think we stalled on if a version bump was needed. Scott K From nobody Fri May 23 17:28:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03971A0281 for ; Fri, 23 May 2014 17:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xXZ1aQsiIoT7 for ; Fri, 23 May 2014 17:28:05 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 854E11A027C for ; Fri, 23 May 2014 17:28:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D21C23F47CF for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLd3j_4FZPRg for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B541829D9B8 for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9F39129D998 for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id A8B4gUZm_8TF for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 89E983F47CF for ; Fri, 23 May 2014 19:28:03 -0500 (CDT) Date: Fri, 23 May 2014 19:28:02 -0500 (CDT) From: Franck Martin To: IETF Apps Discuss Message-ID: <230073500.134635.1400891282683.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140521033348.13532.qmail@joyce.lan> <565A03A1-A2DB-43E9-989F-E18469428ABB@eudaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-ietf-appsawg-nullmx-01 Thread-Index: ORAsk2HbKIUMVxBLxjfqZ2wxrPJp2w== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/A5L5HTU65eVV-fvGopMbkDaRhZ0 Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:28:06 -0000 This document does not seem to address where to send an abuse report for that domain? if example.com is such domain with a null MX, I cannot email abuse@example.com (which I think is required for all domains in theory, practice is different). The whois record may not contain that information either. It would be interesting to tie the null mx with a record to where abuse should be sent. I'm not sure if it should be a separate draft an referred here, or if it should be mentionned here. something like this could work _abuse.example.com TXT "mailto:abuse@example.net;http://www.example.net/abuse" Where mailto: would be a required. Shall I propose some text? From nobody Fri May 23 21:12:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664C71A0061 for ; Fri, 23 May 2014 21:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 Qxa5XugI186u for ; Fri, 23 May 2014 21:12:08 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B311A0059 for ; Fri, 23 May 2014 21:12:07 -0700 (PDT) Received: (qmail 97179 invoked from network); 24 May 2014 04:12:04 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 24 May 2014 04:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d85e.53801c13.k1405; i=johnl@user.iecc.com; bh=Jv1LJcDhMRSmPDa+2C0uD01NeTKwSMNOQ1MMU8KfJ2s=; b=c96UzOGXveVhzSkAhTuumQNvmtEzUlu3pFNnZA8GBJ0OJly2MfZSEN7Mf4RjglDJh1FXMoIlY4lq8tGrhjdJp/Ms+Sqhyc3aUHK0OJ9ZuBNHoKYpuw3KuOyG30ohHoxBC4LCedXYrnKHokgPnOnpIO+HHQMQZuYY0Hrl7VQgYYc5JB5dmvTgG7jIYuUzrwrlyK1FdddxivZKMp9Y7IuBb6YieoQbt6dg5Wy03/EX059qtt1eScDzo+VePaY6qqCe DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d85e.53801c13.k1405; olt=johnl@user.iecc.com; bh=Jv1LJcDhMRSmPDa+2C0uD01NeTKwSMNOQ1MMU8KfJ2s=; b=BqB90cGByYX/jhDhIFY+9BQBqutzPFnWe8XjjZUhLwoeZIpZSteuSx82ncswjE0ECaeCi1kiCXB+WRAU7N1/p7vDxo1zgoxTa3oMTgawmHXbcnwNnta6neNlB/tYlF8FLx3SSX53vRAtIcJ2ZM97RHlnUYUHZ848q+mNb26d2LrKLrhp93JD6vhA+FKR2STah/mn8Sgc7e4m4wuNrZkMnrcHNOkuB4tGLhLghcVxlXj6nLiOfRP86DdDnjcGA7up Date: 24 May 2014 04:11:41 -0000 Message-ID: <20140524041141.55389.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <230073500.134635.1400891282683.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YF37K9CD_fUy_FJovyXvvXS6wAc Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 04:12:09 -0000 In article <230073500.134635.1400891282683.JavaMail.zimbra@peachymango.org> you write: >This document does not seem to address where to send an abuse report for that domain? That is correct. In that regard, it is consistent with every other SMTP RFC over the past 30 years. From nobody Fri May 23 23:29:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934B91A009A for ; Fri, 23 May 2014 23:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 zk9eJJs7C_nQ for ; Fri, 23 May 2014 23:29:39 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD2781A0099 for ; Fri, 23 May 2014 23:29:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P861MSEQ1S002L9J@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 23 May 2014 23:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1400912677; bh=lFA8TTlrfdIXYF1H8knSA5ZNvCoSESTVztW3YxeNhnE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=GKJ6c/SfhYQCWjcSE8Hf+LlEzISC/We+F8aATicO63hbGYJ14U4puo5KaFPzieFx1 pNCgxv117eTMWmiv93+rwUtpa9hnuWlxwemfJgZlcEDyiheq5j2PLP415ipeiNpsN8 IACC4yxchVoR8L21gGzUJiMl/bQnPpBX0psHXmb0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7ZVUWI9SW000052@mauve.mrochek.com>; Fri, 23 May 2014 23:24:32 -0700 (PDT) Message-id: <01P861MQTBNS000052@mauve.mrochek.com> Date: Fri, 23 May 2014 19:14:36 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 23 May 2014 19:28:02 -0500 (CDT)" <230073500.134635.1400891282683.JavaMail.zimbra@peachymango.org> References: <20140521033348.13532.qmail@joyce.lan> <565A03A1-A2DB-43E9-989F-E18469428ABB@eudaemon.net> <230073500.134635.1400891282683.JavaMail.zimbra@peachymango.org> To: Franck Martin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WZiMztz3uoBuSuBJC1uBs2iW12w Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 06:29:40 -0000 > This document does not seem to address where to send an abuse report for that > domain? Why should it? Even if this was an important thing to be able to do - and I'm quite skeptical that it is - it's an entirely separable problem. > if example.com is such domain with a null MX, I cannot email > abuse@example.com (which I think is required for all domains in theory, That's incorrect. RFC 2142 only requires that abuse work for an "organization's top level domain name" accept mail and have a corresponding abuse mailbox. I interpret that to mean that this whole nullmx thing is inappropriate for domains wanting to conform to this requirement. There's also a requirement about supporting appropriate mailboxes for the protocols that are actually associated with the domain name. So if your domain has an email service associated with it various addresses need to work, including abuse@. And once again the nullmx thing isn't appropriate. > It would be interesting to tie the null mx with a record to where abuse > should be sent. I'm not sure if it should be a separate draft an referred here, > or if it should be mentionned here. We call those records MX records. And yes, that means you can't simultaneously say "accept no mail" and "accepts abuse reports by doing so-and-so". > something like this could work > _abuse.example.com TXT "mailto:abuse@example.net;http://www.example.net/abuse" > Where mailto: would be a required. > Shall I propose some text? I am strongly opposed to putting any such mechanism in this specification. If you really think this is important enough to do, you can write a separate document to do it. Ned From nobody Sat May 24 00:39:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2781A01D1 for ; Sat, 24 May 2014 00:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rh76MLV6Oz2s for ; Sat, 24 May 2014 00:39:22 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFD71A01FF for ; Sat, 24 May 2014 00:39:21 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so5716405wes.2 for ; Sat, 24 May 2014 00:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujTxk1k+XLK6ZJeS4mokXjag/SKu9P4aLPm5U0NiLH8=; b=Fy135xLbXE/cAJ43ZuUW2kQo7wpCLkKxTO+GdSliNv+ZjLusDzQLAWRY1iYSTHuhbx XhSj9dIhN8nrk7iDbfUZaft2VSmABd/U15O21Uy0ZzHzTDa0UQzHkSt8LrUjoQ1/6B9v joAf7wgVt2/yknzKEuZsEjAhZA8ayujL9FJK8iQvUh1aCMi4Ta4jugZ9FolzYaZhLdOj IunE5pv95S46HpL0+esnTvfbB21GzlfdlWHXOzpPipvm8KGiqbXoM8z6LZ08KUH0Jwq+ imR2X2DLtUb0ZSkpH9v78Eu1ExnfwNAX6Na98w7Rot9SxUMfdkoE8Ykv/TGoBe8mEV13 R32A== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr10310191wjb.35.1400917158857; Sat, 24 May 2014 00:39:18 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Sat, 24 May 2014 00:39:18 -0700 (PDT) In-Reply-To: References: <1461564554.134575.1400890415415.JavaMail.zimbra@peachymango.org> Date: Sat, 24 May 2014 00:39:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e01419c6a9d123004fa20717b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5JhUVpdBzOb1IRkb3jFtdHgTS4k Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Authentication-Results header extensibility X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 07:39:24 -0000 --089e01419c6a9d123004fa20717b Content-Type: text/plain; charset=UTF-8 I have an update draft partly done. On Fri, May 23, 2014 at 5:19 PM, Scott Kitterman wrote: > > > On May 23, 2014 8:13:35 PM EDT, Franck Martin > wrote: > >Where are we in bringing more flexibility to extensions to the grammar > >of the Authentication-Results header? > > I think we stalled on if a version bump was needed. > > Scott K > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e01419c6a9d123004fa20717b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have an update draft partly done.


On Fri, May 23, 2014 at 5:= 19 PM, Scott Kitterman <scott@kitterman.com> wrote:


On May 23, 2014 8:13:35 PM EDT, Franck Martin <franck@peachymango.org> wrote:
>Where are we in bringing more flexibility to extensions to the grammar<= br> >of the Authentication-Results header?

I think we stalled on if a version bump was needed.

Scott K

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e01419c6a9d123004fa20717b-- From nobody Sat May 24 09:41:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB51A00BA for ; Sat, 24 May 2014 09:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.438 X-Spam-Level: X-Spam-Status: No, score=-98.438 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 iChJmrQTC8ga for ; Sat, 24 May 2014 09:41:23 -0700 (PDT) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACE91A0039 for ; Sat, 24 May 2014 09:41:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2528; t=1400949678; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MF0ewqipNEy+c0ycUZbSGE2reuo=; b=sVw2CzT6UgyQ4Xfs24hu wIbmifD/m6FQ85/fI6tpDgmrSTdrLP+q10ahZHuSVy45TUOg0Q5drf1AipAYlR25 JwFnPJjfuLQyuidC6Vd7qXpcnW1ZNPMOy1BBqyn1HWH5PTxieB8Uqsx/yhvNi1Cy eZm6EOiFoRaw1QdFBska5qE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 24 May 2014 12:41:18 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 429818338.10159.3384; Sat, 24 May 2014 12:41:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2528; t=1400949541; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iG10F0s 7zMouEzG5Mc7OEO1xZf1cy8KuD79vdb8FsyE=; b=hT+dZWOowejkhP2LIwJCbag BVEzR0eZOsRar7vMfXqTQnUWY0HpvtQmtJsWPaZXFd8oymGALaASkOjuF/qvxlO7 mM8k0NU7Xk2qICRd7TO/QRL7ojTbIBr7yUPYc4c/UVw9PEUQLYBhz/oI0iNB1DiI RYEXD6FeAWGU3xxAy2Jw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 24 May 2014 12:39:00 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 446187250.9.3260; Sat, 24 May 2014 12:38:59 -0400 Message-ID: <5380CBAF.2050008@isdg.net> Date: Sat, 24 May 2014 12:41:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140521033348.13532.qmail@joyce.lan> In-Reply-To: <20140521033348.13532.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DQxSi7fOr3-tjbQhNM5V-TJOHIY Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 16:41:26 -0000 My only thing about it is that its a bad title. Its really not a "NULL" MX record. Its an explicitly defined MX record (not NULL) with a Preference value of zero. I hope people don't read it wrong with NULL meaning no MX record is defined and this can translate to a NO MAIL operations or that a mail operation must have a MX record. Section 5, however, is very clear and clean about the two requirements: - One MX RECORD only - Preference equal zero If anything, update the abstract with one simple change to the last sentence to that interested readers will know exactly what it means upfront without the need to get into the details. ...... The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies, by creating a single MX record with a preference of Zero. As we know NULL has a different meaning to C/C++ programmers and it might enforce code changes that take into account a returning count value versus a transversal/walk of a pointer to a MX array of sorted IP records. When that returned pointer, i.e. pMX is NULL, then it could mean NO RECORDS to the implementation method. Please don't tell me that is a WRONG or ODD. Its a normal coding consideration. Walks are cooler than having counts to some. What I am saying this code could change: pMX = GetMXRecords(Target.Domain) if (!pMX) { return NO_MX_USE_A_FALLBALL; } ... walk the pMX pointer array for mail send attempt .... to this where the DNS client API has to change to include a count: pMX = GetMXRecords(Target.Domain, &count) if (count == 0) { return NO_MX_USE_A_RR_FALLBACK; } #ifdef SUPPORT_NULL_MX_PROPOSAL if (count == 1 && pMx[0].Preference == 0) { return SINGLE_MX_PREF_ZERO_NO_MAIL. } #endif ... walk the pMX pointer array for mail send attempt .... Thanks -- HLS On 5/20/2014 11:33 PM, John Levine wrote: > I finally updated the draft, based on the thorough Dave Crocker did > in February: > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > > As far as I know, nothing in the draft is contentious. It still > refers to RFC 4408 rather than 7208 because for some reason 7208 isn't > in the xml2rfc library yet. Other than that I think it's done. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- HLS From nobody Sat May 24 15:41:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456381A00C2 for ; Sat, 24 May 2014 15:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 k_tnvyErpHwt for ; Sat, 24 May 2014 15:40:56 -0700 (PDT) Received: from smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 554D61A00B5 for ; Sat, 24 May 2014 15:40:56 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 0D07419B7C; Sat, 24 May 2014 18:40:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=Q/IWCfdGUyWm mLN3pBVkLxHd3yM=; b=tx2/eKfuhxhC9jGRBfQafQskbTAT3XBTesDUxYaYUEtY pVf94pvpw+NwNeVuB7Hll7MTzupnsjiHZGF+Mdko4b0TYNwB1CE2Jr5X5N+4enAa SW3+pNeveAS/JyWBC7uqk8nje5AncnMQYvduY6AiILvxcRaAJ3T6CQ+P6cEZIMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=eSz0SU M25KNlFX8K1fG9djiaW87r1ZxLr0JB5t6AdLfZcvhoCMiJaw/EKecpGdWw6AkILP wdvUHlwafS0dr5gpIDA3C0OrqF3X5MThNMYh5b6oqj4QuWFIhovBDFVGBpL0esIT +Xyjs/G2fIcz5BP96SOQtlXJQwRKnptQG/2LU= Received: from pb-smtp0. (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 038BA19B79; Sat, 24 May 2014 18:40:53 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.7.113.80]) by pb-smtp0.pobox.com (Postfix) with ESMTPA id 92EF719B76; Sat, 24 May 2014 18:40:49 -0400 (EDT) Date: Sat, 24 May 2014 15:40:48 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1471803259.20140524154048@pobox.com> To: Apps-Discusssion In-Reply-To: <5380CBAF.2050008@isdg.net> References: <20140521033348.13532.qmail@joyce.lan> <5380CBAF.2050008@isdg.net> NSA-Eyes-Only: Why the hell are you reading this?! MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 7458A990-E394-11E3-8DB8-9903E9FBB39C-02871704!pb-smtp0.pobox.com Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ixCdKQfp5lmcmcPUrCoVggu0gU8 Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 22:40:58 -0000 On Sat, 2014-05-24, Hector Santos wrote: > My only thing about it is that its a bad title. Its really not a > "NULL" MX record. Its an explicitly defined MX record (not NULL) with > a Preference value of zero. I hope people don't read it wrong with > NULL meaning no MX record is defined and this can translate to a NO > MAIL operations or that a mail operation must have a MX record. So how about "NEGATIVE MX record". It seems to imply the explicit denial of MX access to a domain rather than some kind of absence=20 as implied by "NULL". Just my 2=C2=A2 --=20 Bill McQuillan From nobody Sat May 24 16:44:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50F1A02AC for ; Sat, 24 May 2014 16:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 6pz-cgDoobaK for ; Sat, 24 May 2014 16:44:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C81B1A02A6 for ; Sat, 24 May 2014 16:44:01 -0700 (PDT) Received: (qmail 23525 invoked from network); 24 May 2014 23:43:58 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 24 May 2014 23:43:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f261.53812ebe.k1405; i=johnl@user.iecc.com; bh=PkX/WPl00Ky9ozdAD5wryvONcxCXhkI7Yo/vF4hYmk0=; b=V9k7QNcvK899WqIOJ9frRxOFSVx6JUjlLez5ZOsCQQ+f38etbGThE/iWz0PzRllzOSU3OtUscM5uoxIaQNl6HofXEeRVsP0Gz5diaqJnClfmtOTpldIWeEHBrtrWqvEzLuhpSXcM5ci6g9haCMDRG+0EC6IpSGAwZrxmlWzOlklE3heIIbmM5nNy+ZQIQEIvxpvYnEcV5nj9m39LyKDOYGVRcIUN8kxUt/GPqIVLwZpz5SYPUDeJJhd5R9fCq9OG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f261.53812ebe.k1405; olt=johnl@user.iecc.com; bh=PkX/WPl00Ky9ozdAD5wryvONcxCXhkI7Yo/vF4hYmk0=; b=R5dctGgtYxqH34zttki9rd+SsI+0BBcwUL9hPBnrAaCenaeRP4mYNd6IpxIvqWiv58ZF0ZtD+lxIGMEn2VEp8N0HfVo3wJo0Nr0dj8OelLkXuoEHxuRFu5byWCFEMioc9GaI68CLHZ8YNZiQRNf+/mw5MP3jwJq05yCOhvs7IQnR/a9AYd2gxYzAxQAnluo2tHARfvSR8kPKoty9GRA8EPYCUoYjkVM8pQp8bD0igq45PjBeyEosPqk45/GhbqTP Date: 24 May 2014 23:43:36 -0000 Message-ID: <20140524234336.62048.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1471803259.20140524154048@pobox.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0zn4HryKrSrF3rGbeNlD0ondftY Cc: McQuilWP@pobox.com Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 23:44:03 -0000 >So how about "NEGATIVE MX record". It's been called NULL MX since the first version of the draft in 2006, and this is the first time anyone's complained about the name. I'm not inclined to change it. From nobody Sat May 24 21:09:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FEC1A020F for ; Sat, 24 May 2014 21:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hZ4qFt-P45xv for ; Sat, 24 May 2014 21:09:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id DF9CA1A0075 for ; Sat, 24 May 2014 21:09:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P87B1C2UYO002VYJ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 24 May 2014 21:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1400990665; bh=8PATmsPAZs1GQ+ozzudZ/xwxdKnd3Otwf5wOTj8y/6U=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Avl/fJvNtTO2sj5AI1i85/sFjX1V2vrOKDJxMnN2FdD7UOiVn3/AUU+DiU7snrqEv 5bMu6YlmmLRDM7qCKsXtY136jLxCelqS1zNUQGatz3rQ5GiZn+2GH2DpNXwTsgv6Zp d0KxGSueKFUud5A7RBpfytgzrS4iMpJIW8f2ftvk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7ZVUWI9SW000052@mauve.mrochek.com>; Sat, 24 May 2014 21:04:22 -0700 (PDT) Message-id: <01P87B1AMXEW000052@mauve.mrochek.com> Date: Sat, 24 May 2014 21:03:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 24 May 2014 23:43:36 +0000" <20140524234336.62048.qmail@joyce.lan> References: <1471803259.20140524154048@pobox.com> <20140524234336.62048.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H5JnXopfWbWdyolvLIqNkFuMHak Cc: McQuilWP@pobox.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 04:09:31 -0000 > >So how about "NEGATIVE MX record". > It's been called NULL MX since the first version of the draft in 2006, > and this is the first time anyone's complained about the name. I'm > not inclined to change it. And I am inclined to agreee. The name speaks to the nature of the record. I don't view that as a bad thing. Ned From nobody Sun May 25 01:49:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8C1A02BC; Sun, 25 May 2014 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Nq7wttvG0Gig; Sun, 25 May 2014 01:49:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEA1A024A; Sun, 25 May 2014 01:49:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 01:49:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1NhkjTrN91MgMLmTBipI921A_90 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 08:49:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-00.txt Pages : 5 Date : 2014-05-23 Abstract: There is at present no way to return a status code to an email client that indicates a message is being rejected or deferred specifically because of email authentication failures. This document registers codes for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 25 01:54:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B881A02CF for ; Sun, 25 May 2014 01:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 pJd5MoMROLFq for ; Sun, 25 May 2014 01:54:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5FA1A02C9 for ; Sun, 25 May 2014 01:54:19 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-98-5381afb64982 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.8C.16420.6BFA1835; Sun, 25 May 2014 10:54:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.10]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Sun, 25 May 2014 10:54:13 +0200 From: Salvatore Loreto To: "apps-discuss@ietf.org Discuss" Thread-Topic: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes Thread-Index: Ac939uaSbEfm5XI0SLKBGvghl682fQ== Date: Sun, 25 May 2014 08:54:13 +0000 Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A4C4581@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A4C4581ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje629Y3BBsfemFmsfrmCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGW/PHWEsmKxZMW33TsYGxvlKXYycHBICJhLfJh9lhrDFJC7c W8/WxcjFISRwlFHi6vd2dghnMaPEjuWNbCBVbAJmEs8fbgHrEBGwlpj/YTeYLSwQKHHi+UrG LkYOoHiQRP+uNIgSPYnLs76zgtgsAqoS97r3gI3hFfCWOPjmA1icEWjx91NrmEBsZgFxiVtP 5jNBHCQgsWTPeajjRCVePv7HCmErSrQ/bQBbxSyQL3HsPyfESEGJkzOfsExgFJqFZNIshKpZ SKogSvQkbkydwgZha0ssW/iaGcLWlZjx7xALsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5 qSWbGIHxcHDLb9UdjJffOB5iFOBgVOLhXeDXGCzEmlhWXJl7iFGag0VJnPeiRnWwkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBkYZPU0dq02d/YXFUrdjFLNOnQy4c+GO1MELSz9ZJR7MSp/s e4LH/O6SkPc/Z/L0bdpuWL9cM5zJ+hQTq7XQHPaQmMcVXuqrOC584JOpso0Je7ZRnb383YJl EtH3Z+Y7iwWUJD2OneixQfHSxG1fL3s4vzFJ2+fQ9zI/83I3Ryajzff39d1fLyixFGckGmox FxUnAgBT2ZcNaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mRO9Ne9KvBmWJFNrK8aJ0ueh4oI Subject: Re: [apps-discuss] Call for Adoption: draft-kucherawy-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 08:54:23 -0000 --_000_2B9B48179856DC4FA00C93C79EB7E64A4C4581ESESSMB109ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable thanks to the positive result of the call for adoption this draft has been adopted as wg item. The chairs will update the wiki with the mini-charter for the draft. br Salvatore Loreto On May 9, 2014, at 9:09 AM, Salvatore Loreto wrote: This is a formal call for adoption of draft-kucherawy-email-auth-codes into= APPSAWG. The call will close on May 23, 2014. The chairs note that there has already been some _expression_ of interest f= or adoption in a recent thread; however more feedback is requested to make sure appsawg is the right venue = for this draft Please submit comments, concerns, support, etc. for this document's handlin= g by APPSAWG in reply to this thread by May 23, 2014. Note that this is not an indication of support for the document as-is, only= for APPSAWG adopting it for further development. As for the APPSAWG process you will find the mini-charter for the draft at = the end of this message. in order to adopt the draft we also need to secure a minimal set of reviewe= rs and supporters for the document. If you'd like to be added to that list, please say so in your reply. cheers /Salvatore The "email-auth-codes" Mini-Charter ---------------------------------------------- The adoption of SPF and DKIM as emerging email authentication technologies = has been significant. Absent from these, an oversight at the time, is a way to indicate to an SMT= P client the fact that a message is being rejected specifically because one= of these mechanisms failed to authenticate the message. Without these, on= ly generic authentication error codes can be returned. This short document registers new Email Enhanced Status Codes (see RFC 3643= and RFC 5248) so that this can be clearly indicated by SMTP servers. No other work is proposed for this document The following have committed to work on the document through to publication= : Reviewers: (please volunteer!) _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_2B9B48179856DC4FA00C93C79EB7E64A4C4581ESESSMB109ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
thanks to the positive result of the call for adoption
this draft has been adopted as wg item.

The chairs will update the wiki with the mini-charter for the draft.

br
Salvatore Loreto

On May 9, 2014, at 9:09 AM, Salvatore Loreto <salvatore.loreto@ericsson.= com> wrote:



This is a formal call for adoption of draft-kucherawy-email-auth-codes into= APPSAWG. 
The call will close on May 23, 2014. 

The chairs note that there has already been some _expression_ of interest f= or adoption in a recent thread;
however more feedback is requested to make sure appsawg is the right venue = for this draft

Please submit comments, concerns, support, etc. for this document's handlin= g by APPSAWG in reply to this thread by May 23, 2014.
Note that this is not an indication of support for the document as-is, only= for APPSAWG adopting it for further development.

As for the APPSAWG process you will find the mini-charter for the draft at = the end of this message.
in order to adopt the draft we also need to secure a minimal set of reviewe= rs and supporters for the document.
If you'd like to be added to that list, please say so in your reply.

cheers
/Salvatore



The "email-auth-codes" Mini-Charter
----------------------------------------------
The adoption of SPF and DKIM as emerging email authentication technologies = has been significant. 
Absent from these, an oversight at the time, is a way to indicate to an SMT= P client the fact that a message is being rejected specifically because one= of these mechanisms failed to authenticate the message.  Without thes= e, only generic authentication error codes can be returned.

This short document registers new Email Enhanced Status Codes (see RFC 3643= and RFC 5248) so that this can be clearly indicated by SMTP servers.
No other work is proposed for this document

The following have committed to work on the document through to publication= :
Reviewers: (please volunteer!)

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--_000_2B9B48179856DC4FA00C93C79EB7E64A4C4581ESESSMB109ericsso_-- From nobody Sun May 25 11:14:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C271C1A0341 for ; Sun, 25 May 2014 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 FqjwpuCpwnN7 for ; Sun, 25 May 2014 11:14:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C59D91A0346 for ; Sun, 25 May 2014 11:14:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140525181414.26351.57930.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 11:14:14 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oBe8Kx5hpx4nMd9gUrYzDcSsXns Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 18:14:16 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun May 25 11:35:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA431A0352 for ; Sun, 25 May 2014 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nKQBRo_5QBoH for ; Sun, 25 May 2014 11:35:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F9C1A035A for ; Sun, 25 May 2014 11:35:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140525183535.1969.93179.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 11:35:35 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NAvHb9-ZJDxpIO-pUQ_IeOLItl8 Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 18:35:38 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-email-auth-codes", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun May 25 15:03:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7DE1A03F1; Sun, 25 May 2014 15:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ZwJne-SdfLp8; Sun, 25 May 2014 15:03:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AB31A03F6; Sun, 25 May 2014 15:03:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140525220300.8857.12309.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 15:03:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EGYK8KUTtusxwMt2Qk9byrVDQzs Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 22:03:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-02.txt Pages : 6 Date : 2014-05-25 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 25 15:22:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EDD1A03FE for ; Sun, 25 May 2014 15:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 zbT3xDNfhm3O for ; Sun, 25 May 2014 15:22:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D11A1A03FA for ; Sun, 25 May 2014 15:22:37 -0700 (PDT) Received: (qmail 71085 invoked from network); 25 May 2014 22:22:34 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 May 2014 22:22:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=11121.53826d2a.k1405; i=johnl@user.iecc.com; bh=jcamJ8fx9RgVrfDMN8dZQHC9YZpGIaGsj/a86bfg8q4=; b=aj6t0lu6efWseS4EOEPM5Kfeyky8fqXYSF2AZ0LCbq70H5JvJFYwQJd/HeQvShbq4zlGxpRbLugoxqZpd1fMsE/79uzUOxvH/bUjGXi04C+O382f1XQp+KgEp5u86qAEZDPc4DNHFm+MQElGzgvCOjOvIiJfHnG3brwKS5btZNOwHikysyQ3+AVm3sx48FgMmZeRvdC8fPsZYEDReu6uqawI/aj8fbejX5WFst/rWkKhrKFLfQwJfIGj/EReJhgW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=11121.53826d2a.k1405; olt=johnl@user.iecc.com; bh=jcamJ8fx9RgVrfDMN8dZQHC9YZpGIaGsj/a86bfg8q4=; b=wVmfmC69gleCO9UHBSSDEBswEKssAPZ+JWxKTVd19PYdNdDxe9Ifm/BcVYUqz8VfMmj8zI/+FELRxY6ahbMcHUXF3OaZGlXRd+R/pBjY4R9W5qpjDTXG514zGpf19Vfm/Ui8kHf02j3zbtEHLfVrq86QXUshXyFRW4r7Hg1bJEdgj+NIJ/qcIJ/yb7W+kuPx3rFkpKwlr943NONvt4n7MuFv2+sV9dpyUDjB/puJAC1atJCIflgfDKJiX+V5CLel Date: 25 May 2014 22:22:12 -0000 Message-ID: <20140525222212.69920.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ao31xrYR0VJpXdaf-jyZbF4Fygk Subject: [apps-discuss] draft-ietf-appsawg-nullmx-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 22:22:39 -0000 I did another round of edits, addressing comments from Tim and others. R's, John From nobody Mon May 26 12:59:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD11A024D; Mon, 26 May 2014 12:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 Vyj79w7S3at9; Mon, 26 May 2014 12:59:33 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FE01A023D; Mon, 26 May 2014 12:59:33 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so12665310qcx.27 for ; Mon, 26 May 2014 12:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=WciecxbOY2PcnNh0CVaSPcB6NpxS2Zb/j68dqarMPSI=; b=p2s05y4VMPN+pPZdbh/yEwMRT37sLJufpX/3cotRtQ320YyDnjs7pahRj3atfdfpUx XQL/zMETanyOp1YjQuvZD8EHqO2nFnwfl+gzSVpP47rLZoJKdStWDIrb7b6JkQEi7VB3 sO3SqksRu92eFVmgOI/YBdecNIkIOZsNby2GNdBQ3wg5U3CAbr4AL14lgUQI51CcyzJz 9U19xJ39Ihg7aONzfk7oPt1n31vWyXNrYmiJobDUSwtT1G26YZUn9rJsTDJ4alar8CVa HHLFfnUbbW1wpWkIuo6LM61+o4uUL4wmviNIDrtfvVyl/IuZfBR+3269vpjOy0dI4d7R tNng== X-Received: by 10.224.125.74 with SMTP id x10mr35539751qar.99.1401134370111; Mon, 26 May 2014 12:59:30 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id a13sm8504790qgf.38.2014.05.26.12.59.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 May 2014 12:59:29 -0700 (PDT) Message-ID: <276CF85BB22348268BB456984A397BE7@PeterPC> From: "Peter Occil" To: "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> Date: Mon, 26 May 2014 15:59:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140526-3, 05/26/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4DwXUKWOciPISELgg_SUebwFbi4 Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 19:59:34 -0000 Is there any more discussion on this document? I feel like this CBOR tag is ready to be registered. --Peter -----Original Message----- From: Peter Occil Sent: Thursday, May 15, 2014 12:35 PM To: LTRU Working Group ; apps-discuss@ietf.org Cc: Carsten Bormann Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags I have updated my specification on language-tagged strings. http://peteroupc.github.io/CBOR/langtags.html The two things new are: - The "NOTE" section. - The sentence "Both the language tag and the arbitrary string can optionally be annotated with CBOR tags." --Peter From nobody Tue May 27 07:26:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720231A015E for ; Tue, 27 May 2014 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZAZEgFG3fS9C for ; Tue, 27 May 2014 07:26:14 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFED71A0158 for ; Tue, 27 May 2014 07:26:13 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so9802562wes.0 for ; Tue, 27 May 2014 07:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lGKQ9V5nFJdphqfQIgWMf6S+bahh1xPp7jJfuFa/wLI=; b=tQ2Dj9szKRbdM85hr6gw+vgV13pqHK8NHfhZjl8eO2hsF1b86r65N6xtGu4Kp9fWdR bnjbVU/ub7v5MkUj+NbFE/06Wapb2fGBbftw1Zp1mfXQvZNuFU+gv+KKpB2h/x/7lM9R 7wIUHOQnXSuwLqrub0y+Npvtg5fHqPpIDRELcx6KLDwIqV31W4PlIja5Ut79UG3zcyWM ijzb0bElwjNmtpYDtUYPxiyaws9S26cvDyaEBhJdbMGOUeDZyFrSz0lzpQjKXDdQ+2B8 GTNO5vE6hc1IPtEZtrX9BcMZ+Npq9lGpw951GFGt4TaW5woiSk6kUAzcoPY6TAITa+By RyaA== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr38165337wic.5.1401200769256; Tue, 27 May 2014 07:26:09 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 07:26:09 -0700 (PDT) Date: Tue, 27 May 2014 07:26:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c23e5a1c538904fa627acd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tBujQ7GObq95C5MM8Ev-2iF6Seg Subject: [apps-discuss] IETF 90 scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:26:15 -0000 --001a11c23e5a1c538904fa627acd Content-Type: text/plain; charset=UTF-8 Colleagues, The window is open for us to request a meeting slot for Toronto. We'll be requesting our usual APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflict set. Please propose agenda items for this meeting in response to this thread. We'll have our usual updates from the co-chairs and ADs and will be inviting chairs of BoFs and newly formed working groups to give short presentations on what's happening during the week. If you are working on a document in APPSAWG that requires face time to resolve some issues, or would like to make or request a presentation on a particular topic, please let us know ASAP. Our preliminary agenda is due to the Secretariat on Friday, June 20th. -MSK, APPSAWG co-chair --001a11c23e5a1c538904fa627acd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The window is open= for us to request a meeting slot for Toronto.=C2=A0 We'll be requestin= g our usual APPSAWG/APPAREA Monday morning 9:30 slot with the usual conflic= t set.

Please propose agenda items for this meeting in response to this = thread.=C2=A0 We'll have our usual updates from the co-chairs and ADs a= nd will be inviting chairs of BoFs and newly formed working groups to give = short presentations on what's happening during the week.

If you are working on a document in APPSAWG that requires face time to = resolve some issues, or would like to make or request a presentation on a p= articular topic, please let us know ASAP.=C2=A0 Our preliminary agenda is d= ue to the Secretariat on Friday, June 20th.

-MSK, APPSAWG co-chair

--001a11c23e5a1c538904fa627acd-- From nobody Tue May 27 09:53:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC40C1A04C1 for ; Tue, 27 May 2014 09:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 mqnxiiUd6-zN for ; Tue, 27 May 2014 09:53:13 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF41F1A0408 for ; Tue, 27 May 2014 09:53:13 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so10997206veb.14 for ; Tue, 27 May 2014 09:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cnhh54MOVtCTVyD0LhQuZ5GOO6r6G/nMeV7CFvS49Ek=; b=Br5XxGlyVdbf7WC8pIR3vDU6WVnmQPmkVFJ9Oqx9RSNNFZqRGgwBTkHSbBvA93kB0l bDf5lCBsdttxpu03MhfpC3zilnJ0y6JCo7hAjWd1veWZK5GBJ+q8xvyLqpRAjPl6AtZe zdRFXE4Gg6sbOlyasaZGent883kLHSkf0y6DcILgERc73gnJ0h+lHQvybJPe7uqUFY+W m2bjX0I7LgPeWL8f1Se1ZPwqSrdhVINB1U5N2WEXh/uFvk0hIRPoFDclGuhVXNAgvPcL JnmoXyBZtv7z+THxrIXNtKUBX+JKLgO3D88dri+IkyMuHQ/vBNQUmWMoYKTIm23LwjCm UTiA== MIME-Version: 1.0 X-Received: by 10.52.97.202 with SMTP id ec10mr2193570vdb.55.1401209589996; Tue, 27 May 2014 09:53:09 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Tue, 27 May 2014 09:53:09 -0700 (PDT) In-Reply-To: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 12:53:09 -0400 X-Google-Sender-Auth: nRkJFoTllDYRvmAGu9pLQyr2zW8 Message-ID: From: Barry Leiba To: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jVpAGfJn3FEKB3X9i4DqrxPpXDs Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:53:14 -0000 > Title : Email Authentication Status Codes > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-email-auth-codes-00.txt > Pages : 5 > Date : 2014-05-23 > > Abstract: > There is at present no way to return a status code to an email client > that indicates a message is being rejected or deferred specifically > because of email authentication failures. This document registers > codes for this purpose. I'll repeat that I have a very strong objection to including the DKIM status codes. 6376 says this (Section 6.3): In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems. and this (Section 6.3): If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. The point that the codes are trying to convey is that the message is being rejected by a *policy* decision, not directly because of a DKIM signature issue. Both status codes that are proposed represent rejection because of a policy that directly violates "SHOULD" provisions in RFC 6376. I do not want to see a Proposed Standard that standardizes a status code that says, essentially, "This message was rejected because we have a policy that's in violation of RFC 6376." I would have much less problem with a status code that says, "This message was rejected because we were unable to verify the sending domain, and policy requires such verification." That could be put in here as a general thing, or can be left to DMARC to create (I see no reason to wait). This status code could explain, in its description, that said verification could come from successful validation of a DKIM signature, successful application of SPF, or [perhaps] by another verification mechanism that might later be defined. That would also address my other concern: this would clearly take precedence over the SPF Failures Code. You return the "Sending Domain Verification Failure Code" if you make broader checks, while the "SPF Failures Code" (why is it plural?) is used when you're only checking SPF (which does include policy, so my DKIM objection doesn't apply to SPF). It is probably worth explicitly saying that in the document. Barry From nobody Tue May 27 10:13:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1D11A01C1 for ; Tue, 27 May 2014 10:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Z6O6k5vFRzQU for ; Tue, 27 May 2014 10:13:25 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D91E1A01AC for ; Tue, 27 May 2014 10:13:25 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so2194028wiw.14 for ; Tue, 27 May 2014 10:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hase3FG+vG9Pl5tdkXP7qvk2RYT1tzeQOOxqIaj33zc=; b=dEvJGnHdmZNDi3RDJ1OpcUYrSu04BlJs43RNzmHawYFQCtM4RH9Mu8EK5ToQL0ONWq 3uLHxpxVvwyVXsEukQ5aufRVcstVXcgLnifrL5MasBhLv9tEm02RfuVXls9V+amg1jKh sQwefvdoasTV8cF0DryMRIZ6ZOy1bR6VMQAdf7y4cO26wlr0UZ8Pg/nTDEeqa8tta0ac Nmn3HLzieKizXFEHlYTsY7tR7miU4xnuQNDmlKp2afwaPjkolfFHdiloM18Mk7y6dNVr GV/1/0C7UyclyqIiM64C3kiE0m1rrJ/H0UB2cr5obbgxJR+tUocdbuVXcJHx+tPSh0GA GYhA== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr41241335wjb.73.1401210801233; Tue, 27 May 2014 10:13:21 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 10:13:21 -0700 (PDT) In-Reply-To: References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 10:13:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7bf10a1c10269c04fa64d084 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IWFSzfgXmK-A8pyo1qNK85OYs8E Cc: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:13:29 -0000 --047d7bf10a1c10269c04fa64d084 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 9:53 AM, Barry Leiba wrote: > The point that the codes are trying to convey is that the message is > being rejected by a *policy* decision, not directly because of a DKIM > signature issue. Both status codes that are proposed represent > rejection because of a policy that directly violates "SHOULD" > provisions in RFC 6376. I do not want to see a Proposed Standard that > standardizes a status code that says, essentially, "This message was > rejected because we have a policy that's in violation of RFC 6376." > > I would have much less problem with a status code that says, "This > message was rejected because we were unable to verify the sending > domain, and policy requires such verification." That could be put in > here as a general thing, or can be left to DMARC to create (I see no > reason to wait). This status code could explain, in its description, > that said verification could come from successful validation of a DKIM > signature, successful application of SPF, or [perhaps] by another > verification mechanism that might later be defined. > I guess I misunderstood your proposed change to the individual submission, and it landed where we are now. I'll take another run at it in the next version. > That would also address my other concern: this would clearly take > precedence over the SPF Failures Code. You return the "Sending Domain > Verification Failure Code" if you make broader checks, while the "SPF > Failures Code" (why is it plural?) is used when you're only checking > SPF (which does include policy, so my DKIM objection doesn't apply to > SPF). It is probably worth explicitly saying that in the document. > The plural is probably a mistake. I'll work on the rest of this as well. -MSK --047d7bf10a1c10269c04fa64d084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 9:53 AM, Barry Leiba <barry= leiba@computer.org> wrote:
The point that the codes are trying to conve= y is that the message is
being rejected by a *policy* decision, not directly because of a DKIM
signature issue. =C2=A0Both status codes that are proposed represent
rejection because of a policy that directly violates "SHOULD"
provisions in RFC 6376. =C2=A0I do not want to see a Proposed Standard that=
standardizes a status code that says, essentially, "This message was rejected because we have a policy that's in violation of RFC 6376."= ;

I would have much less problem with a status code that says, "This
message was rejected because we were unable to verify the sending
domain, and policy requires such verification." =C2=A0That could be pu= t in
here as a general thing, or can be left to DMARC to create (I see no
reason to wait). =C2=A0This status code could explain, in its description,<= br> that said verification could come from successful validation of a DKIM
signature, successful application of SPF, or [perhaps] by another
verification mechanism that might later be defined.
I guess I misunderstood your proposed change to the individual= submission, and it landed where we are now.=C2=A0 I'll take another ru= n at it in the next version.
=C2=A0
That would also address my other concern: this would clearly take
precedence over the SPF Failures Code. =C2=A0You return the "Sending D= omain
Verification Failure Code" if you make broader checks, while the "= ;SPF
Failures Code" (why is it plural?) is used when you're only checki= ng
SPF (which does include policy, so my DKIM objection doesn't apply to SPF). =C2=A0It is probably worth explicitly saying that in the document.

The plural is probably a mistake.=C2=A0 I= 'll work on the rest of this as well.

-MSK
--047d7bf10a1c10269c04fa64d084-- From nobody Tue May 27 10:54:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4C91A0354 for ; Tue, 27 May 2014 10:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 zP2dWmlzW0uT for ; Tue, 27 May 2014 10:54:51 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CCC1A01D6 for ; Tue, 27 May 2014 10:54:50 -0700 (PDT) Received: internal info suppressed Date: Tue, 27 May 2014 19:54:35 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Barry Leiba In-Reply-To: Message-ID: References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1401213279; bh=SA7Wxo7lx7KOxQB/fcq49sOmiXKmgEIq6kZFtmrKKGw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p5OdlF3R7W72Ex4m2vw2Xtcjtn2WPLRdJeG/fqv+g2sZThfSLpS5HlmH19TN23AuB kzhC7NVXOzrpKRx8RhwPRq2F8hwTPss0dxjo48Uo0Zvt+BWX+d+2QZd974aLq55ZvH sczD5tO/8TJmujWRT9IDvxnpx1TJCC8PpqZtzcrw= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QawRNSFYX7bOLYX-7o-bf46q-24 Cc: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:54:53 -0000 On Tue, 27 May 2014, Barry Leiba wrote: >> Title : Email Authentication Status Codes >> Author : Murray S. Kucherawy >> Filename : draft-ietf-appsawg-email-auth-codes-00.txt >> Pages : 5 >> Date : 2014-05-23 >> >> Abstract: >> There is at present no way to return a status code to an email client >> that indicates a message is being rejected or deferred specifically >> because of email authentication failures. This document registers >> codes for this purpose. > > I'll repeat that I have a very strong objection to including the DKIM > status codes. ++++1 !! 6376 says this (Section 6.3): > > In general, modules that consume DKIM verification output SHOULD NOT > determine message acceptability based solely on a lack of any > signature or on an unverifiable signature; such rejection would cause > severe interoperability problems. > > and this (Section 6.3): > > If the email cannot be verified, then it SHOULD be treated the same > as all unverified email, regardless of whether or not it looks like > it was signed. > > The point that the codes are trying to convey is that the message is > being rejected by a *policy* decision, not directly because of a DKIM > signature issue. Both status codes that are proposed represent > rejection because of a policy that directly violates "SHOULD" > provisions in RFC 6376. I do not want to see a Proposed Standard that > standardizes a status code that says, essentially, "This message was > rejected because we have a policy that's in violation of RFC 6376." > > I would have much less problem with a status code that says, "This > message was rejected because we were unable to verify the sending > domain, and policy requires such verification." That could be put in > here as a general thing, or can be left to DMARC to create (I see no > reason to wait). This status code could explain, in its description, > that said verification could come from successful validation of a DKIM > signature, successful application of SPF, or [perhaps] by another > verification mechanism that might later be defined. correct. > That would also address my other concern: this would clearly take > precedence over the SPF Failures Code. You return the "Sending Domain > Verification Failure Code" if you make broader checks, while the "SPF > Failures Code" (why is it plural?) is used when you're only checking > SPF (which does include policy, so my DKIM objection doesn't apply to > SPF). It is probably worth explicitly saying that in the document. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Tue May 27 11:54:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58B1A01F6; Tue, 27 May 2014 11:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 svGLeyehI0Wq; Tue, 27 May 2014 11:54:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B81B1A0664; Tue, 27 May 2014 11:54:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 11:54:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zkaOOQoYGCO4Sa6rnNeIwSG8xCM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:54:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-01.txt Pages : 6 Date : 2014-05-27 Abstract: There is at present no way to return a status code to an email client that indicates a message is being rejected or deferred specifically because of email authentication failures. This document registers codes for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 27 12:00:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6951A06DA for ; Tue, 27 May 2014 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 kQhL3yWlOlOu for ; Tue, 27 May 2014 12:00:05 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908421A06E5 for ; Tue, 27 May 2014 12:00:05 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so2148199wib.1 for ; Tue, 27 May 2014 11:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jSKvrjmLkUD4Kxv2+yMpkuEv6XUFlJtgBzRIbxZI6pw=; b=qkptBwVr/k4XIsUn3utFS5Qkwp8XXbxL1rUKwU2gCW2hAsDU4Ue7ZduOkwUVamNEB7 kU/3T6e5qtnAad4exSGgP9Dw4UjVb+CRlghjTTx7up9iG0MbanhAKtHywXEoHAonHe+T dFOA2PVwAHYLt9TujzPUo6dV1VdDfJzRPtSFkFgXgVGX5OK2QtRTrxJblo79E+6oz8WV n5AuR3a4q5/oEJ1jjFOQY2yzUymAdULDcAP3PhrDm6AQZPpZYmkjWLk0/LGHnRWmlpKW gBtc74HSUC5I3Op7XZtwFYQ8nllB9W654q1ijkNwgLmPuoedRIsOKvf0pSMuD1U66N1d 5pwQ== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr3050330wib.26.1401217199806; Tue, 27 May 2014 11:59:59 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 11:59:59 -0700 (PDT) In-Reply-To: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> References: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 11:59:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04462e5e72a46c04fa664dc8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mpFGlI70CD7moCsHSMWvQSqvTm8 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:00:07 -0000 --f46d04462e5e72a46c04fa664dc8 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 11:54 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Email Authentication Status Codes > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-email-auth-codes-01.txt > Pages : 6 > Date : 2014-05-27 > > Abstract: > There is at present no way to return a status code to an email client > that indicates a message is being rejected or deferred specifically > because of email authentication failures. This document registers > codes for this purpose. > This addresses Barry's concerns (I hope!). -MSK --f46d04462e5e72a46c04fa664dc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 11:54 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Emai= l Authentication Status Codes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-appsawg-email-auth-codes-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-05-27

Abstract:
=C2=A0 =C2=A0There is at present no way to return a status code to an email= client
=C2=A0 =C2=A0that indicates a message is being rejected or deferred specifi= cally
=C2=A0 =C2=A0because of email authentication failures. =C2=A0This document = registers
=C2=A0 =C2=A0codes for this purpose.

Th= is addresses Barry's concerns (I hope!).

-MSK
--f46d04462e5e72a46c04fa664dc8-- From nobody Tue May 27 12:08:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D241A06A9 for ; Tue, 27 May 2014 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 xou45QdsGnES for ; Tue, 27 May 2014 12:08:40 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C551A0225 for ; Tue, 27 May 2014 12:08:39 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so7671659vcb.7 for ; Tue, 27 May 2014 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q3l7qE1Esx5s4AIP+GD7UiQXaAYzONC036Vgg1LFQrs=; b=f86eOj42x0ovyG2p6Ui3FGs8iIv+ZdK/TlfWGAfkVP0Uuzs9t6i4ToiX5vC8p2qftt 5GptbZ5xgwTlt9/PXQnGwbtHdqttIO32AszlR95i5wj26jLGendDTYxwHz5GaeLQLzm8 Rbqmh0ofA4mb3mwxCcy2bzlVMg39y1uUeA31WUz8cfGZG5IOKpdfY7Yk5OGllotASYNN E3xpR+ryhp0PXi6tO3M2YItZEZA+4hWP1J5cus8GhqTlYXtva4HIxvZKmmP91cdZ5VHc 3Is9AvQeH2M0Y7cwEO6AZDHAv8kChpFqhSLA3dGrTuHrJsUPY4rh9zl/zTx2Tma2cKmw RNbQ== MIME-Version: 1.0 X-Received: by 10.52.35.69 with SMTP id f5mr2567921vdj.83.1401217716196; Tue, 27 May 2014 12:08:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Tue, 27 May 2014 12:08:36 -0700 (PDT) In-Reply-To: References: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 15:08:36 -0400 X-Google-Sender-Auth: -e9vFgT_a0UWn9zpoo2RJRHiQrY Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rqcLupYH-liP-QpL0WTFNHb3CAI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:08:40 -0000 >> Filename : draft-ietf-appsawg-email-auth-codes-01.txt > > This addresses Barry's concerns (I hope!). It does; I can live with this version, and I hope others find those changes acceptable. Thanks. Barry From nobody Tue May 27 12:16:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A401A0664 for ; Tue, 27 May 2014 12:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 RHSLl68OykM5 for ; Tue, 27 May 2014 12:15:57 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1787C1A072D for ; Tue, 27 May 2014 12:15:04 -0700 (PDT) Received: internal info suppressed Date: Tue, 27 May 2014 21:14:29 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Barry Leiba In-Reply-To: Message-ID: References: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1401218070; bh=JeKBtJrhcQ8S5p3vDlgCtZ54LHnS4FoAJuxWJOGBBlg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rMFpCaAp8MlAfH5oFL1GQBu4CNmj/ggAhtxHtje76eKKEXG63XtefqlKuLckRP8U0 qiOfJGvoSK1XNOI/zbs5P+c23JrCBYlAtVt6TXEwwJsy1s8QYx/seqA0amRa+4AAu3 NPchK8w5wWsgob1FIXHMgVyMKL3045foGbnnUwlo= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_ZCRR8jAEk8YC5odwcurPMMCs_c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:15:58 -0000 On Tue, 27 May 2014, Barry Leiba wrote: >>> Filename : draft-ietf-appsawg-email-auth-codes-01.txt >> >> This addresses Barry's concerns (I hope!). > > It does; I can live with this version, and I hope others find those > changes acceptable. ok +1 as "rejections because of DKDM or SPF are often "mysterious" for users (... and administrators) the clearer we state information, the better it is... > > Thanks. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Tue May 27 13:54:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0521A0261 for ; Tue, 27 May 2014 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 K6WIZtwFZkBh for ; Tue, 27 May 2014 13:54:11 -0700 (PDT) Received: from catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D41571A0272 for ; Tue, 27 May 2014 13:54:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1191; t=1401224037; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ItfpW95StjFsiCcDuO82AXLLsRY=; b=XDXVPxxq6zcy7EzLju55 ywcUNJ6bVPEyKbDZNokGlDa8MpI3UQwCT/a9xN1yMgdqNwnMzJyyo/AP3DJPlt/Z yoobTHPYZDNCoQ/z37FA3c4fiBFN6qJ8oBwWA2cv9oxPhzfKNA+KW31mtG9AwswJ yAnwXJsxoV3SAcajosLdstk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 27 May 2014 16:53:57 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 704173318.2191.2312; Tue, 27 May 2014 16:53:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1191; t=1401223894; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OYkVIt8 sHnJyCaP8f9aC1zNfDc3od5/YM21SnunXJk8=; b=1aTCotevZB3Mw/yaHLtc2xd tAc2HrJ/E+gRkAfQdQOJo1g+rmhciV6rlwKVaofzoAyd39n18bOHIB2jYFLc8qXp zqeUs2hHd+07AAozzRgDtv2rf8xgr4pxf+/hy7BdtNI/KsInhYWRg43Kh/XzNwMm XEyeJOmtcqt4TJNQ/G2s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 27 May 2014 16:51:34 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 720541000.9.484; Tue, 27 May 2014 16:51:33 -0400 Message-ID: <5384FB62.4000309@isdg.net> Date: Tue, 27 May 2014 16:53:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba , "Murray S. Kucherawy" References: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZwkDdkzdUqzR7gRmQl2hJgz8qdY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 20:54:13 -0000 On 5/27/2014 3:08 PM, Barry Leiba wrote: >>> Filename : draft-ietf-appsawg-email-auth-codes-01.txt >> >> This addresses Barry's concerns (I hope!). > > It does; I can live with this version, and I hope others find those > changes acceptable. > Why would a SMTP implementator wish to support this guideline for applying specific SMTP EXTENDED response codes if it violates DKIM? What will happen if the server issues the INVALID vs MISSING extended response? Will the client exploit/leverage this in a negative/positive manner? Is there a security loophole? In all cases, it is a about a rejection (55x) which all clients MUST treat the same (from a SMTP standpoint), so there is no violation. Now, where its OPTIONALLY applied, can extended codes make clients "smarter?" Will it do a bounce with a different result? Perhaps with the DSN reporting which will most likely have the 55x reported response. The drafts needs to take from the DKIM "treat invalid/missing" the same philosophy which came from a policy analysis where these different conditions were folded. The semantic became ambiguous only when POLICY was pulled from the framework. -- HLS From nobody Tue May 27 14:20:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258B71A070C for ; Tue, 27 May 2014 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 f5IOPz9yZGC1 for ; Tue, 27 May 2014 14:20:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0E1A0428 for ; Tue, 27 May 2014 14:20:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8B3MLNS1C003H2D@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 27 May 2014 14:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401225341; bh=rS2wKIPRB8kE+dMlESxeHQX7MT2oLT6mT+OYFN+DiFU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=eMuc+em64UkBoLau1xEpto/2hLgNJ/+TO76c75kSBPYwFkPVE2Qv4mjMxKXYWJP07 2M9N4P2T7hvsEj8x9picy6lbABRlpSKda1RONV7oxD18q4vR9GDIU2nJpV/u1Vr2YU n73eT1FnGWp3mU+u0SK66KbVVSmjaX4XjAuH89DI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7ZVUWI9SW000052@mauve.mrochek.com>; Tue, 27 May 2014 14:15:37 -0700 (PDT) Message-id: <01P8B3MKBPVG000052@mauve.mrochek.com> Date: Tue, 27 May 2014 14:08:21 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 May 2014 12:53:09 -0400" References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BZRzdWOOlsraCVkQS_tIJEcecPw Cc: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:20:47 -0000 > > Title : Email Authentication Status Codes > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-email-auth-codes-00.txt > > Pages : 5 > > Date : 2014-05-23 > > > > Abstract: > > There is at present no way to return a status code to an email client > > that indicates a message is being rejected or deferred specifically > > because of email authentication failures. This document registers > > codes for this purpose. > I'll repeat that I have a very strong objection to including the DKIM > status codes. 6376 says this (Section 6.3): > In general, modules that consume DKIM verification output SHOULD NOT > determine message acceptability based solely on a lack of any > signature or on an unverifiable signature; such rejection would cause > severe interoperability problems. > and this (Section 6.3): > If the email cannot be verified, then it SHOULD be treated the same > as all unverified email, regardless of whether or not it looks like > it was signed. > The point that the codes are trying to convey is that the message is > being rejected by a *policy* decision, not directly because of a DKIM > signature issue. Both status codes that are proposed represent > rejection because of a policy that directly violates "SHOULD" > provisions in RFC 6376. I do not want to see a Proposed Standard that > standardizes a status code that says, essentially, "This message was > rejected because we have a policy that's in violation of RFC 6376." Nicely put. I have to agree. > I would have much less problem with a status code that says, "This > message was rejected because we were unable to verify the sending > domain, and policy requires such verification." Exactly. This provides a code with real utility, because it tells the processing agent that the problem isn't with this recipient address, but with the message/recipient combination. > That could be put in > here as a general thing, or can be left to DMARC to create (I see no > reason to wait). This status code could explain, in its description, > that said verification could come from successful validation of a DKIM > signature, successful application of SPF, or [perhaps] by another > verification mechanism that might later be defined. The argument for putting it here is so that it is more generally applicable. The argument for putting it in the DMARC specification is that would make it clear that DMARC agents are supposed to use it. A middle ground would be to specify it here and reference the specification in DMARC. But any of these work for me; I'm more concerned with producing a timely specification than I am with the document taxonomy. > That would also address my other concern: this would clearly take > precedence over the SPF Failures Code. You return the "Sending Domain > Verification Failure Code" if you make broader checks, while the "SPF > Failures Code" (why is it plural?) is used when you're only checking > SPF (which does include policy, so my DKIM objection doesn't apply to > SPF). It is probably worth explicitly saying that in the document. Agreed. Ned From nobody Tue May 27 14:22:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44BE1A0428 for ; Tue, 27 May 2014 14:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Frnh53Jj-VF1 for ; Tue, 27 May 2014 14:22:33 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A680E1A026B for ; Tue, 27 May 2014 14:22:32 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so9995366wes.23 for ; Tue, 27 May 2014 14:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h8jLuX+KmeozinVA+wUVNwUaT2em2LLs+68UAKKMIOM=; b=b9YJZSgyQAVN+8dInDkzNu+38TaMIcYyL8DB9F4V2MRV6luZ0fgIy6J3rD3LpBGWbu K9Wj6tG+32HUQjQl5gOnAwfUGbjL+8jGJCfHqlG3ppwcyfrfTGkNtUPln7eFkW1tvUMN crHIeOuXH3VvamZSlAX+356V1WmsyPrtCwc7cbUr8X1LzrbvmlLf5fVNo10uaJ90ILOG Uw3CxgV3diQjybvcqTpWm7HRFdreXuXW6r1XhI11T8B6MVgvjTiX1hFXPiUXX6QCVRAZ FPBuBS4mVkK3YiLx6G5CWNc1L/ylYXV4AOm66cIB/AW9OWAOqvX6JEIbYuVKsNKrxySs JFBA== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr43397441wjb.73.1401225747869; Tue, 27 May 2014 14:22:27 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 14:22:27 -0700 (PDT) In-Reply-To: <5384FB62.4000309@isdg.net> References: <20140527185423.18081.12586.idtracker@ietfa.amsl.com> <5384FB62.4000309@isdg.net> Date: Tue, 27 May 2014 14:22:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7bf10a1cf3b85204fa684aec Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8FaX-qd4JuvhGVZOldQTYk8DKd8 Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:22:35 -0000 --047d7bf10a1cf3b85204fa684aec Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 1:53 PM, Hector Santos wrote: > Why would a SMTP implementator wish to support this guideline for applying > specific SMTP EXTENDED response codes if it violates DKIM? > Senders of legitimate messages might find it useful to know why their messages are being rejected. Automation (list services, for example) might find it useful to know the difference between a generic policy rejection and a DKIM-specific one. This also sets the stage for DMARC-based rejections, detection of which is something MLMs sorely need, for example. > What will happen if the server issues the INVALID vs MISSING extended > response? > Both are potentially useful information for SMTP clients or message generators of any kind. They're certainly more descriptive than 5.7.0 or 5.7.1, which are generic. Will the client exploit/leverage this in a negative/positive manner? > That is the intent, yes. > Is there a security loophole? > Do you have one in mind that isn't already called out in the document? > In all cases, it is a about a rejection (55x) which all clients MUST treat > the same (from a SMTP standpoint), so there is no violation. > The violation is one of DKIM's advice, as is already cited in the document. Specifically, if you bounce mail because of DKIM failures, you're violating the SHOULD NOT of DKIM. > Now, where its OPTIONALLY applied, can extended codes make clients > "smarter?" > Nothing compels MTAs to use these codes, so of course they're optional. -MSK --047d7bf10a1cf3b85204fa684aec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 1:53 PM, Hector Santos <hsantos@= isdg.net> wrote:
Why = would a SMTP implementator wish to support this guideline for applying spec= ific SMTP EXTENDED response codes if it violates DKIM?

Senders of legitimate messages= might find it useful to know why their messages are being rejected.=C2=A0 = Automation (list services, for example) might find it useful to know the di= fference between a generic policy rejection and a DKIM-specific one.=C2=A0 = This also sets the stage for DMARC-based rejections, detection of which is = something MLMs sorely need, for example.
=C2=A0
What will happen if the server issues the INVALID vs MISSING extended respo= nse?

Both are potentially useful inform= ation for SMTP clients or message generators of any kind.=C2=A0 They're= certainly more descriptive than 5.7.0 or 5.7.1, which are generic.

Will the client exploit/leverage this in a negative/positive manner?

That is the intent, yes.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Is there a security loophole?

Do you ha= ve one in mind that isn't already called out in the document?
=C2=A0=
In all cases, it is a about a rejection (55x) which all clients MUST treat = the same (from a SMTP standpoint), so there is no violation.

The violation is one of DKIM's advice, as is alre= ady cited in the document.=C2=A0 Specifically, if you bounce mail because o= f DKIM failures, you're violating the SHOULD NOT of DKIM.
=C2=A0
Now, where its OPTIONALLY applied, can extended codes make clients "sm= arter?"

Nothing compels MTAs to us= e these codes, so of course they're optional.

-MSK
--047d7bf10a1cf3b85204fa684aec-- From nobody Tue May 27 14:24:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0531A0428 for ; Tue, 27 May 2014 14:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yWbFyH3-7_Ml for ; Tue, 27 May 2014 14:24:12 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC2E1A0301 for ; Tue, 27 May 2014 14:24:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so9966183wgh.4 for ; Tue, 27 May 2014 14:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wlTvc7pEMB9A8D61xX2mg5iqNxXNkzjzsrheqwSKxg0=; b=et2InTeGoAYWVKx1cnx7zYwiRdP2Kca6T+mWyIS7l5JpgsjVBqcIG17kc8nQwHmvNA GKH2cpBMiH+bmWaTkSfiYjB9svGeE9vud4viz0tOwzgTBEDW6EOPCmVqxFFlBCK5P944 1BnfJiSusya9Mr4Anv3+d24LaX6NuMt4FqEryxvD3I8CzYYAbCMJjdx5tgKdFLxhb+Pd rPjAKbBw1xjDJi+zg9eRzEE3VBZmX1BHq2CZCqkb1kIRN3h0I4qNvo8YiYTMuyZKxsmT xR5q+9OPavgCEMeMoEBnYoyjr0zoqYWQeb61Jps5ERJS4itlvvOfh7VcrL6zcBn9pCrs 7zbg== MIME-Version: 1.0 X-Received: by 10.180.75.102 with SMTP id b6mr41613060wiw.26.1401225847864; Tue, 27 May 2014 14:24:07 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 14:24:07 -0700 (PDT) In-Reply-To: <01P8B3MKBPVG000052@mauve.mrochek.com> References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> <01P8B3MKBPVG000052@mauve.mrochek.com> Date: Tue, 27 May 2014 14:24:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d04389155e984ae04fa685081 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/J5ll0W2g_A6mmw0R6-WlopESUII Cc: Barry Leiba , draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:24:13 -0000 --f46d04389155e984ae04fa685081 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 2:08 PM, Ned Freed wrote: > > > I would have much less problem with a status code that says, "This > > message was rejected because we were unable to verify the sending > > domain, and policy requires such verification." > > Exactly. This provides a code with real utility, because it tells the > processing agent that the problem isn't with this recipient address, but > with > the message/recipient combination. > > > That could be put in > > here as a general thing, or can be left to DMARC to create (I see no > > reason to wait). This status code could explain, in its description, > > that said verification could come from successful validation of a DKIM > > signature, successful application of SPF, or [perhaps] by another > > verification mechanism that might later be defined. > > The argument for putting it here is so that it is more generally > applicable. > The argument for putting it in the DMARC specification is that would make > it clear that DMARC agents are supposed to use it. > > A middle ground would be to specify it here and reference the > specification in > DMARC. But any of these work for me; I'm more concerned with producing a > timely > specification than I am with the document taxonomy. > Does the -01 version handle these concerns for you as well? -MSK --f46d04389155e984ae04fa685081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 2:08 PM, Ned Freed <ned.freed= @mrochek.com> wrote:

> I would have much less problem with a status code that says, "Thi= s
> message was rejected because we were unable to verify the sending
> domain, and policy requires such verification."

Exactly. This provides a code with real utility, because it tells the=
processing agent that the problem isn't with this recipient address, bu= t with
the message/recipient combination.

> That could be put in
> here as a general thing, or can be left to DMARC to create (I see no > reason to wait). =C2=A0This status code could explain, in its descript= ion,
> that said verification could come from successful validation of a DKIM=
> signature, successful application of SPF, or [perhaps] by another
> verification mechanism that might later be defined.

The argument for putting it here is so that it is more generally appl= icable.
The argument for putting it in the DMARC specification is that would make it clear that DMARC agents are supposed to use it.

A middle ground would be to specify it here and reference the specification= in
DMARC. But any of these work for me; I'm more concerned with producing = a timely
specification than I am with the document taxonomy.
Does the -01 version handle these concerns for you as well?
-MSK
--f46d04389155e984ae04fa685081-- From nobody Tue May 27 15:05:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47C1A073C for ; Tue, 27 May 2014 15:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4egIWYi8b3cR for ; Tue, 27 May 2014 15:05:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 968AC1A0290 for ; Tue, 27 May 2014 15:05:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8B573PMOG003JDO@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 27 May 2014 15:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1401228028; bh=3yszOsgIKr4eqmyhSrYjImsdF6byO54EYzyVDzSZm84=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=sztKtlM4xPUaKKfcReKYLFLbOnRw41WfSWv1Oqp+Amz/g9+n16nPYmgPIklZCkgVZ f15Fiv9VDQJZicsgsPWsm7qS3fQPD1w9/HGpt+WnIGspslzQ6vnbX/M5+I1Vjsc2fM +pfVTFVXrqEypr7lQc2UUPKLXlTWWzpJo30hDcAE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P7ZVUWI9SW000052@mauve.mrochek.com>; Tue, 27 May 2014 15:00:23 -0700 (PDT) Message-id: <01P8B571PW6Y000052@mauve.mrochek.com> Date: Tue, 27 May 2014 15:00:07 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 May 2014 14:24:07 -0700" References: <20140525084948.26994.91004.idtracker@ietfa.amsl.com> <01P8B3MKBPVG000052@mauve.mrochek.com> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XFl6N08IKj7VyPYCVAqG0NSA7Po Cc: Barry Leiba , Ned Freed , draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:05:35 -0000 > On Tue, May 27, 2014 at 2:08 PM, Ned Freed wrote: > > > > > I would have much less problem with a status code that says, "This > > > message was rejected because we were unable to verify the sending > > > domain, and policy requires such verification." > > > > Exactly. This provides a code with real utility, because it tells the > > processing agent that the problem isn't with this recipient address, but > > with > > the message/recipient combination. > > > > > That could be put in > > > here as a general thing, or can be left to DMARC to create (I see no > > > reason to wait). This status code could explain, in its description, > > > that said verification could come from successful validation of a DKIM > > > signature, successful application of SPF, or [perhaps] by another > > > verification mechanism that might later be defined. > > > > The argument for putting it here is so that it is more generally > > applicable. > > The argument for putting it in the DMARC specification is that would make > > it clear that DMARC agents are supposed to use it. > > > > A middle ground would be to specify it here and reference the > > specification in > > DMARC. But any of these work for me; I'm more concerned with producing a > > timely > > specification than I am with the document taxonomy. > > > Does the -01 version handle these concerns for you as well? Yes, it looks OK to me now. Ned From nobody Tue May 27 16:55:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BF21A07D7 for ; Tue, 27 May 2014 16:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0JFEV_jiqDlF for ; Tue, 27 May 2014 16:55:52 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6D93D1A07D5 for ; Tue, 27 May 2014 16:55:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 271EBA05B1 for ; Tue, 27 May 2014 18:55:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTTmJF9NZJiB for ; Tue, 27 May 2014 18:55:49 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0926EA05A9 for ; Tue, 27 May 2014 18:55:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E54B4A05B1 for ; Tue, 27 May 2014 18:55:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IaFBQMC-02XR for ; Tue, 27 May 2014 18:55:48 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id CEA92A05A9 for ; Tue, 27 May 2014 18:55:48 -0500 (CDT) Date: Tue, 27 May 2014 18:55:45 -0500 (CDT) From: Franck Martin To: apps-discuss@ietf.org Message-ID: <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> In-Reply-To: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_40525_880343263.1401234945098" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Better NDR Thread-Index: LNcVuxxafzGtboahQZp94XG9s+dQpg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ycpwh2KS2ZyzQruw-1xUo-sHAS8 Subject: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:55:53 -0000 ------=_Part_40525_880343263.1401234945098 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I was wondering, if anyone has worked or has pointers on making better NDR. I think the tendency nowaday is to reject emails during the SMTP transaction. The sending MTA then produces a NDR based on this SMTP one line. This email is for the consumption of the human who tried to send the email. Many humans cannot make any sense of this. Could we pass back something like a fully formated multipart email than a one line error? Something in plain "english"? ------=_Part_40525_880343263.1401234945098 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I was wondering, if anyone has worked or has pointers on making better NDR.

I think the tendency nowaday is to reject emails during the SMTP transaction. The sending MTA then produces a NDR based on this SMTP one line. This email is for the consumption of the human who tried to send the email.

Many humans cannot make any sense of this. Could we pass back something like a fully formated multipart email than a one line error? Something in plain "english"?
------=_Part_40525_880343263.1401234945098-- From nobody Tue May 27 16:59:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D012A1A07D7 for ; Tue, 27 May 2014 16:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 YYgDB8yWuA3r for ; Tue, 27 May 2014 16:59:03 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0621E1A07D5 for ; Tue, 27 May 2014 16:59:02 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so10256020wes.37 for ; Tue, 27 May 2014 16:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YHRiGsxP9qr+RPOKBzlJxGMCRp1pYqULGZ1NjXleeEQ=; b=LqnJnOjq5xnoSMVEUocpUkHGH9+U5051QmAeUfdGkFrVUsLfTc1kO0xutHkfjwbdxY zbmbFQMXrW+SKX2Edl6OU2LHmfpcvKdUPA/kDVicmc/cziFewQDbgicmq1WSJY442ibd Gg552PhW2Gj3RYP6m1D7WJGcfPz9PF52cAQAXp7oqgBQn5YgqsTbz13dPevF3WtflsPA wEtOrhh30MILfSUAOt9qUTfwWoCpLitYeCE5QxrsEMOkZu7oy1w7LdRKkvxpX3COca63 q5atfZ3gFExNBvaR5hUV7V1CTzxFlQMLqRUV45F5N/IzqwlWk+9cJwsulO+Td6gpA0pv bCbg== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr46674364wjb.35.1401235138751; Tue, 27 May 2014 16:58:58 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 16:58:58 -0700 (PDT) In-Reply-To: <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> Date: Tue, 27 May 2014 16:58:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=089e01419c6ab1342404fa6a7a16 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dOoWwbeUrUtRF-QcpuI-xaycbXY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:59:05 -0000 --089e01419c6ab1342404fa6a7a16 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 4:55 PM, Franck Martin wrote: > I was wondering, if anyone has worked or has pointers on making better NDR. > > I think the tendency nowaday is to reject emails during the SMTP > transaction. The sending MTA then produces a NDR based on this SMTP one > line. This email is for the consumption of the human who tried to send the > email. > > Many humans cannot make any sense of this. Could we pass back something > like a fully formated multipart email than a one line error? Something in > plain "english"? > > Isn't this what the text/plain part of a DSN is for? -MSK --089e01419c6ab1342404fa6a7a16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 4:55 PM, Franck Martin <fr= anck@peachymango.org> wrote:
I was wondering, if a= nyone has worked or has pointers on making better NDR.

I think the tendency nowaday is to reject emails during= the SMTP transaction. The sending MTA then produces a NDR based on this SM= TP one line. This email is for the consumption of the human who tried to se= nd the email.

Many humans cannot make any sense of this. Could we pass bac= k something like a fully formated multipart email than a one line error? So= mething in plain "english"?


Isn't this what the text/plain part of a DSN is for= ?

-MSK
--089e01419c6ab1342404fa6a7a16-- From nobody Tue May 27 17:20:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8C1A081F for ; Tue, 27 May 2014 17:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 O9TqR80d7mGZ for ; Tue, 27 May 2014 17:20:23 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453A71A07DD for ; Tue, 27 May 2014 17:20:22 -0700 (PDT) Received: (qmail 45070 invoked from network); 28 May 2014 00:20:17 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 28 May 2014 00:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3d2d.53852bc1.k1405; i=johnl@user.iecc.com; bh=zVrqeIZ2CJkLQXexcsv+gIRmcL/I/6V4neBtiJdT3Z0=; b=epPjVhqRcKqC0Bu9w0CgDcCS1Fr/WFFUt33zAXDUQgqmSBP+AalCrjvRaO/A8qRdh3n4SBIon+z7Ro2wxU/En5cAqLGw084rkLJEukePoSvbSa7Jtend42KoNnkLXtDNVvcs6ZplSlULIFaQkwzgSOHmlHZAbgbZ7ymwF2RCB+g0tOLpf6WT4FFjknVXXgIDnKgMCyGoEjuz0oAvgn7WQLptR1lK9cTjHuzSQ+XZ5XL4OLwfbQv40ER0TtmWsWk/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3d2d.53852bc1.k1405; olt=johnl@user.iecc.com; bh=zVrqeIZ2CJkLQXexcsv+gIRmcL/I/6V4neBtiJdT3Z0=; b=GDkIM110mF6J4xsU2frwpLofkyy5vUoLkqKXfEosyRSafYh0uoAW+ixgkbb5kYwGKLFsTpBhiSG1n+ghHfixgMMCcvKU60SShkRzsapzMXRiPWkC5hBGDdkoWO++zli0Ud5ptxNE7+dvSDw1opaQXQdHXEiVLpnMPX9rTN1SPm23g91DxYyyffmlNaXHIkQE1m3zsWAEkmHtk6bRy/vesJkD/rDiRTiltl5RXcVKfIzw9LlC2J+0Q0DWAczrdCAI Date: 28 May 2014 00:19:55 -0000 Message-ID: <20140528001955.15660.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/j8nNKTkImHEjRYx8XcvluUm9br0 Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:20:25 -0000 >> Many humans cannot make any sense of this. Could we pass back something >> like a fully formated multipart email than a one line error? Something in >> plain "english"? >> >> >Isn't this what the text/plain part of a DSN is for? Yes, of course. Also see https://bounce.io/ R's, John From nobody Tue May 27 17:21:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E151A081D for ; Tue, 27 May 2014 17:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 dlI979o_U-Yv for ; Tue, 27 May 2014 17:21:31 -0700 (PDT) Received: from jacobrideout.net (jacobrideout.net [74.50.50.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF2C1A07F9 for ; Tue, 27 May 2014 17:21:31 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by jacobrideout.net (Postfix) with ESMTPSA id B3DB84021D for ; Tue, 27 May 2014 20:21:27 -0400 (EDT) Authentication-Results: jacobrideout.net; dmarc=none header.from=jacobrideout.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jacobrideout.net; s=2012a; t=1401236487; bh=QTkMzZx+Zcc9AiYX+vDMV4Nc9xQmcAeIoutm0j6cA/E=; h=Reply-To:In-Reply-To:References:From:Date:Subject:To:Cc:From; b=UMejAA/mAdZU9bcO3hY2VZYacxiyheMfdbBEOgFYlC2VesRT2TDT4T1AUY7l0HxC2 UHl2EzauKz+levbaYGwTnvH4k23KKcOO/WUUVo6QreCb3OAxfxXqjfp9wQZQcUmDBX Sq/QEdFyWh+NW2uxp+d7s2bmjEQdbb+XBwni7hHU= Received: by mail-ie0-f176.google.com with SMTP id rl12so9565474iec.21 for ; Tue, 27 May 2014 17:21:26 -0700 (PDT) X-Received: by 10.50.253.130 with SMTP id aa2mr38365941igd.39.1401236486898; Tue, 27 May 2014 17:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.216.65 with HTTP; Tue, 27 May 2014 17:21:06 -0700 (PDT) In-Reply-To: <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> From: Jacob R Rideout Date: Tue, 27 May 2014 20:21:06 -0400 Message-ID: To: Franck Martin Content-Type: multipart/alternative; boundary=001a113445ce0c50c304fa6acb97 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IBY_y09tO5a-0pJz9CDgs45iQ2I Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@jacobrideout.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:21:32 -0000 --001a113445ce0c50c304fa6acb97 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 7:55 PM, Franck Martin wrote: > I was wondering, if anyone has worked or has pointers on making better NDR. > > I think the tendency nowaday is to reject emails during the SMTP > transaction. The sending MTA then produces a NDR based on this SMTP one > line. This email is for the consumption of the human who tried to send the > email. > > Many humans cannot make any sense of this. Could we pass back something > like a fully formated multipart email than a one line error? Something in > plain "english"? > Take a look a Bounce.io. --001a113445ce0c50c304fa6acb97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a113445ce0c50c304fa6acb97-- From nobody Tue May 27 17:31:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC451A081D for ; Tue, 27 May 2014 17:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E8Vc41Nr7KdL for ; Tue, 27 May 2014 17:30:56 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3CB1A0316 for ; Tue, 27 May 2014 17:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1641CA045B; Tue, 27 May 2014 19:30:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0Ua9QVZga9N; Tue, 27 May 2014 19:30:53 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EA454A046B; Tue, 27 May 2014 19:30:52 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D3EB7A046A; Tue, 27 May 2014 19:30:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6v-tUcxtDoKY; Tue, 27 May 2014 19:30:52 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id B906CA045B; Tue, 27 May 2014 19:30:52 -0500 (CDT) Date: Tue, 27 May 2014 19:30:52 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <970775108.41049.1401237052201.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41048_1150910691.1401237052201" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Better NDR Thread-Index: aZ2YPufGrmTh4ySfuN9uXTCPo/coqg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FmAz1PdhfODsmGJm18uIjz69RWs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:30:58 -0000 ------=_Part_41048_1150910691.1401237052201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "IETF Apps Discuss" > Sent: Tuesday, May 27, 2014 4:58:58 PM > Subject: Re: [apps-discuss] Better NDR > On Tue, May 27, 2014 at 4:55 PM, Franck Martin < franck@peachymango.org > > wrote: > > I was wondering, if anyone has worked or has pointers on making better NDR. > > > I think the tendency nowaday is to reject emails during the SMTP > > transaction. > > The sending MTA then produces a NDR based on this SMTP one line. This email > > is for the consumption of the human who tried to send the email. > > > Many humans cannot make any sense of this. Could we pass back something > > like > > a fully formated multipart email than a one line error? Something in plain > > "english"? > > Isn't this what the text/plain part of a DSN is for? This is if the receiver decides to send a bounce as an email, with all the backscatter problems that may result. If the receiver gets an SMTP error "500 mailbox invalid", then the receiver needs to translate that into something readable by humans, the interpretation by the sender may loose the original meaning of the receiver. This is a simple example, but there are more complicated one. Gmail tries to pack the error message on several lines by using /r/n in the error text. Tracking what error message really means is complex, just trying to figure out if it is a hard or soft bounce, is complicated with no opensource library to do that... It would make more sense, if the receiver would pass a meaningful message during the SMTP transaction. ------=_Part_41048_1150910691.1401237052201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent:= Tuesday, May 27, 2014 4:58:58 PM
Subject: Re: [apps-discuss]= Better NDR

On Tue, May 27, 2014 at 4:55= PM, Franck Martin <franck@peachymango.org> wrote:
<= div class=3D"gmail_extra">
I was wondering, if anyone has worked or ha= s pointers on making better NDR.

I think the tende= ncy nowaday is to reject emails during the SMTP transaction. The sending MT= A then produces a NDR based on this SMTP one line. This email is for the co= nsumption of the human who tried to send the email.

Man= y humans cannot make any sense of this. Could we pass back something like a= fully formated multipart email than a one line error? Something in plain "= english"?


Isn't t= his what the text/plain part of a DSN is for?
This is if the receiver decides to send a bounce as an emai= l, with all the backscatter problems that may result.

If the receiver gets an SMTP error "500 mailbox invalid", then the = receiver needs to translate that into something readable by humans, the int= erpretation by the sender may loose the original meaning of the receiver. T= his is a simple example, but there are more complicated one.
Gmail tries to pack the error message on several lines by using= /r/n in the error text.

Tracking what error m= essage really means is complex, just trying to figure out if it is a hard o= r soft bounce, is complicated with no opensource library to do that...
<= /div>

It would make more sense, if the receiver would pa= ss a meaningful message during the SMTP transaction.
= ------=_Part_41048_1150910691.1401237052201-- From nobody Tue May 27 17:34:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E32A1A0316 for ; Tue, 27 May 2014 17:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gEbtc4oG0StD for ; Tue, 27 May 2014 17:34:53 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id D53171A02E4 for ; Tue, 27 May 2014 17:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 99F81A058B; Tue, 27 May 2014 19:34:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OXaTcFnITR8; Tue, 27 May 2014 19:34:49 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7A3DCA05B1; Tue, 27 May 2014 19:34:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 64400A05AD; Tue, 27 May 2014 19:34:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tjV10rYQzPqd; Tue, 27 May 2014 19:34:49 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 4945BA058B; Tue, 27 May 2014 19:34:49 -0500 (CDT) Date: Tue, 27 May 2014 19:34:49 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <2050738472.41096.1401237289133.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> <970775108.41049.1401237052201.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41095_1268526263.1401237289132" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Better NDR Thread-Index: aZ2YPufGrmTh4ySfuN9uXTCPo/coqpDcRFnu Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tGVzdH7pq-yHSt4ZPV4q-924isc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:34:55 -0000 ------=_Part_41095_1268526263.1401237289132 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit corrected sender vs receiver > ----- Original Message ----- > > From: "Murray S. Kucherawy" > > > To: "Franck Martin" > > > Cc: "IETF Apps Discuss" > > > Sent: Tuesday, May 27, 2014 4:58:58 PM > > > Subject: Re: [apps-discuss] Better NDR > > > On Tue, May 27, 2014 at 4:55 PM, Franck Martin < franck@peachymango.org > > > wrote: > > > > I was wondering, if anyone has worked or has pointers on making better > > > NDR. > > > > > > I think the tendency nowaday is to reject emails during the SMTP > > > transaction. > > > The sending MTA then produces a NDR based on this SMTP one line. This > > > email > > > is for the consumption of the human who tried to send the email. > > > > > > Many humans cannot make any sense of this. Could we pass back something > > > like > > > a fully formated multipart email than a one line error? Something in > > > plain > > > "english"? > > > > > Isn't this what the text/plain part of a DSN is for? > > This is if the receiver decides to send a bounce as an email, with all the > backscatter problems that may result. > If the sender gets an SMTP error "500 mailbox invalid", then the sender needs > to translate that into something readable by humans, the interpretation by > the sender may loose the original meaning of the receiver. This is a simple > example, but there are more complicated one. > Gmail tries to pack the error message on several lines by using /r/n in the > error text. > Tracking what error message really means is complex, just trying to figure > out if it is a hard or soft bounce, is complicated with no opensource > library to do that... > It would make more sense, if the receiver would pass a meaningful long > message during the SMTP transaction. ------=_Part_41095_1268526263.1401237289132 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
corrected sender vs receiver


From: "Murray S. Kucherawy" <superuser@gmail.com>
= To: "Franck Martin" <franck@peachymango.org>
Cc: "IETF = Apps Discuss" <apps-discuss@ietf.org>
Sent: Tuesday, May 27= , 2014 4:58:58 PM
Subject: Re: [apps-discuss] Better NDR
=
On Tue, May 27, 2014 at 4:55 PM, Franck Martin <= span dir=3D"ltr"><franck@peachymango.org> wrote:
I was wondering, if anyone has worked or has pointers on making= better NDR.

I think the tendency nowaday is to re= ject emails during the SMTP transaction. The sending MTA then produces a ND= R based on this SMTP one line. This email is for the consumption of the hum= an who tried to send the email.

Many humans cannot make= any sense of this. Could we pass back something like a fully formated mult= ipart email than a one line error? Something in plain "english"?
<= /div>


Isn't this what the text/pl= ain part of a DSN is for?
This= is if the receiver decides to send a bounce as an email, with all the back= scatter problems that may result.

If the sende= r gets an SMTP error "500 mailbox invalid", then the sender needs to transl= ate that into something readable by humans, the interpretation by the sende= r may loose the original meaning of the receiver. This is a simple example,= but there are more complicated one.

Gmail tries = to pack the error message on several lines by using /r/n in the error text.=

Tracking what error message really means is c= omplex, just trying to figure out if it is a hard or soft bounce, is compli= cated with no opensource library to do that...

It would make more sense, if the receiver would pass a meaningful long mes= sage during the SMTP transaction.

------=_Part_41095_1268526263.1401237289132-- From nobody Tue May 27 17:35:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE91B1A02E4 for ; Tue, 27 May 2014 17:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SIou3rvFC31Y for ; Tue, 27 May 2014 17:35:18 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D991A0829 for ; Tue, 27 May 2014 17:35:15 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so10126328wgg.25 for ; Tue, 27 May 2014 17:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3PZmpPrHjo+vqh/9sT+QQ3FVx+9qf3MgXUMoH7zNvnw=; b=xjgXxs1eST4EntMJNpNwtwi2hNeezoVm24ia6ZJWlqp8+xpv4B6oW9LNE9RS2orbLE sYIT7O+36f8Y1G+kNiVmsTKNtoRUQPDQBU5sp5wWKVvrDx1PvJXgIATbs5axsjZSBdoX gjhvogd7fz+O3C3LFJvE+9+4iQtoYgmdwtGf1XvBRF5eZ+SP7QVj3Sx7mXBBFuEIAoy9 +iqpEys9eKRKa+X04G+5+nh34p6eALpiPhLP7ioOCozeE6+xcN5tRl4yK+DM/tHCwy2h cpWvHzpor4S1TBzNxW50gWN1cTVuIkzD0dT5p4onSkRC6kwfJ0edGDtXm09/Jok4z4VL z9yw== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr46906189wjb.35.1401237310771; Tue, 27 May 2014 17:35:10 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 27 May 2014 17:35:10 -0700 (PDT) In-Reply-To: <970775108.41049.1401237052201.JavaMail.zimbra@peachymango.org> References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> <970775108.41049.1401237052201.JavaMail.zimbra@peachymango.org> Date: Tue, 27 May 2014 17:35:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=089e01419c6a27965004fa6afc05 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/f08KCMa-MK78Y-xg-rsKSNFf02w Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:35:19 -0000 --089e01419c6a27965004fa6afc05 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 5:30 PM, Franck Martin wrote: > ------------------------------ > > > Isn't this what the text/plain part of a DSN is for? > > This is if the receiver decides to send a bounce as an email, with all the > backscatter problems that may result. > > If the receiver gets an SMTP error "500 mailbox invalid", then the > receiver needs to translate that into something readable by humans, the > interpretation by the sender may loose the original meaning of the > receiver. This is a simple example, but there are more complicated one. > Either way, a DSN is generated, whether it's by the client or the server. I think your question reduces to how useful to an end user the text part of that is. > Gmail tries to pack the error message on several lines by using /r/n in > the error text. > > Tracking what error message really means is complex, just trying to figure > out if it is a hard or soft bounce, is complicated with no opensource > library to do that... > Isn't the first digit of the SMTP reply code all you need to figure out if it's a permanent or temporary failure? If the issue is parsing a DSN for that information, then that's the stuff that's supposed to be in the second MIME part. The problem is that not all DSN generators follow the RFC. > It would make more sense, if the receiver would pass a meaningful message > during the SMTP transaction. > Enhanced status codes were added to make the SMTP reply more meaningful. Beyond that is the text part, which isn't really "safe" for standardization. So is your question really: How do we encourage DSN generators to translate SMTP replies and enhanced status codes into something more useful to end users? Or do you want something more fine-grained than the codes we already have? -MSK --089e01419c6a27965004fa6afc05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 5:30 PM, Franck Martin <fr= anck@peachymango.org> wrote:


Isn't this what the text/plain p= art of a DSN is for?
This is if the receiver decides to send a bounce as an email, with all t= he backscatter problems that may result.

If the receiver gets an SMTP error "500 mail= box invalid", then the receiver needs to translate that into something= readable by humans, the interpretation by the sender may loose the origina= l meaning of the receiver. This is a simple example, but there are more com= plicated one.

Either way, a DSN is generated= , whether it's by the client or the server.=C2=A0 I think your question= reduces to how useful to an end user the text part of that is.
=C2=A0
Gmail tries to pack the er= ror message on several lines by using /r/n in the error text.

Tracking what error message really means is compl= ex, just trying to figure out if it is a hard or soft bounce, is complicate= d with no opensource library to do that...

Isn't the first digit of the SMTP reply code all yo= u need to figure out if it's a permanent or temporary failure?

<= /div>
If the issue is parsing a DSN for that information, then that'= ;s the stuff that's supposed to be in the second MIME part.=C2=A0 The p= roblem is that not all DSN generators follow the RFC.
=C2=A0
It would make more sense, if the receiver would pass a meaningful message = during the SMTP transaction.

E= nhanced status codes were added to make the SMTP reply more meaningful.=C2= =A0 Beyond that is the text part, which isn't really "safe" f= or standardization.

So is your question really: How do we = encourage DSN generators to translate SMTP replies and enhanced status code= s into something more useful to end users?=C2=A0 Or do you want something m= ore fine-grained than the codes we already have?

-MSK
--089e01419c6a27965004fa6afc05-- From nobody Tue May 27 17:51:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A58C1A02C5 for ; Tue, 27 May 2014 17:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 xWjDZvFTqm6I for ; Tue, 27 May 2014 17:51:27 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 229191A0833 for ; Tue, 27 May 2014 17:51:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D499B60529; Tue, 27 May 2014 19:51:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBfZocVIFVM8; Tue, 27 May 2014 19:51:23 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B3BA460503; Tue, 27 May 2014 19:51:23 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 94D556052E; Tue, 27 May 2014 19:51:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bx2WLTs42uIu; Tue, 27 May 2014 19:51:23 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 62C3060529; Tue, 27 May 2014 19:51:23 -0500 (CDT) Date: Tue, 27 May 2014 19:51:23 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1135782268.41257.1401238283133.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <10504166.40474.1401234823820.JavaMail.zimbra@peachymango.org> <1914377058.40526.1401234945099.JavaMail.zimbra@peachymango.org> <970775108.41049.1401237052201.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41256_1761420709.1401238283132" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Better NDR Thread-Index: DlPfgMLQYwFv4dAxedw5XCnMA89Mbg== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YiiMsR0hiLP_GviZEdS3XiybQws Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Better NDR X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:51:28 -0000 ------=_Part_41256_1761420709.1401238283132 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "IETF Apps Discuss" > Sent: Tuesday, May 27, 2014 5:35:10 PM > Subject: Re: [apps-discuss] Better NDR > On Tue, May 27, 2014 at 5:30 PM, Franck Martin < franck@peachymango.org > > wrote: > > > Isn't this what the text/plain part of a DSN is for? > > > > > This is if the receiver decides to send a bounce as an email, with all the > > backscatter problems that may result. > > > If the receiver gets an SMTP error "500 mailbox invalid", then the receiver > > needs to translate that into something readable by humans, the > > interpretation by the sender may loose the original meaning of the > > receiver. > > This is a simple example, but there are more complicated one. > > Either