From nobody Tue Jul 1 00:34: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 AB6471A0185 for ; Tue, 1 Jul 2014 00:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_54=0.6, J_CHICKENPOX_56=0.6, 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 GmzSoQhYmU5e for ; Tue, 1 Jul 2014 00:34:33 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 06D7B1A017D for ; Tue, 1 Jul 2014 00:34:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,580,1399989600"; d="scan'208";a="210972189" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 01 Jul 2014 17:27:55 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7485"; a="241396495" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 01 Jul 2014 17:34:31 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 1 Jul 2014 17:34:31 +1000 From: "Manger, James" To: Carsten Bormann Date: Tue, 1 Jul 2014 17:34:29 +1000 Thread-Topic: [apps-discuss] Post-WG-LC changes in draft-ietf-appsawg-json-merge-patch Thread-Index: Ac+U9iu1H/aS+ek+Q4mXe2R+hzwCHgABxMdA Message-ID: <255B9BB34FB7D647A506DC292726F6E115496E96A5@WSMSG3153V.srv.dir.telstra.com> References: <20140630170757.27164.41689.idtracker@ietfa.amsl.com> <211EFBCD-6605-414B-8680-652C98214B5E@vpnc.org> <255B9BB34FB7D647A506DC292726F6E115496E8CC6@WSMSG3153V.srv.dir.telstra.com> <8186C77A-9628-4033-9CBA-8B4CCCFC6F62@tzi.org> In-Reply-To: <8186C77A-9628-4033-9CBA-8B4CCCFC6F62@tzi.org> 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/MMG5A4hrjfHqlh9K8FCv7wXcsGY Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Post-WG-LC changes in 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: Tue, 01 Jul 2014 07:34:34 -0000 WWVzLCB0aGF0IGxvb2sgcmlnaHQsIENhcnN0ZW4uDQpFdmVuIG5vdCBrbm93aW5nIFJ1YnkgKHdo aWNoIEkgZ3Vlc3MgdGhpcyBjb2RlIGlzKSwgdGhlIGNvZGUgaXMgc2ltcGxlIGVub3VnaCB0byB1 bmRlcnN0YW5kIGFuZCBzZWUgaXQgaXMgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nIC0tIHdoaWNoIGlz IGEgY29tcGxpbWVudCB0byBSdWJ5IGFuZCBtZXJnZS1wYXRjaC4NCg0KW2Fzc3VtaW5nIHRoYXQg aW4gUnVieSBuaWwsICJ1bmRlZmluZWQiLCBhbmQgYSBKU09OIG51bGwgYXJlIHNvcnQgb2YgdGhl IHNhbWVdDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXSANClNlbnQ6IFR1 ZXNkYXksIDEgSnVseSAyMDE0IDQ6MzIgUE0NClRvOiBNYW5nZXIsIEphbWVzDQpDYzogUGF1bCBI b2ZmbWFuOyBJRVRGIEFwcHMgRGlzY3Vzcw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFBv c3QtV0ctTEMgY2hhbmdlcyBpbiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1tZXJnZS1wYXRjaA0K DQpHb29kIHBvaW50cy4NCg0KSGVyZSBpcyBteSBpbXBsZW1lbnRhdGlvbjoNCg0KZGVmIG1lcmdl X3BhdGNoKG9yaWcsIHBhdGNoKQ0KICBpZiBIYXNoID09PSBwYXRjaA0KICAgIG9yaWcgPSB7fSB1 bmxlc3MgSGFzaCA9PT0gb3JpZw0KICAgIHBhdGNoLmVhY2ggZG8gfGssIHZ8DQogICAgICBpZiB2 Lm5pbD8NCiAgICAgICAgb3JpZy5kZWxldGUoaykNCiAgICAgIGVsc2UNCiAgICAgICAgb3JpZ1tr XSA9IG1lcmdlX3BhdGNoKG9yaWdba10sIHYpDQogICAgICBlbmQNCiAgICBlbmQNCiAgICBvcmln DQogIGVsc2UNCiAgICBwYXRjaA0KICBlbmQNCmVuZCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIyB5ZXAsIHRoYXQncyAxNSBsaW5lcy4NCg0KVGhpcyBjb3VsZCBzZXJ2ZSB0byByZXBsYWNl IHRoZSBBcHBlbmRpeCBCLg0KVGhpcyBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBoYXZlIHRoZSBi dWcgdGhhdCB5b3UgbWVudGlvbjoNCg0KPiAzLg0KPiBUaGUgbWVyZ2UgYmVoYXZpb3VyIGluIGRy YWZ0LTAzIGlzIG5vdyBkZWxpYmVyYXRlbHkgdW5kZWZpbmVkIGlmIHRoZSBwYXRjaCBpcyBub3Qg YW4gb2JqZWN0IG9yIGFycmF5LiBIb3dldmVyLCBpdCBpcyBhbHNvIHVuZGVmaW5lZCBpZiB0aGUg dGFyZ2V0IGlzIG5vdCBhbiBvYmplY3Qgb3IgYXJyYXkuIFRoaXMgdW5kZWZpbmVkIGJlaGF2aW91 ciBjYW4gb25seSBkbyBoYXJtLiBNYW55IGltcGxlbWVudGF0aW9ucyB3aWxsIGludm9sdmUgYSBt ZXJnZSh0YXJnZXQsIHBhdGNoKSBmdW5jdGlvbiB0aGF0IGFjY2VwdHMgYW55IEpTT04gZm9yIGl0 cyBhcmd1bWVudHMgc28gd2UgbWF5IGFzIHdlbGwgZGVmaW5lIGFsbCB0aGUgcmVzdWx0cy4gSXQg aXMgYWxzbyBzdHJhbmdlIHRvIG1lbnRpb24gYXJyYXlzIGV4cGxpY2l0bHkgYXMgbWVyZ2UtcGF0 Y2ggdHJlYXRzIGFycmF5cyBqdXN0IGxpa2UgYSBwcmltaXRpdmUuDQoNClRoZXJlZm9yZSwgaXQg ZG9lcyBub3QgY2hlY2sgYWdhaW5zdCB0aGUgZXhhbXBsZXM6DQoNCk1pc21hdGNoOiANCm9yaWc6 ICAgICB7ImEiOiJmb28ifQ0KcGF0Y2g6ICAgIG51bGwNCmRyYWZ0OiAgICAiSW52YWxpZCBFeGFt cGxlIg0KYWN0dWFsOiAgIG51bGwNCk1pc21hdGNoOiANCm9yaWc6ICAgICB7ImEiOiJmb28ifQ0K cGF0Y2g6ICAgICJiYXIiDQpkcmFmdDogICAgIkludmFsaWQgRXhhbXBsZSINCmFjdHVhbDogICDi gJxiYXIiDQoNCkl0IGRvZXMgY2hlY2sgYWdhaW5zdCB5b3VyIGV4YW1wbGU6DQoNCiAgICAgICAg ICAge30gICAgICAgICAgICAgIHsiYSI6eyJiYiI6ICAgICB7ImEiOnsiYmIiOnt9fX0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHsiY2NjIjpudWxsfX19DQoNCkkgYmVsaWV2ZSB0aGUgYWJv dmUgaW1wbGVtZW50YXRpb24gaXMgZXhhY3RseSB3aGF0IG1lcmdlLXBhdGNoIHNob3VsZCBkbywg YW5kIHRoZSB0ZXh0IHNob3VsZCBiZSB1cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCg== From nobody Tue Jul 1 07:27: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 BA3341A0319 for ; Tue, 1 Jul 2014 07:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, 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 7z_MAss1EeeM for ; Tue, 1 Jul 2014 07:27:38 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84A61A02F8 for ; Tue, 1 Jul 2014 07:27:37 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hw13so7750162qab.3 for ; Tue, 01 Jul 2014 07:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1dQMEQuzzfREm/jACf+4FAJupM0ZFd0FPkAdjUmGCPU=; b=C/fmJXphcMuFoU2SlOyZi/heMZmIeWfmjpJAyOH10NtDfDhhy20Y5tRLD8sxZOHS+R Ix4N4o+byrcpZAIm33WhP6jSUhm48dawxYqduecGQOQBfImqgiWVP86/JbqQc7WZ2swH v6lt4UsdLu+sbX3OwXeRZeB/sAMyBOIrcHOdgZI5jzIMQtjMfODF73D/S3bycWAdH8Tc dzsVFRMW08ALV3jpyBVXFdPCEiBkrMSVD37NiUqJ8cG4TXj/9P5ff/P3Ggyzk9igJmaa XgGqtPRZD0eXoTSI6SHxRgmPM3gLejXhcFgM0J1UfQSFziIOjeqSmQ3X5JypWKqrtHA5 MiNA== 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:from:date :message-id:subject:to:cc:content-type; bh=1dQMEQuzzfREm/jACf+4FAJupM0ZFd0FPkAdjUmGCPU=; b=ktTQDZYV8IT8oiMHndzm0rmVW7jakCa7m8DXY8KBKnr7JVJ58dmlzMOwJj3yxtwIFo Ba0BtRx1BdCwRs57LeN5sGtiUDvnfrUvUM7IOzRj0/mHVDJcq5rTNhjOXZ1qCfAqzPTr Wm/slpNB4KG8fNKSQGdvIOdNVo00M+cAK5srPouaxlAlJ9DmvnL1gsTufuQE1jnZlVgE 0UjppbdXVvsIf/HZQKQ1AOS73NuKlh5UTXlbcll+JBoq/MJ+IO0AE7z3NfXF4k5KXlub FLpFjFIPjy9oDsUCHNoY2GEWJRjr0D7Lm/WUEYnG/AmhUwytulVbJIbwJQJqjsa9ht/g 2yaQ== X-Gm-Message-State: ALoCoQkrf+a2KMbf1SZD/F8ogLgptaQRIQkVNyYZODv9Ha6fTszovEu7rIn4IkK8Ezp9KwV6WAIy X-Received: by 10.224.126.135 with SMTP id c7mr53048107qas.6.1404224856731; Tue, 01 Jul 2014 07:27:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Tue, 1 Jul 2014 07:27:16 -0700 (PDT) In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> From: Wei Chuang Date: Tue, 1 Jul 2014 07:27:16 -0700 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11c307d4c55ac104fd2293f7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hl3GEhxg-JPG0gTpkoXbPIjtFZU Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 01 Jul 2014 14:27:39 -0000 --001a11c307d4c55ac104fd2293f7 Content-Type: text/plain; charset=ISO-8859-1 Before this thread is done, let me mention a modification to this concept to see what your opinion might be (or anyone else reading this): You've mentioned earlier that mailing lists frequently strip content that will preclude deployment of this concept. This could be mitigated as follows: Though at the risk of making this proposal more complicated, there is a way of dealing with this. The proposal could say to extend the DKIM to support the signing only certain stable MIME parts such as: Content-Type: text/plain that are unlikely to get stripped (or other base alternate part). This also signs the MIME multipart metadata to detect stripping, and as before the headers. Diffs are only made of the signed parts. The upside is this still provides forwarding trust chaining, and allows the recipient to reconstruct the text forwarding versions. This text typically should get at the meaning of sender, and can then be verified against the alternate formats such as HTML not signed. The downside non text formatting such as HTML will become a Spam / Phishing attack vector. Also this will requires an extension to DKIM to allow these restricted body MIME part signings. Thanks, -Wei On Mon, Jun 30, 2014 at 11:52 AM, John R Levine wrote: > Forced on list managers, but not on MUA authors. If we can get MUA >>> authors to change the way they display list mail, we could do something >>> much simpler like the message wrapping that's an option in recent >>> versions >>> of Mailman. >>> >> >> With message wrapping, my understanding is it wraps the original message >> in >> a MIME part. If that's the case, then that's pretty much the storage (or >> more) of doing the diff. >> > > There's a major practical difference: the message wrap hack is essentially > a single message digest. List managers already have code to build digests, > and MUAs can display them, if not always very beautifully. Lists do not > have code to save the original message, then later use some diff'ing > algorithm to create new message parts that no MUA knows how to display. > > > I just don't seem them (us, really) implementing something as complex as >>> your proposal, particularly if it turns out that it needs a lot of >>> tweaking >>> to avoid false positives. >>> >> >> Actually this proposal is supposed to resolve the tweaking that is needed >> today with DMARC. What tweaking do see you will be required? >> > > Incoming mail filters will have to look at the diffs and apply some yet to > be invented heuristics to analyse the them and decide whether the before > and after versions are "too different". I have no idea what a satisfactory > definition of "too different" is, and would be surprised if anyone else > did. There isn't even a generally accepted version of diff syntax -- > programs like the freeware "patch" have extensive heuristics to try to > decode all of the various diff formats they have to deal with. > > Anyway, the two of us have been arguing in a vacuum. Let's see what other > people thing. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > --001a11c307d4c55ac104fd2293f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Before this thread is done, let me mention a modification = to this concept to see what your opinion might be (or anyone else reading t= his):

You've mentioned earlier that mailing lis= ts frequently strip content that will preclude deployment of this concept. = =A0This could be mitigated as follows:

Though at the risk of making this proposal more complicated, there is = a way of dealing with this. =A0The proposal could say to extend the DKIM to= support the signing only certain stable MIME parts such as: Content-Type: = text/plain that are unlikely to get stripped (or other base alternate part)= . =A0This also signs the MIME multipart metadata to detect stripping, and a= s before the headers. =A0Diffs are only made of the signed parts. =A0The up= side is this still provides forwarding trust chaining, and allows the recip= ient to reconstruct the text forwarding versions. =A0This =A0text typically= should get at the meaning of sender, and can then be verified against the = alternate formats such as HTML not signed. =A0The downside non text formatt= ing such as HTML will become a Spam / Phishing attack vector. =A0Also this = will requires an extension to DKIM to allow these restricted body MIME part= signings.=A0

=
Thanks,
-Wei


O= n Mon, Jun 30, 2014 at 11:52 AM, John R Levine <johnl@taugh.com> wrote:
Forced on list managers, but not on MUA authors. =A0If we can get MUA
authors to change the way they display list mail, we could do something
much simpler like the message wrapping that's an option in recent versi= ons
of Mailman.

With message wrapping, my understanding is it wraps the original message in=
a MIME part. =A0If that's the case, then that's pretty much the sto= rage (or
more) of doing the diff.

There's a major practical difference: the message wrap hack is essentia= lly a single message digest. List managers already have code to build diges= ts, and MUAs can display them, if not always very beautifully. =A0Lists do = not have code to save the original message, then later use some diff'in= g algorithm to create new message parts that no MUA knows how to display.

I just don't seem them (us, really) implementing something as complex a= s
your proposal, particularly if it turns out that it needs a lot of tweaking=
to avoid false positives.

Actually this proposal is supposed to resolve the tweaking that is needed today with DMARC. =A0What tweaking do see you will be required?

Incoming mail filters will have to look at the diffs and apply some yet to = be invented heuristics to analyse the them and decide whether the before an= d after versions are "too different". =A0I have no idea what a sa= tisfactory definition of "too different" is, and would be surpris= ed if anyone else did. =A0There isn't even a generally accepted version= of diff syntax -- programs like the freeware "patch" have extens= ive heuristics to try to decode all of the various diff formats they have t= o deal with.

Anyway, the two of us have been arguing in a vacuum. =A0Let's see what = other people thing.


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

--001a11c307d4c55ac104fd2293f7-- From nobody Tue Jul 1 09:29: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 535751B282D for ; Tue, 1 Jul 2014 09:29:39 -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 YSXq94a8_rpG for ; Tue, 1 Jul 2014 09:29: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 F21F81B27F3 for ; Tue, 1 Jul 2014 09:29:37 -0700 (PDT) Received: (qmail 98959 invoked from network); 1 Jul 2014 16:29:35 -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; s=1828e.53b2e1ef.k1407; bh=HHcX9wsRldQdhiSaQyd8ixeRWYNI/9SJma3JTa01mtw=; b=aizemGxk+CaEEckpOxwuPdrCgzKJ/g+/Af7QRAGuzKYs/qCOpJF3JhNJio8EsAYzSs0mnoO0irxuXc1D22mBDI9PlEcACMKSr/NVorCOnOcAmtA+41vlzYkjPXlyQfHTizNV6AyGNW4bQ/bIC3QfboXPmUVuuvZ4VBH1V9Zuz0q069gfMMS8QQv+Hw879t23yrsV71RbE6PxoP8ARYv2+6p2ao4l6Yf79422v3ugVXWMkOj/VT9/i/ir/kxf5ao0 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; s=1828e.53b2e1ef.k1407; bh=HHcX9wsRldQdhiSaQyd8ixeRWYNI/9SJma3JTa01mtw=; b=nJjae+ddSKfvm4PrRHqSXCjlzSsSWqJ9h63Ly78KHka91aFfYU7PMQw4s9+OV87f1+31cC1aia2qZOPRos2BwqWWJCbbX4nPoKyMDuPPGIhA3rsW/LbHSMHnK0Rh3fFjt/IFM25Qt9seWIeJnmGmPQOInr1SmLQLfgcA4LcGT5XNtSVADo7btJqIlw6sLpLZ4+Q4dkW1AKGTHsD1MROIwnZYLVvT0neNplsDHP8Eh4khpBCye9Z8xN/utONRYwVf 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; 01 Jul 2014 16:29:35 -0000 Date: 1 Jul 2014 12:29:34 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t5-1-AeQ_vkew4o11nACQUUG_hc Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 01 Jul 2014 16:29:39 -0000 > Though at the risk of making this proposal more complicated, there is a way > of dealing with this. The proposal could say to extend the DKIM to support > the signing only certain stable MIME parts such as: Content-Type: > text/plain that are unlikely to get stripped (or other base alternate > part). This also signs the MIME multipart metadata to detect stripping, > and as before the headers. Diffs are only made of the signed parts. When we were working on DKIM, we spent a lot of time looking at more complex canonicalizations that would exclude some parts of the message, and pretty much gave up. The issue isn't just picking what parts to include, but which excluded parts an attacker might add that would be rendered by MUAs. I still think it is very unlikely that small mail systems would ever implement something this complex. If the impediment to using double signing by forwarders is figuring out who the forwarders are, that could be handled by DNSWLs. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jul 1 11:58: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 A52F21B28A6 for ; Tue, 1 Jul 2014 11:58:06 -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 pUlU6Spc7N1K for ; Tue, 1 Jul 2014 11:58:05 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7474C1B28A3 for ; Tue, 1 Jul 2014 11:58:04 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so9966336wes.5 for ; Tue, 01 Jul 2014 11:58:03 -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=VJJr7f8SGJdkpGjnTcju8hImcp0fWyhnbJg2WSTQdYA=; b=Hye6c+JARxrBRknNYAYaCFoc3iBgYMTeyJQiW7F7sSm0cde8pY3yANDmTChmorSJsd KZJPxyqEj0TT3p6/C6ZPVi1qvlz1idT5N/cHwizjJYdisqEWmwt+ZsXbEif7V/mYLooh Ehl568Q42rTPmpz3bWBY0ryaoPCBPCKJfO55b5F906wqCY+Icq59Cw8nxRi2aOMZ3Gll UirctzlwwQX4koVsSFLOOf+T4qsQfzY3W6M5PqJX5GVLhPFKjZ+R38rv4P/wWhu4klbj ulPY0BeuSZXMIpfNQqdp1UH/tdPM4TUBaDNQpMYWC0Xp4ILAGyWYazweEeOuBRY95OOx Gr4w== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr54414303wja.37.1404241082934; Tue, 01 Jul 2014 11:58:02 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Tue, 1 Jul 2014 11:58:02 -0700 (PDT) In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> Date: Tue, 1 Jul 2014 11:58:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7b450a7ced6c5c04fd265a8c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Kl4cxFhBPTopXDGuMlXMyjUZIEc Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 01 Jul 2014 18:58:06 -0000 --047d7b450a7ced6c5c04fd265a8c Content-Type: text/plain; charset=UTF-8 I posted a draft that captures an idea originally proposed by Ned Freed: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ It's a canonicalization that hashes each piece of the MIME structure individually, as a tree. This allows for easy detection of modifications of an individual part, or of a subtree. It's also able to withstand encoding changes so long as the encoded content itself isn't changed. In an ideal world, Mediators like lists that want to add content would do so by adding a new text/plain part, and MUAs would render them properly. With this canonicalization, DKIM verifiers could identify any added content easily, determine whether it's safe, and then decide whether to consider the signature valid based on that. But I realize how much cooperation is needed to meet that ideal. -MSK On Tue, Jul 1, 2014 at 9:29 AM, John R Levine wrote: > Though at the risk of making this proposal more complicated, there is a way >> of dealing with this. The proposal could say to extend the DKIM to >> support >> the signing only certain stable MIME parts such as: Content-Type: >> text/plain that are unlikely to get stripped (or other base alternate >> part). This also signs the MIME multipart metadata to detect stripping, >> and as before the headers. Diffs are only made of the signed parts. >> > > When we were working on DKIM, we spent a lot of time looking at more > complex canonicalizations that would exclude some parts of the message, and > pretty much gave up. The issue isn't just picking what parts to include, > but which excluded parts an attacker might add that would be rendered by > MUAs. > > I still think it is very unlikely that small mail systems would ever > implement something this complex. If the impediment to using double > signing by forwarders is figuring out who the forwarders are, that could be > handled by DNSWLs. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b450a7ced6c5c04fd265a8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I posted a draft that captures an idea originall= y proposed by Ned Freed:

https://datatracker.ietf.org/doc/draft-k= ucherawy-dkim-list-canon/

It's a canonicalization that hashes each piece of the MIME st= ructure individually, as a tree.=C2=A0 This allows for easy detection of mo= difications of an individual part, or of a subtree.=C2=A0 It's also abl= e to withstand encoding changes so long as the encoded content itself isn&#= 39;t changed.

In an ideal world, Mediators like lists that want to add con= tent would do so by adding a new text/plain part, and MUAs would render the= m properly.=C2=A0 With this canonicalization, DKIM verifiers could identify= any added content easily, determine whether it's safe, and then decide= whether to consider the signature valid based on that.=C2=A0 But I realize= how much cooperation is needed to meet that ideal.

-MSK



On Tue, Jul 1, 2014 at 9:29 AM, John R Levine <johnl@taugh.= com> wrote:
Though at the risk of making this proposal more complicated, there is a way=
of dealing with this. =C2=A0The proposal could say to extend the DKIM to su= pport
the signing only certain stable MIME parts such as: Content-Type:
text/plain that are unlikely to get stripped (or other base alternate
part). =C2=A0This also signs the MIME multipart metadata to detect strippin= g,
and as before the headers. =C2=A0Diffs are only made of the signed parts.

When we were working on DKIM, we spent a lot of time looking at more comple= x canonicalizations that would exclude some parts of the message, and prett= y much gave up. =C2=A0The issue isn't just picking what parts to includ= e, but which excluded parts an attacker might add that would be rendered by= MUAs.

I still think it is very unlikely that small mail systems would ever implem= ent something this complex. =C2=A0If the impediment to using double signing= by forwarders is figuring out who the forwarders are, that could be handle= d by DNSWLs.


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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

--047d7b450a7ced6c5c04fd265a8c-- From nobody Tue Jul 1 15:53: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 BB1121A0040 for ; Tue, 1 Jul 2014 15:53:51 -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 yigby19MqYM7 for ; Tue, 1 Jul 2014 15:53:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 244531A0AD2 for ; Tue, 1 Jul 2014 15:53:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9O32ZD6IO006R7G@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 1 Jul 2014 15:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1404254920; bh=Pe3TdQnQWYSME1qsvUHG2fAC5st88Mlg5AB4FsDtSs8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ZHIvUR4uKF0apnAi6G5+u55DZFT5TSoUHhPyGRB/O/30WLOy9Ksx0E58m/cyGVaVp xt4krqtK4lNks+hFpfv67Ohk1DFRFHsDDSoMZJKXaM8E2tBYAhsAfOGsej3ORrnNnT 9TBEcCy9Imat2dPOv0xTyTb+177T8m7fggJbINLU= 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 <01P9IDD5BPLS0049PU@mauve.mrochek.com>; Tue, 01 Jul 2014 15:48:37 -0700 (PDT) Message-id: <01P9O32XP18I0049PU@mauve.mrochek.com> Date: Tue, 01 Jul 2014 15:46:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 Jul 2014 11:58:02 -0700" References: <20140629012552.81149.qmail@joyce.lan> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oiSnBNJyOdeNRav4gwvLqSz13qc Cc: John R Levine , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 01 Jul 2014 22:53:51 -0000 > I posted a draft that captures an idea originally proposed by Ned Freed: I think Merkle got there first on the whole tree thing, but whatever. > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > It's a canonicalization that hashes each piece of the MIME structure > individually, as a tree. This allows for easy detection of modifications > of an individual part, or of a subtree. It's also able to withstand > encoding changes so long as the encoded content itself isn't changed. Surviving encoding changes was the original motivation for doing this, albeit in the context of multipart/signed, not DKIM. Ned From nobody Wed Jul 2 09:44: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 9F1B51B27DF; Wed, 2 Jul 2014 05:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2jVJkoiR_aKH; Wed, 2 Jul 2014 05:10:54 -0700 (PDT) Received: from obermeyer.clearbearing.net (smtp.clearbearing.net [IPv6:2607:fc58:1004::9]) (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 C8CBC1B28F3; Wed, 2 Jul 2014 05:10:53 -0700 (PDT) Received: from mail.nuleaf.com (unknown [166.198.137.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by obermeyer.clearbearing.net (Postfix) with ESMTPSA id 8BD95F26D0; Wed, 2 Jul 2014 08:10:30 -0400 (EDT) Received: from [192.168.100.116] (IP116.NULEAF.COM [192.168.100.116]) by mail.nuleaf.com (Postfix) with ESMTP id 4D7EF41316; Wed, 2 Jul 2014 08:10:22 -0400 (EDT) From: Chuck Davin To: Pete Resnick In-Reply-To: <52D59155.8050404@qti.qualcomm.com> References: <1388586125.7196.58.camel@chuck> <52D59155.8050404@qti.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Organization: Rarely Date: Wed, 02 Jul 2014 08:10:07 -0400 Message-ID: <1404303007.10842.108.camel@chuck.nuleaf.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-ClearBearing-MailScanner-Information: Please contact ClearBearing (http://www.clearbearing.com) for more information on our anti-spam/anti-virus efforts. X-ClearBearing-MailScanner-ID: 8BD95F26D0.A5AD0 X-ClearBearing-MailScanner: Found to be clean X-ClearBearing-MailScanner-IP-Protocol: IPv4 X-ClearBearing-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-12.001, required 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_05 -5.00, TLS_AUTH_NOSPAM -5.00) X-ClearBearing-MailScanner-From: chuck@eesst.org X-ClearBearing-MailScanner-Watermark: 1404907849.07771@+njHbBONPmLHNgZ7cnoHiA Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HMtVT6I4Md5-mMU8ZsUdftgNDOw X-Mailman-Approved-At: Wed, 02 Jul 2014 09:44:18 -0700 Cc: Internet Engineering Steering Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group on Email Exchange of Secondary School Transcripts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chuck@eesst.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 12:10:56 -0000 Hello Pete, I recently received some robo-mail reminding me that the EESST internet draft (http://www.ietf.org/id/draft-davin-eesst-00.pdf) is about to expire. I would still like to pursue standardization of this draft (http://www.eesst.org) but clearly have been too distracted recently to make much headway. Over the past six months, I have been engaged in local lobbying and grass-roots efforts to prevent individual student information from being shared with third-parties. Recently, those efforts have met with some success, although a tangential free speech case is still pending in local court. As has been widely reported (e.g., http://www.politico.com/story/2014/06/internet-data-mining-children-107461.html?hp=l7), many state legislatures have taken up the issue of who owns and controls individual student information, and perhaps the tide is turning against authoritarian school officials and third-party corporate "custodians" of our children's data. At the time, I concluded that these real-world efforts to protect our children were more urgent than cranking up an IETF standardization effort (sorry). To the extent that more school officials may now be taking individual student privacy more seriously, they will need tools to help them do that. At the very least, school officials should be deprived of the excuse that centralized, third-party databases are the only available technology alternative, that individual control over individual personal information is not technically possible. That's why a timely standardization effort is needed. So, I'm reaching out to other like-minded internet engineers, who may also be concerned citizens and parents. In this community, the requisite technology is certainly familiar, and it may be that the independent spirit of the old days is also still alive. Will corporate powers or education bureaucrats rush to embrace this effort? Maybe not, but our children need an alternative, and the IETF can perhaps speak with greatest authority regarding secure email. This isn't especially hard work, but I believe it needs to be done. Who out there shares that belief? Who is willing to help? Best, Chuck (IETF-er from long ago) From nobody Wed Jul 2 11:03: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 AFC291B29E3 for ; Wed, 2 Jul 2014 11:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, 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 FPfSNxekurUK for ; Wed, 2 Jul 2014 11:03:41 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d: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 22ADC1B29E1 for ; Wed, 2 Jul 2014 11:03:41 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so9405997qac.35 for ; Wed, 02 Jul 2014 11:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oewdILb4DbrghHTy4kqEFE8HLN2FQXzWf3C2v7LlPts=; b=hwNAJY0DcObYLE22Xd6lWCgcsikYCB24BP9t7ald2Xl1AAEbCwHxySFlt5RXPaErEL gZhO0PaEQZJE7fAUd44Ix6aw0Mrd3yJupQn/KJpqk395zhMN4cmmYfMuJWsogobmuO+F jMb2t3LW2lC4RlUWcB44JZvuj3Ofab+5N0i7WowkT+QZZsxLaCbZzzTsCWzlxWdt6K6G bQoXn96U/zbYwuzPVzMK0G5ZFoykJVhWxiooEeeyjD3dn/b1o4D7ex6jYMp/e6GyIhm6 FsOYljnHVu5wtMkeLrtzzPhSb0Hmcw83IVLOCWsUZ7ByjjZRco+jPSHcvX2G3/gy70O6 Zy3Q== 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:from:date :message-id:subject:to:cc:content-type; bh=oewdILb4DbrghHTy4kqEFE8HLN2FQXzWf3C2v7LlPts=; b=J1EoVrd3BCtqJm13TbA0W7OnZ94OgGBka/Yie7nQHIyv8gq7uJZjxP3u6T1T8aG6lW bVfHni9VJAdcDuUDPv9J+jmBJos4kjlBgebwi46ubX+IgetcSNDVKt3pkKDkEvxaky9A r3VeTv4FS9weSeEDs8hmYJ470kHJcRj1VPvKqmKRttXhOe49lR3S5gtcwx1jyaXcZc74 FjLwj14KLVJ/VS04WNjFH/ZHiyOhhA2Cy95VzJpIh9Ps9bYt4s9w8vM3Jo6Q0hcY5Ozo PcjCwRi7ckBTo5Ty2n300W97iR7uh/d5If0cXpsHEnu48jF+qIrCBwZikjw6+2yr0hGe o+mg== X-Gm-Message-State: ALoCoQkICXWyLsIu3Z7czlLi58+LzsMzzEffAYFHmfjr0qqScNOKgHPU/QLt2lNqHZifcwQsCvEF X-Received: by 10.140.84.168 with SMTP id l37mr82199163qgd.104.1404324220245; Wed, 02 Jul 2014 11:03:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Wed, 2 Jul 2014 11:03:20 -0700 (PDT) In-Reply-To: <01P9O32XP18I0049PU@mauve.mrochek.com> References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> From: Wei Chuang Date: Wed, 2 Jul 2014 11:03:20 -0700 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a11c117084c9c3b04fd39b6d2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wHYCBvqXZxRq0S1Aflc0TkTVk18 Cc: John R Levine , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 18:03:42 -0000 --001a11c117084c9c3b04fd39b6d2 Content-Type: text/plain; charset=ISO-8859-1 Preliminaries: I think the main difference is that OP proposal tries to recover the earlier content, but if one doesn't need that as with the canonicalization approach it can be quite compact and less invasive for the implementor. That said: In section 5 of the canonicalization draft it refers to explicitly two DKIM signatures one for the original author and the other for the MLM. Could more than one MLM signers be allowed? Also perhaps DKIM signature headers should have a field to assist in describing its purpose such as original author signature vs resigner? -Wei On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed wrote: > > I posted a draft that captures an idea originally proposed by Ned Freed: > > I think Merkle got there first on the whole tree thing, but whatever. > > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > > > It's a canonicalization that hashes each piece of the MIME structure > > individually, as a tree. This allows for easy detection of modifications > > of an individual part, or of a subtree. It's also able to withstand > > encoding changes so long as the encoded content itself isn't changed. > > Surviving encoding changes was the original motivation for doing this, > albeit in the context of multipart/signed, not DKIM. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c117084c9c3b04fd39b6d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Preliminaries: I think the main difference is that OP= proposal tries to recover the earlier content, but if one doesn't need= that as with the canonicalization approach it can be quite compact and les= s invasive for the implementor.

That said: In section 5 of the canonicalization draft it ref= ers to explicitly two DKIM signatures one for the original author and the o= ther for the MLM. =A0Could more than one MLM signers be allowed? =A0Also pe= rhaps DKIM signature headers should have a field to assist in describing it= s purpose such as original author signature vs resigner?

-Wei

On Tu= e, Jul 1, 2014 at 3:46 PM, Ned Freed <ned.freed@mrochek.com> wrote:
> I posted a draft that c= aptures an idea originally proposed by Ned Freed:

I think Merkle got there first on the whole tree thing, but whatever.=

> https://datatracker.ietf.org/doc/draft-kucherawy-= dkim-list-canon/

> It's a canonicalization that hashes each piece of the MIME structu= re
> individually, as a tree. =A0This allows for easy detection of modifica= tions
> of an individual part, or of a subtree. =A0It's also able to withs= tand
> encoding changes so long as the encoded content itself isn't chang= ed.

Surviving encoding changes was the original motivation for doing this= ,
albeit in the context of multipart/signed, not DKIM.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned

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

--001a11c117084c9c3b04fd39b6d2-- From nobody Wed Jul 2 12:18: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 9FA331B288D for ; Wed, 2 Jul 2014 12:18:22 -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 0aj_wRRS5tc8 for ; Wed, 2 Jul 2014 12:18:21 -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 F05001A04C8 for ; Wed, 2 Jul 2014 12:18:20 -0700 (PDT) Received: (qmail 52264 invoked from network); 2 Jul 2014 19:18:19 -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; s=cc27.53b45afb.k1407; bh=W6d0Bv6tmtAVy5aD7CwHUvLI6nlCvY1zjkEQAevY9LQ=; b=My/jDw9a7cBVOPENEQyPjSKPnpofj+UUjDh3i1icGLlBG8ET6BvmpC5pFeN+PbiULoaTLZnCeH6397cAjHB8zkPg3t1tEWHL/BE+U8Z1hDFGkMUDKcm7iIg1jLZA+Y+bSllpJdC2IWRuG2HYyRO15xugIjvk0hCHjSJcM7IyirqyuzWmiAPYSz4f5uwLUEzAcW6EoTf+Xz/GbtVoLgHpad5wSiEioJLp4tSNuJ0qFSTXp790eaFY47FZ+jxdHecD 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; s=cc27.53b45afb.k1407; bh=W6d0Bv6tmtAVy5aD7CwHUvLI6nlCvY1zjkEQAevY9LQ=; b=poi/lsEhpIIp78/4VqniI9hF5LsftndHCKnXleL00XZZvzm10kPqH8VPYJFUQF84szdCBY+PwlRpYsBmgE717vag3KbPhXgLx3dz8pxW1YI8DsIgTMlc4PbY+sLEDaz2g9tB3K0bQogp43ZuLa0TCQFvg1GTK6niq/Qjx/US5EnZ/Zx+SahE10oN5ej9OVElsz0T6GmHNRj2t4rSjxyzkLFmazslApgxaqCIeQOctNTvLGxXPR8jCW6CzcecVOVb 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; 02 Jul 2014 19:18:19 -0000 Date: 2 Jul 2014 15:18:19 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F1zVKJvc1fRGR_ttMjmtgp9Skqc Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 19:18:23 -0000 > That said: In section 5 of the canonicalization draft it refers to > explicitly two DKIM signatures one for the original author and the other > for the MLM. Could more than one MLM signers be allowed? Also perhaps > DKIM signature headers should have a field to assist in describing its > purpose such as original author signature vs resigner? Any MTA that handles a message can add DKIM signatures on the way through. It is normal to add more than one signature; my lists add one for the list domain and one for lists.iecc.com, the domain of the MTA that handles all the list mail. A specific design decision in DKIM (albeit one that a lot of people seem to have trouble with) is that the signature d= need have no connection to anything else in the message. You can add all of the extra informative tags you want, although in practice informative tags don't seem to be very useful other than for debugging. The original plan was that the list would sign its outgoing mail, and recipients would recognize the list and its good reputation to deliver the mail. R's, John > On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed wrote: > >>> I posted a draft that captures an idea originally proposed by Ned Freed: >> >> I think Merkle got there first on the whole tree thing, but whatever. >> >>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >> >>> It's a canonicalization that hashes each piece of the MIME structure >>> individually, as a tree. This allows for easy detection of modifications >>> of an individual part, or of a subtree. It's also able to withstand >>> encoding changes so long as the encoded content itself isn't changed. >> >> Surviving encoding changes was the original motivation for doing this, >> albeit in the context of multipart/signed, not DKIM. From nobody Wed Jul 2 14:25: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 03CF01A032E for ; Wed, 2 Jul 2014 14:25:33 -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 32gUQi-HaIG6 for ; Wed, 2 Jul 2014 14:25:32 -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 A38521B285D for ; Wed, 2 Jul 2014 14:25:31 -0700 (PDT) Received: (qmail 74283 invoked from network); 2 Jul 2014 21:25:29 -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; s=1222a.53b478c9.k1407; bh=GcesnbnPGWngUOrmwXews9pDydTLOa5BZk8B7BVW0V8=; b=jiOMikSSZ9Qqj2SNlpeMtAUuiknPwBW5YZSDDqXuGnD3sgU3ABN/XuFXcpq5avN1PXBZe2LFGW3kkYpSj1Dajvo9xtUCo8aLQsyC5gI2lMFLjZ82glkLpuQKbsCi2vGyYfsiCWVuSBFvz6xyLMgLEQOwOCZMjnbxfNuwmv7o/2afKiNzJLaUaaJ6hpa53GFaydRYTd0k8pEksUQ5erEYJHEa57HhwKdydKnTeJH5t7gyqV5paWcirEGr2bFNS09o 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; s=1222a.53b478c9.k1407; bh=GcesnbnPGWngUOrmwXews9pDydTLOa5BZk8B7BVW0V8=; b=ee+/wQvFciuIpoO2ietWOBfqvCMEgBCq6CwzO8PuLJJO4HndfBTgj2iJA0aEXi7RQ/IGkA6RaqmV24dYpPm/a6CnkYw3lLUXTKyuiPnkgTaxtc7mV+23WakBwwQnPYdt2V6lzbBkNnaTCd2L4+nYyKEeW4YiGFP0wimSjF8qeHTcyn/TAZr8fYPiUNeTqSXKRvVmFIqQv4moN/aBV4c0Y0fOqytiUbMb1JdQAxeUGKt+/f4C2+9MepDg1jQgDt+r 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; 02 Jul 2014 21:25:29 -0000 Date: 2 Jul 2014 17:25:28 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01P9O32XP18I0049PU@mauve.mrochek.com> References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LurRya3LnauyyfLr9H7IRxwzhvg Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 21:25:33 -0000 >> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > >> It's a canonicalization that hashes each piece of the MIME structure >> individually, as a tree. This allows for easy detection of modifications >> of an individual part, or of a subtree. It's also able to withstand >> encoding changes so long as the encoded content itself isn't changed. > > Surviving encoding changes was the original motivation for doing this, > albeit in the context of multipart/signed, not DKIM. I believe that it lets you sign each MIME part separately, but that's only one step toward something that survives mailing lists. There's still the problem of looking at the incoming message and deciding whether it's still similar enough to the message that was signed. I'm fairly confident that for any rule you can invent that would allow the normal mailing list changes, I can construct egregious spam that it would permit. There's a huge variation in what lists do, and a lot of what they do, e.g., adding text to the front of the body, is not very different from what a malicious faux list would do. Basically, this plan needs a second layer of semantics to decide what's "the same". The double signing approach needs a second layer to say which forwarders are credible. I don't see any reason to think this second layer would be more tractable, and the underlying mechanisms are much more complicated. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jul 2 14:43: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 432181B29F0 for ; Wed, 2 Jul 2014 14:43:27 -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 Ahfp9su-Ws8J for ; Wed, 2 Jul 2014 14:43:24 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007D41B2AC4 for ; Wed, 2 Jul 2014 14:43:22 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so12610601pdi.4 for ; Wed, 02 Jul 2014 14:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lF0LggIH2Bj+BxxvF69Gq6XPlOzKpTEmlx3G7+YVK3g=; b=RK3a5I/+STgUmxURNVJNE9vOyK9jnNWIbFUjNddGQQvHyoC0EARVtjlDDcWIknnahs 8VaT2COxEKC8qdvfxwLtvPHitMLrDpdTafp3NNXMZO6COnYhkdsL8FBq8PAcSRntXo7O 8MR485iGwfg+y3aUuLk9tCXQXILtxlAakVdLK44hCsZogYlSYev2STDF8fW7kS1LrimD ts7VdEwvpUaCQKEua+Go0KK/gxwOJPr+Wuk4/k3hZlrfjLqFWK1j7WIQWY4QRHYpyCh4 yWShQdjb9T/vGnvu0dGebj3bEi9p4dk19SbdI8A5lM0nxBDsB7E0wNF9cxGPSpHhTj+V pBmw== X-Received: by 10.66.180.34 with SMTP id dl2mr529655pac.124.1404337402664; Wed, 02 Jul 2014 14:43:22 -0700 (PDT) Received: from [192.168.2.224] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id by1sm38457508pbb.75.2014.07.02.14.43.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 14:43:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 2 Jul 2014 14:43:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> To: John R Levine X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y6YQKO_wufoyNN-rVv9JukoqgcM Cc: Ned Freed , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 21:43:27 -0000 On Jul 2, 2014, at 2:25 PM, John R Levine wrote: >>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >>=20 >>> It's a canonicalization that hashes each piece of the MIME structure >>> individually, as a tree. This allows for easy detection of = modifications >>> of an individual part, or of a subtree. It's also able to withstand >>> encoding changes so long as the encoded content itself isn't = changed. >>=20 >> Surviving encoding changes was the original motivation for doing = this, >> albeit in the context of multipart/signed, not DKIM. >=20 > I believe that it lets you sign each MIME part separately, but that's = only one step toward something that survives mailing lists. There's = still the problem of looking at the incoming message and deciding = whether it's still similar enough to the message that was signed. >=20 > I'm fairly confident that for any rule you can invent that would allow = the normal mailing list changes, I can construct egregious spam that it = would permit. There's a huge variation in what lists do, and a lot of = what they do, e.g., adding text to the front of the body, is not very = different from what a malicious faux list would do. >=20 > Basically, this plan needs a second layer of semantics to decide = what's "the same". The double signing approach needs a second layer to = say which forwarders are credible. I don't see any reason to think this = second layer would be more tractable, and the underlying mechanisms are = much more complicated. Dear John, Agreed. A single DNS transaction is possible with TPA-Label. This scheme offers = a solution using smaller DNS resources than other proposed schemes even = while solving back-office service issues that make use of the Sender = header without modifying any DKIM operation. =20 Regards, Douglas Otis= From nobody Wed Jul 2 14:53: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 BB6D61B2ACC for ; Wed, 2 Jul 2014 14:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 im3DNQhUwDrf for ; Wed, 2 Jul 2014 14:53:39 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 503D51B2ACE for ; Wed, 2 Jul 2014 14:53:39 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3h3bmL1vg9z1L8f1; Wed, 2 Jul 2014 23:53:38 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3h3bmL0hm2z5Mh9k; Wed, 2 Jul 2014 23:53:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id D3ADE1231B2; Wed, 2 Jul 2014 23:53:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IcD1CfTNtZ1w; Wed, 2 Jul 2014 23:53:32 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 4BB3512318C; Wed, 2 Jul 2014 23:53:32 +0200 (CEST) Message-ID: <53B47F5C.2020400@sonnection.nl> Date: Wed, 02 Jul 2014 23:53:32 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine , Ned Freed References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1404338018; bh=PWdE3OgzlsUZ8tQkvzbbWvPM6NKK0Q9/7SQ5paXkb3E=; h=Message-ID:Date:From:To:Subject:From; b=lu1FY8Uncd0xIyJn8a44eEyJeJVTAkvIuBnrDwX6g2RrBiLO3Bj3OfGMQb+RDOjUJ 26jFzOY+Aw9pRgUYArWuLJlwNVC29z7B3FR3YAZHoKVYlXflN3timOO3G9GNeNrXGa fYlrs2Z/9NcQmjC6BRWtFR+N/jC+SCSCOt49GWlo= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3h3bmL1vg9z1L8f1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zQ-C45Cxro_D_Dn4Bnq29MOgpbA Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:53:45 -0000 On 07/02/2014 11:25 PM, John R Levine wrote: >>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >> >>> It's a canonicalization that hashes each piece of the MIME structure >>> individually, as a tree. This allows for easy detection of >>> modifications >>> of an individual part, or of a subtree. It's also able to withstand >>> encoding changes so long as the encoded content itself isn't changed. >> >> Surviving encoding changes was the original motivation for doing this, >> albeit in the context of multipart/signed, not DKIM. > > I believe that it lets you sign each MIME part separately, but that's > only one step toward something that survives mailing lists. There's > still the problem of looking at the incoming message and deciding > whether it's still similar enough to the message that was signed. > > I'm fairly confident that for any rule you can invent that would allow > the normal mailing list changes, I can construct egregious spam that > it would permit. There's a huge variation in what lists do, and a lot > of what they do, e.g., adding text to the front of the body, is not > very different from what a malicious faux list would do. > > Basically, this plan needs a second layer of semantics to decide > what's "the same". The double signing approach needs a second layer > to say which forwarders are credible. I don't see any reason to think > this second layer would be more tractable, and the underlying > mechanisms are much more complicated. In the past that second layer has been called 'reputation' and I'm pretty sure that most mailing lists, adding their own DKIM signature, will have no problem in surviving a reputation check. The problem here is the 'on/off' or 'black vs white' nature of DMARC's p=reject. Reputation is seldom black/white, most of the time it's somewhere in between. /rolf From nobody Wed Jul 2 15:05: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 C95EC1B2AE8 for ; Wed, 2 Jul 2014 15:05:28 -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_16=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 dbR9MFhPlmQI for ; Wed, 2 Jul 2014 15:05:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635551B2ADE for ; Wed, 2 Jul 2014 15:05:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so10366192wib.11 for ; Wed, 02 Jul 2014 15:05: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=NxB0Uv8a6k03UsPDr/s60JMeHpckhD6oaoAk+ONe7rE=; b=e2XJdG1aCLrbL0KUOY8md4KLue1UYAdOPXg/erL4KNSFNeL0/CfprXIegs5weDXCv9 VD3Bzl1DLWPP2D/QTpnA7ci7zF6CBQ2NAFeIma4hpmfWr5A0bG8QatDkYDyyKzYoiFmg 8BoRhWewFE4WttyMEUIJxKab84ryQdnq0XkAGNQN/AYemVqb2l1ITeFhLq6Xqjw7GQgf /kXKtcm6hsFvT/qowcq83raPoDIMBCvHlehNwg8s574Du8z5LrO4qLT7samiXeIS0cz8 J5VfiCf7iqFpr6Ht1NQGSgrlgp5c8/BDUsbev/hKaYYznMsqWTescKtRhGJZ3TbalZRn a9cQ== MIME-Version: 1.0 X-Received: by 10.180.10.168 with SMTP id j8mr46647660wib.73.1404338725956; Wed, 02 Jul 2014 15:05:25 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Wed, 2 Jul 2014 15:05:25 -0700 (PDT) In-Reply-To: <53B47F5C.2020400@sonnection.nl> References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> <53B47F5C.2020400@sonnection.nl> Date: Wed, 2 Jul 2014 15:05:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a11c25918e7b32804fd3d16ef Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kHE7Q5bzXoUdMRG_3JnLIMnLn7s Cc: Ned Freed , John R Levine , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 22:05:29 -0000 --001a11c25918e7b32804fd3d16ef Content-Type: text/plain; charset=UTF-8 On Wed, Jul 2, 2014 at 2:53 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > > In the past that second layer has been called 'reputation' and I'm pretty > sure that most mailing lists, adding their own DKIM signature, will have no > problem in surviving a reputation check. The problem here is the 'on/off' > or 'black vs white' nature of DMARC's p=reject. Reputation is seldom > black/white, most of the time it's somewhere in between. > I believe that's consistent with the notion that things like DKIM, SPF, and DMARC are often merely inputs to a larger evaluation engine, which also takes things like reputation into account. It's precisely why the DMARC spec calls out the ability for policy exceptions, at the discretion of the receiver. -MSK --001a11c25918e7b32804fd3d16ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 2, 2014 at 2:53 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
<= br>
In the past that second layer has been called 'reputation' and I= 9;m pretty sure that most mailing lists, adding their own DKIM signature, w= ill have no problem in surviving a reputation check. The problem here is th= e 'on/off' or 'black vs white' nature of DMARC's p=3Dre= ject. Reputation is seldom black/white, most of the time it's somewhere= in between.

I believe that's consist= ent with the notion that things like DKIM, SPF, and DMARC are often merely = inputs to a larger evaluation engine, which also takes things like reputati= on into account.=C2=A0 It's precisely why the DMARC spec calls out the = ability for policy exceptions, at the discretion of the receiver.

-MSK
--001a11c25918e7b32804fd3d16ef-- From nobody Wed Jul 2 15:47: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 1D6021A0944 for ; Wed, 2 Jul 2014 15:47:31 -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 rLW8ukSmAWBC for ; Wed, 2 Jul 2014 15:47:29 -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 8A3531A0463 for ; Wed, 2 Jul 2014 15:47:29 -0700 (PDT) Received: (qmail 84845 invoked from network); 2 Jul 2014 22:47:28 -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; s=14b6c.53b48c00.k1407; bh=bwCRPhLvVaBh7G1A60AV8o+GT5Jo/he7m7p/f9snOXc=; b=vRRE//rAgmrcXd/Aljtx7C2LmMKdzD20JrXxwvzz6QN/axMXKiTfmtYajwU0HaQBD05p6VRKMCmoiNzA5pzVtkFODkE9p+7amBTDX4ARoYNavfD6/OhRoIJf2JheOALe6oFUmh3LPRiTnntf0IANaT2T40HcyA/Q4hB3EabjgEfnQ6LNns365MiAtqxtfK1j2JtPDOcZ9dGpXXq7ldhcazWSjVG/nDgcePgTlx58AL/lWZcleYMoT1vSZ5FAuXTJ 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; s=14b6c.53b48c00.k1407; bh=bwCRPhLvVaBh7G1A60AV8o+GT5Jo/he7m7p/f9snOXc=; b=MKt3ARHppOitN31SfYiLqyquTenj+Z8JTn6c90mGt2PoScFJlB/WZbe85FGe0Lnago38SR4rV9jErag8s0cvFVU5EO7+VlCHJuOYQxAnfCad6o+q1Lpa/1tTqCYkMgU15mU9pBblk0ivdKn90tUxyBNvCgxIKD31ZqoTRMGIA6JpQQbIJ2FFbmCSTNJJD4rwtpAOwdfrKMirdRXwQea6x6lb1KwojwLsot1J5BQyKQ5/12tPUkBJM7nQweQZ1+mU 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; 02 Jul 2014 22:47:28 -0000 Date: 2 Jul 2014 18:47:27 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> <53B47F5C.2020400@sonnection.nl> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JKZ5wNw0b-r8WV8w5gACfaN-PW4 Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 22:47:31 -0000 >> In the past that second layer has been called 'reputation' and I'm pretty >> sure that most mailing lists, adding their own DKIM signature, will have no >> problem in surviving a reputation check. ... > I believe that's consistent with the notion that things like DKIM, SPF, and > DMARC are often merely inputs to a larger evaluation engine, which also > takes things like reputation into account. It's precisely why the DMARC > spec calls out the ability for policy exceptions, at the discretion of the > receiver. Originally I thought that list reputation would be stable enough that recipients should just deliver the fripping mail. Then someone at Gmail told me that they've seen spear phishing through forwarders. That's the threat that double signing or even O-A-R addresses. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jul 2 15:50: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 0204E1A0944 for ; Wed, 2 Jul 2014 15:50:42 -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 DNyMcPfZkclx for ; Wed, 2 Jul 2014 15:50:31 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60081A0463 for ; Wed, 2 Jul 2014 15:50:31 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id g10so12712285pdj.28 for ; Wed, 02 Jul 2014 15:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y5QM6/kdy0XFphJaBceLtB6RslyWoUPggRC0CYNKeVU=; b=w8zPqIav1SQhTb0OfK9+9Y1nWL7X5lWG4K0VNQ/HZJWpmPysOmqL8U0QtMmsmmtBEV 3Y7b8f7i09jZt6KXwKuZewrDeq/tA7XsADovy5cZ2KVtM92bcGORKaOcrMMwC07osRTL /UnGP0Hb0dkyNrOSNhxPjN3rcdZxR0vq6UGZpJiTGJkiN3EpuL/IjFwiOr+KhVgrJvqK qYb1CLYKOe+fDyY3mlR/pPDlma0mkvtB0NZOolfEEUgjGr0Sp6IVb7hZwjmh58Vz4liW yrlhIhf3rGJykZJK78GUBFAfPY8tvT1y9y7OC/S+dkp/0JS6VLGysz9hghzaxyMonA1F tJlA== X-Received: by 10.70.109.196 with SMTP id hu4mr2061474pdb.58.1404341431515; Wed, 02 Jul 2014 15:50:31 -0700 (PDT) Received: from [192.168.2.224] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id gx10sm36756210pbd.81.2014.07.02.15.50.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 15:50:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 2 Jul 2014 15:50:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EC77051-3F68-4298-B54D-E773D71C6977@gmail.com> References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> <53B47F5C.2020400@sonnection.nl> To: John R Levine X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/awIDR6IYp5uLoRuXPlMWtLNGI8o Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 02 Jul 2014 22:50:42 -0000 On Jul 2, 2014, at 3:47 PM, John R Levine wrote: >>> In the past that second layer has been called 'reputation' and I'm = pretty >>> sure that most mailing lists, adding their own DKIM signature, will = have no >>> problem in surviving a reputation check. ... >=20 >> I believe that's consistent with the notion that things like DKIM, = SPF, and >> DMARC are often merely inputs to a larger evaluation engine, which = also >> takes things like reputation into account. It's precisely why the = DMARC >> spec calls out the ability for policy exceptions, at the discretion = of the >> receiver. >=20 > Originally I thought that list reputation would be stable enough that = recipients should just deliver the fripping mail. Then someone at Gmail = told me that they've seen spear phishing through forwarders. That's the = threat that double signing or even O-A-R addresses. Dear John, Agreed. That is why the option to include O-A-R in TPA-Label was added = to permit a safer level of remediation when needed. Regards, Douglas Otis From nobody Thu Jul 3 07:26:59 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 A707C1B2AD1 for ; Thu, 3 Jul 2014 07:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, 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 rQQJ-u_aIUhG for ; Thu, 3 Jul 2014 07:26:56 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEF11B2AA9 for ; Thu, 3 Jul 2014 07:26:44 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so274921qcx.25 for ; Thu, 03 Jul 2014 07:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vUWVhQelBXgaexuWVtddoBFo71U+yVmcx//BD8TcdZc=; b=VxwTMe9WqxmmUOcZa7xohPWq+JTGVU/q3N0S+ShcJM7QIFZD52hVyBshjV5LSQjOqC Ejgqku9PvZZeHWS8XZDkSHlDvKcRuo10IFE/yLsodk4muHwl8oAW9OtIJjpoJOsj2n6T bQQLCOG+nmb/R4YDTHIlBCGAYxt8w01J1lM4KZTMguCc/ehID6/ifjUg+y0ocwT/pVg5 vdvjI64ywivbBHPbW/V9zYESU6yw5tIzWBV7jVDcfvenlFJzCnmXD9amtHk/NkSRQRyB lYUSatt+ZvBm577WGd6MgenfERRXHuZZtMAzNMXhNJDvT/5EZ3CzvWeofG+rr8fmMh9L oUHw== 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:from:date :message-id:subject:to:cc:content-type; bh=vUWVhQelBXgaexuWVtddoBFo71U+yVmcx//BD8TcdZc=; b=AIU57y9uavnPWpBO57xUuJ9dyOVSeEFMXqtYeQ18MYQNxk8PZn63J7l+9w21WlfReE zQeKYeomqRIWWghI3TyT1qpO0ILiaNDQx696foHAK96cqgNqPQt7oe61mUA83AF3SzdZ tuyRG5FPy0dXZ2mvHHGt54p3ODFERmMan74N/xPosSA6KkGanVegx3WHjw3d3raIWvXw WuEjHVcfYUlbN4gWHq3GoDL0BB/NTju3yzuyqcPQF8HE537lS/QNbRsMFn0NpCrUtrzl HJKxdV/AYDJE/pKJD0zLJOkKUYjliWJogALufjz+7fRam0CQgl0Qs/Kt3nGE8K6rUnF7 4zdw== X-Gm-Message-State: ALoCoQmBHKrzaj3PAcULOOstPVw1PT1rCQ7F57bP1VcCTcplb0sXRkX/LeIMk7h1aCP6ZBfbT72N X-Received: by 10.140.91.66 with SMTP id y60mr7495979qgd.58.1404397603302; Thu, 03 Jul 2014 07:26:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Thu, 3 Jul 2014 07:26:22 -0700 (PDT) In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> From: Wei Chuang Date: Thu, 3 Jul 2014 07:26:22 -0700 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a113a4f8044cf7904fd4acc78 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/u6-oNraXIT1sSzbIRzqNhWbwKuw Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 03 Jul 2014 14:26:58 -0000 --001a113a4f8044cf7904fd4acc78 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 2, 2014 at 12:18 PM, John R Levine wrote: > That said: In section 5 of the canonicalization draft it refers to >> explicitly two DKIM signatures one for the original author and the other >> for the MLM. Could more than one MLM signers be allowed? Also perhaps >> DKIM signature headers should have a field to assist in describing its >> purpose such as original author signature vs resigner? >> > > Any MTA that handles a message can add DKIM signatures on the way through. > It is normal to add more than one signature; my lists add one for the list > domain and one for lists.iecc.com, the domain of the MTA that handles all > the list mail. A specific design decision in DKIM (albeit one that a lot > of people seem to have trouble with) is that the signature d= need have no > connection to anything else in the message. I think this is a really nice feature of RFC6376 DKIM to have the SDID domain not tied to RFC5322.FROM, and one I intended to use in the remainder of my proposal. > You can add all of the extra informative tags you want, although in > practice informative tags don't seem to be very useful other than for > debugging. > Recipients can only act on them if the tag is standardized. In the context of my proposal but perhaps useful in others, is the notion to identify the original sender signature and find whether the mail is in the original form to determine the original senders intent. -Wei > > The original plan was that the list would sign its outgoing mail, and > recipients would recognize the list and its good reputation to deliver the > mail. > > R's, > John > > > On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed wrote: >> >> I posted a draft that captures an idea originally proposed by Ned Freed: >>>> >>> >>> I think Merkle got there first on the whole tree thing, but whatever. >>> >>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >>>> >>> >>> It's a canonicalization that hashes each piece of the MIME structure >>>> individually, as a tree. This allows for easy detection of >>>> modifications >>>> of an individual part, or of a subtree. It's also able to withstand >>>> encoding changes so long as the encoded content itself isn't changed. >>>> >>> >>> Surviving encoding changes was the original motivation for doing this, >>> albeit in the context of multipart/signed, not DKIM. >>> >> --001a113a4f8044cf7904fd4acc78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 2, 2014 at 12:18 PM, John R Levine &l= t;johnl@taugh.com&= gt; wrote:
That said: In section 5 of the canonicalization draft it refers to
explicitly two DKIM signatures one for the original author and the other for the MLM. =A0Could more than one MLM signers be allowed? =A0Also perhaps=
DKIM signature headers should have a field to assist in describing its
purpose such as original author signature vs resigner?

Any MTA that handles a message can add DKIM signatures on the way through. = It is normal to add more than one signature; my lists add one for the list = domain and one for list= s.iecc.com, the domain of the MTA that handles all the list mail. =A0A = specific design decision in DKIM (albeit one that a lot of people seem to h= ave trouble with) is that the signature d=3D need have no connection to any= thing else in the message.

I think this is a really nice feature of RFC6376 DKIM t= o have the SDID domain not tied to RFC5322.FROM, and one I intended to use = in the remainder of my proposal.
=A0
You can add all of the extra informative tags you want, although in practic= e informative tags don't seem to be very useful other than for debuggin= g.

Recipients can only act on them if t= he tag is standardized. =A0In the context of my proposal but perhaps useful= in others, is the notion to identify the original sender signature and fin= d whether the mail is in the original form to determine the original sender= s intent.

-Wei
=A0

The original plan was that the list would sign its outgoing mail, and recip= ients would recognize the list and its good reputation to deliver the mail.=

R's,
John


On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed <ned.freed@mrochek.com> wrote:

I posted a draft that captures an idea originally proposed by Ned Freed:

I think Merkle got there first on the whole tree thing, but whatever.

https://datatracker.ietf.org/doc/draft-kucheraw= y-dkim-list-canon/

It's a canonicalization that hashes each piece of the MIME structure individually, as a tree. =A0This allows for easy detection of modifications=
of an individual part, or of a subtree. =A0It's also able to withstand<= br> encoding changes so long as the encoded content itself isn't changed.

Surviving encoding changes was the original motivation for doing this,
albeit in the context of multipart/signed, not DKIM.

--001a113a4f8044cf7904fd4acc78-- From nobody Thu Jul 3 09:18: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 590E01B2999 for ; Thu, 3 Jul 2014 09:18:03 -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_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 EDOpLRGv48v5 for ; Thu, 3 Jul 2014 09:18:01 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D281B2966 for ; Thu, 3 Jul 2014 09:18:00 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y13so458053pdi.27 for ; Thu, 03 Jul 2014 09:18:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4ToY2MsIfmeICwgyZer7SWqToc0G2E3YhlekntpTpQM=; b=LUSmYog+eSm6QKJrgHXCmkYC9XxcOIeBXrLOCCs7X6aQ3Jv8Th8aDKR13shoN7Fy3j HGHxBu6Oer8l37/+OnnKfI9PHywFH8CQ+z4gx0ScmyWEHuUBLjISgAL5AlWl/Kk48rrp HAN1NbLDl/ymjCoSYLGwtuEjRKfzZVvMLuIXbDuZnLl0J6f48iqhyEiaGYgP10FPkp5E hizWYTJerbxywyG4YgNs3dyxGx52PsWCgj4NXhxi15ONXRLP1712mSu4UbgprOD9o1CP F2TL9OPOcRCyc8x31apdY+ijXQVD6kqp2TvLHzpvR+na6m/lXorR/tfDVsV2Rc+XjAZk Ls/w== X-Gm-Message-State: ALoCoQmmj3xNFQ4LSgOHT3WTUiv1+N7KE19YWVZl03Y3lbPF9/B+AcPj4fOdcgOXrvjAzjNq/6zZ X-Received: by 10.68.138.227 with SMTP id qt3mr5779055pbb.6.1404404280604; Thu, 03 Jul 2014 09:18:00 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:64a2:b5fd:2a80:82ce? ([2602:306:3406:4f00:64a2:b5fd:2a80:82ce]) by mx.google.com with ESMTPSA id nx12sm144515172pab.6.2014.07.03.09.17.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 09:17:58 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_03BD82F2-9351-482F-A031-4CE6982CBC3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 3 Jul 2014 11:17:59 -0500 Message-Id: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3CRaRTPNV53zPLFNNnVOcHVY1ZM Cc: mile@ietf.org, draft-ietf-mile-enum-reference-format.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-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: Thu, 03 Jul 2014 16:18:03 -0000 --Apple-Mail=_03BD82F2-9351-482F-A031-4CE6982CBC3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tim, Thank you for your review. Please see my comments inline. Regards, Adam On Jun 25, 2014, at 12:25 PM, Tim Bray wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please > = seehttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te > ). >=20 > 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. >=20 > Document:draft-ietf-mile-enum-reference-format-05 > Title: IODEF Enumeration Reference Format > Reviewer:Tim Bray > Review Date: June 25, 2014 >=20 > There are problems in this document which should be addressed before > publication. >=20 > 1. The description uses many technical terms without first either > defining them or giving a reference for their meaning: =93Reference > class=94, =93Enumeration values=94, "enumeration identifiers and their > references=94. This reviewer found the spec really hard to understand > due to the heavy use of specialized language with no definition of > terms. NOTE: It may be reasonable to decide that this specification > is only intended to be read by those who are already sufficiently > expert to understand the terms, in which case this wouldn=92t be a > problem. We could attempt to define enumeration, however, the overview language = in section 2 does provide examples of such enumerations (CVE, CCE, CPE). = Because this enumeration reference format is tied closely to IODEF, I=92m= not convinced we need to go down the road of defining what we mean when = those involved in security automation are probably very familiar with = CVE, CCE, CPE, and so on. I=92m especially not convinced given the = suggested abstract rewrite, which I like. >=20 > 2. Why introduce two child elements, rather than just add an > attribute? Here=92s the example: >=20 > > 1 > CXI-1234-XYZ > >=20 > An attribute would feel more idiomatic. Why not >=20 > CXI-1234-XYZ ? This is a reasonable suggestion. I=92m fine with either choice. Does = one method have value over the other from an implementation perspective = (I=92m asking all)? >=20 > Suggested improvements to the spec: >=20 > Abstract: This at least should be comprehensible to nonspecialists. > Here is a suggested rewrite: >=20 > The The Incident Object Description Exchange Format (IODEF) is an XML > construct which contains identifiers, using an element called > ReferenceName, that come from enumerations of fixed string values. At > the moment the content of ReferenceName is just a string field, which > is unsatisfactory because it is necessary to know both the value and > the enumeration from which it comes. This specification changes the > definition of ReferenceName by adding structure which identifies both > the value and the enumeration from which it comes. This is done > indirectly through an IANA registry. If there are no objections, I quite like this modification to the = abstract. >=20 > In the first paragraph of section 2, the word =93resulting=94 is = wrong. I > think the sentence is trying to say =93to require that the = ReferenceName > element identify both the enumeration from which the name comes and > the name itself, and to identify enumerations via an IANA registry, > which includes useful metadata such as a link to the enumeration=92s > specification.=94 Would it be enough to change from =93=85resulting reference formats=94 = to =93=85resulting values in the specified format.=94 ? The final = sentence would read: =93There are several ways to accomplish this goal, = but the most appropriate at this point is to require a specific format = for the ReferenceName string of the IODEF [IODEF] Reference class, and = use an IANA registry to manage the resulting values in the specified = format.=94 This change was recommended by our responsible AD. >=20 > FIGURE 1 identifies the structure of Reference *before* this draft. > Why not provide before-and-after pictures? Is an =93after=94 picture really necessary given the XML listings and = language descriptions? I=92m not convinced it would be. Additionally, = if an =93after=94 picture were created, it would probably turn out to be = a picture of ReferenceName rather than the overall picture, which may = then be viewed as disjointed from the =93before=94 picture anyway. >=20 > Section 2, para beginning =93Per IODEF=94, language is clumsy = =93specific > references, such as ... are referenced.=94 Perhaps something like > =93becomes problematic when the ReferenceName comes from a particular > enumeration such as CVE [CVE], CCE [CCE], or CPE [CPE] and it is not > obvious to an implementer how to determine which. One solution, > presented here, is to add structure to the ReferenceName to identify > both the value and the enumeration it comes from=93. I have no issues making this change. >=20 > Section 2.1, should the title become something like =93Revised > ReferenceName Format=94? I have no issues making this change. >=20 > Also, sort of roundabout. How about =93... and requires a child = elements > named "Index" and "ID"; the first contains an integer which identifies > an entry in an IANA registry (see Section 4), which specifies the > specification the actual enumeration value, provided as the content of > the =93ID=94 child element. Or, as suggested above, make Index an > attribute, then you don=92t need ID. I=92m not entirely sure I followed this one, but let=92s see if using an = attribute will fly and then address this one. >=20 > The name =93Index=94 is lousy. Yes, it=92s an integer index into an = IANA > registry, but element names should describe what the content means, > not its data format. This identifies is a enumeration or a namespace > or a specification. Maybe SpecIndex? or Enumeration? Agreed. SpecIndex or Enumeration would work for me, but I think = SpecIndex is better because it=92s a bit more generic than Enumeration. = Are there other suggestions here? >=20 > Also, in the IANA table, shouldn=92t the spec say something about what > kind of thing the Specification URI is supposed to identify? An I-D? > An RFC? An XSD? The Specification URI is a list of one or more URIs. Then, we=92d need = a descriptor for each potential URI associated with the Index. Is that = what you had in mind, or something else? >=20 > --=20 > - Tim Bray (If you=92d like to send me a private message, see > https://keybase.io/timbray) --Apple-Mail=_03BD82F2-9351-482F-A031-4CE6982CBC3F 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTtYI4AAoJELhc5c4zaVWH0EkH/AvnHbh1uMmYNntYnU0dIi6N OIzHKiR/De4k/oUrbHILIVPe2mPpowLLi4SGd3Nc+ZWujLSdzGLd7qo6iZTXoWOC PRdLlNl4S2VtmUjThx76I2YZMM6Cd5j1Jb7Lpxk+lp0FluXJk0hUpmjYlC0/EneX 35T+K3SM8Fod8fRuNaNXnOuB8gfmSlBmcGSIMRx8+v9g/KM+tMoBqPw0rVRTS2x9 LMz6GcJiv6qQN2NgFQ7GliVIZwPCH2Qn5D992FVQ28OZQDfOCcU/TMBry0AKm6SM kdtkgYQ9syjxrjmQk0RcZL1FDO5Lm0Jg9rpVAb+CzMdOBJ6OkMWy/rv42GPyFpg= =xL0N -----END PGP SIGNATURE----- --Apple-Mail=_03BD82F2-9351-482F-A031-4CE6982CBC3F-- From nobody Thu Jul 3 10:21: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 4F59C1A0515 for ; Thu, 3 Jul 2014 10:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 rMLBZw_Kw8QT for ; Thu, 3 Jul 2014 10:20:51 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48591B2B3A for ; Thu, 3 Jul 2014 10:20:43 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hy4so535020vcb.19 for ; Thu, 03 Jul 2014 10:20:43 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=v5OLm5ap9nFZk50itPso/mMDH0LKL3SxdBbP8Gr3YT8=; b=ItOtBOIu36iCCdGXspkAKmu5iJxGCdtDX2aTuMEP8HWd2XiRexpAR+xA6IRUy9Oyhi DKNisrUvvvBVjkAIhQzDn1mNIN+qLxp6TiU6VaKhbBNuxBYHV0cR28Zx+Huh2SJ2FLYd gkWb3OgwMiDdNbEbGu/XnXYVuRJdyXiZlwjIDJT1IVliK3iUj6CDIqH7qmH3WpeS5od/ ZOjlQj7IUPpBk2daRoeh7MeiKTr9seHz7UpN2X664bn3DdOCB0D/pg16Q8lDHitQ8Myc 2ewh9opiIugU3WYAxM6dxGCtkdQtCgZJ26wUK/g1JyDfKvEWGifXMaZVHVTZz/qOZu08 eCoA== X-Gm-Message-State: ALoCoQndJAKW4v2eErIstRiualpluGjOSWULOhpkZozNM0Vq2pM6DTzxdzk/eXxDLGpRchtif9Jx X-Received: by 10.221.42.135 with SMTP id ty7mr5107052vcb.14.1404408042867; Thu, 03 Jul 2014 10:20:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Thu, 3 Jul 2014 10:20:22 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> References: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> From: Tim Bray Date: Thu, 3 Jul 2014 10:20:22 -0700 Message-ID: To: "Adam W. Montville" Content-Type: multipart/alternative; boundary=001a1133997483e44804fd4d3afd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JWNsXmRQOEWkdBJ2aZJG4_cO-w0 Cc: mile@ietf.org, draft-ietf-mile-enum-reference-format.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-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: Thu, 03 Jul 2014 17:20:53 -0000 --001a1133997483e44804fd4d3afd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 3, 2014 at 9:17 AM, Adam W. Montville wrote: > > We could attempt to define enumeration, however, the overview language in > section 2 does provide examples of such enumerations (CVE, CCE, CPE). > Because this enumeration reference format is tied closely to IODEF, I=E2= =80=99m > not convinced we need to go down the road of defining what we mean when > those involved in security automation are probably very familiar with CVE= , > CCE, CPE, and so on. I=E2=80=99m especially not convinced given the sugg= ested > abstract rewrite, which I like. > =E2=80=8BSounds like you=E2=80=99re on your way to a solution.=E2=80=8B > > 2. Why introduce two child elements, rather than just add an > > attribute? Here=E2=80=99s the example: > > > > > > 1 > > CXI-1234-XYZ > > > > > > An attribute would feel more idiomatic. Why not > > > > CXI-1234-XYZ ? > > This is a reasonable suggestion. I=E2=80=99m fine with either choice. D= oes one > method have value over the other from an implementation perspective (I=E2= =80=99m > asking all)? > =E2=80=8BThe only real unambiguous advantage is that you have two markup co= nstructs instead of three. Also, I guess, a few less bytes. There=E2=80=99s an int= angible argument in that this is the sort of thing attributes are supposed to be for; here=E2=80=99s a data value and here=E2=80=99s some metadata about it,= e.g. its namespace.=E2=80=8B > FIGURE 1 identifies the structure of Reference *before* this draft. > > Why not provide before-and-after pictures? > > Is an =E2=80=9Cafter=E2=80=9D picture really necessary given the XML list= ings and language > descriptions? I=E2=80=99m not convinced it would be. Additionally, if a= n =E2=80=9Cafter=E2=80=9D > picture were created, it would probably turn out to be a picture of > ReferenceName rather than the overall picture, which may then be viewed a= s > disjointed from the =E2=80=9Cbefore=E2=80=9D picture anyway. > =E2=80=8BOr, maybe just take out the ASCII art. It=E2=80=99s not obvious it= adds much value. Or if you leave it in, attach a label to make it clear that it describes the *current* structure before the change described by the draft is made.=E2=80=8B > The name =E2=80=9CIndex=E2=80=9D is lousy. Yes, it=E2=80=99s an integer = index into an IANA > > registry, but element names should describe what the content means, > > not its data format. This identifies is a enumeration or a namespace > > or a specification. Maybe SpecIndex? or Enumeration? > > Agreed. SpecIndex or Enumeration would work for me, but I think SpecInde= x > is better because it=E2=80=99s a bit more generic than Enumeration. Are = there > other suggestions here? > > > Also, in the IANA table, shouldn=E2=80=99t the spec say something about= what > > kind of thing the Specification URI is supposed to identify? An I-D? > > An RFC? An XSD? > > The Specification URI is a list of one or more URIs. Then, we=E2=80=99d = need a > descriptor for each potential URI associated with the Index. Is that wha= t > you had in mind, or something else? > =E2=80=8BHm, no, I mean, are there any constraints on who=E2=80=99s allowed= to specify enumerations, what kinds of things should implementers be prepared to deal with? Can any storefront publish a one-page description of some values and expect implementers to find use in it? I have no ideas or opinions about the answers to this question, but I think it=E2=80=99s a real question. Wh= en I see a =E2=80=9CURL of the specification=E2=80=9D with no remarks about what kin= d of beast it might be or where it comes from, that makes me nervous (and it might make the IESG nervous too).=E2=80=8B --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1133997483e44804fd4d3afd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Thu, Jul 3, 2014 at 9:17 AM, Adam W. Montville <adam@stoicsecurity.co= m> wrote:

We could attempt to define enumeration, however, the overview languag= e in section 2 does provide examples of such enumerations (CVE, CCE, CPE). = =C2=A0Because this enumeration reference format is tied closely to IODEF, I= =E2=80=99m not convinced we need to go down the road of defining what we me= an when those involved in security automation are probably very familiar wi= th CVE, CCE, CPE, and so on. =C2=A0I=E2=80=99m especially not convinced giv= en the suggested abstract rewrite, which I like.

=E2=80=8BSounds like you=E2=80=99re on your way to a solution.= =E2=80=8B


> 2. Why introduce two child elements, rather than just add an
> attribute? =C2=A0Here=E2=80=99s the example:
>
> <ReferenceName>
> =C2=A0 <Index>1</Index>
> =C2=A0 <ID>CXI-1234-XYZ</ID>
> </ReferenceName>
>
> An attribute would feel more idiomatic. Why not
>
> <ReferenceName Index=3D"1">CXI-1234-XYZ</ReferenceN= ame> ?

This is a reasonable suggestion. =C2=A0I=E2=80=99m fine with either c= hoice. =C2=A0Does one method have value over the other from an implementati= on perspective (I=E2=80=99m asking all)?

=E2=80=8BThe only real unambiguous advantage is that you have two markup co= nstructs instead of three. =C2=A0Also, I guess, a few less bytes. =C2=A0The= re=E2=80=99s an intangible argument in that this is the sort of thing attri= butes are supposed to be for; here=E2=80=99s a data value and here=E2=80=99= s some metadata about it, e.g. its namespace.=E2=80=8B

> FIGURE 1 identifies the structure= of Reference *before* this draft.
> Why not provide before-and-after pictures?

Is an =E2=80=9Cafter=E2=80=9D picture really necessary given the XML = listings and language descriptions? =C2=A0I=E2=80=99m not convinced it woul= d be. =C2=A0Additionally, if an =E2=80=9Cafter=E2=80=9D picture were create= d, it would probably turn out to be a picture of ReferenceName rather than = the overall picture, which may then be viewed as disjointed from the =E2=80= =9Cbefore=E2=80=9D picture anyway.

=E2=80=8BOr, maybe just take out the ASCII art. It=E2=80=99s n= ot obvious it adds much value. =C2=A0Or if you leave it in, attach a label = to make it clear that it describes the *current* structure before the chang= e described by the draft is made.=E2=80=8B


> The name =E2=80=9CIndex=E2=80=9D is lousy. =C2=A0Yes, = it=E2=80=99s an integer index into an IANA
> registry, but element names should describe what the content means, > not its data format. This identifies is a enumeration or a namespace > or a specification. =C2=A0Maybe SpecIndex? or Enumeration?

Agreed. =C2=A0SpecIndex or Enumeration would work for me, but I think= SpecIndex is better because it=E2=80=99s a bit more generic than Enumerati= on. =C2=A0Are there other suggestions here?

> Also, in the IANA table, shouldn=E2=80=99t the spe= c say something about what
> kind of thing the Specification URI is supposed to identify? =C2=A0An = I-D?
> An RFC? An XSD?

The Specification URI is a list of one or more URIs. =C2=A0Then, we= =E2=80=99d need a descriptor for each potential URI associated with the Ind= ex. =C2=A0Is that what you had in mind, or something else?
=

=E2=80=8BHm, no= , I mean, are there any constraints on who=E2=80=99s allowed to specify enu= merations, what kinds of things should implementers be prepared to deal wit= h? =C2=A0Can any storefront publish a one-page description of some values a= nd expect implementers to find use in it? =C2=A0I have no ideas or opinions= about the answers to this question, but I think it=E2=80=99s a real questi= on. =C2=A0When I see a =E2=80=9CURL of the specification=E2=80=9D with no r= emarks about what kind of beast it might be or where it comes from, that ma= kes me nervous (and it might make the IESG nervous too).=E2=80=8B

--=C2=A0
- Tim Bray (If= you=E2=80=99d like to send me a private message, see https://keybase.io/timbray)
--001a1133997483e44804fd4d3afd-- From nobody Thu Jul 3 10:58: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 9EDC41A01EF; Thu, 3 Jul 2014 09:45:50 -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 2TZqNZ53iyUB; Thu, 3 Jul 2014 09:45:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3425C1A01E7; Thu, 3 Jul 2014 09:45:46 -0700 (PDT) Received: from DM2PR09MB0224.namprd09.prod.outlook.com (25.160.92.146) by DM2PR09MB0223.namprd09.prod.outlook.com (25.160.92.145) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 16:45:43 +0000 Received: from DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) by DM2PR09MB0224.namprd09.prod.outlook.com ([25.160.92.146]) with mapi id 15.00.0974.002; Thu, 3 Jul 2014 16:45:43 +0000 From: "Waltermire, David A." To: "Adam W. Montville" , Tim Bray Thread-Topic: Apps Area review of draft-ietf-mile-enum-reference-format-05 Thread-Index: AQHPkJqdazrBUZdEL0Kr0AFFbJsrVpuOk4CAgAAGZzA= Date: Thu, 3 Jul 2014 16:45:42 +0000 Message-ID: <49d0fdfe85ac407daf12659865c4ce58@DM2PR09MB0224.namprd09.prod.outlook.com> References: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> In-Reply-To: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.225.82] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(13464003)(377454003)(24454002)(77096002)(74662001)(106116001)(20776003)(2656002)(85852003)(107046002)(99286002)(85306003)(74502001)(15975445006)(74316001)(31966008)(76176999)(87936001)(86362001)(54356999)(106356001)(33646001)(92566001)(19580395003)(83072002)(95666004)(99396002)(83322001)(19580405001)(101416001)(46102001)(81542001)(81342001)(76482001)(21056001)(80022001)(76576001)(79102001)(105586002)(64706001)(77982001)(50986999)(66066001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR09MB0223; H:DM2PR09MB0224.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Lq2Rx7dduJJ72ET2CdImTH9fT2w X-Mailman-Approved-At: Thu, 03 Jul 2014 10:58:26 -0700 Cc: "mile@ietf.org" , "draft-ietf-mile-enum-reference-format.all@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-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: Thu, 03 Jul 2014 16:45:50 -0000 Adam, In my view, we should make this specification as approachable as possible t= o non-domain experts. I am not sure we can assume that all readers are fami= liar with CVE, CCE, and CPE. The comment about enumerations resonates with = me. This may get addressed by the abstract changes, which may make this moo= t, but it may make sense to use less specialized language. For example we c= ould use collection/set of identifiers (or "identification set") instead of= enumeration. Thoughts? Dave -----Original Message----- From: Adam W. Montville [mailto:adam@stoicsecurity.com]=20 Sent: Thursday, July 03, 2014 12:18 PM To: Tim Bray Cc: apps-discuss@ietf.org; draft-ietf-mile-enum-reference-format.all@tools.= ietf.org; mile@ietf.org; The IESG Subject: Re: Apps Area review of draft-ietf-mile-enum-reference-format-05 Hi Tim, Thank you for your review. Please see my comments inline. Regards, Adam On Jun 25, 2014, at 12:25 PM, Tim Bray wrote: > I have been selected as the Applications Area Directorate reviewer for=20 > this draft (for background on appsdir, please=20 > seehttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec > torate > ). >=20 > 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. >=20 > Document:draft-ietf-mile-enum-reference-format-05 > Title: IODEF Enumeration Reference Format Reviewer:Tim Bray Review=20 > Date: June 25, 2014 >=20 > There are problems in this document which should be addressed before=20 > publication. >=20 > 1. The description uses many technical terms without first either=20 > defining them or giving a reference for their meaning: "Reference=20 > class", "Enumeration values", "enumeration identifiers and their=20 > references". This reviewer found the spec really hard to understand=20 > due to the heavy use of specialized language with no definition of=20 > terms. NOTE: It may be reasonable to decide that this specification=20 > is only intended to be read by those who are already sufficiently=20 > expert to understand the terms, in which case this wouldn't be a=20 > problem. We could attempt to define enumeration, however, the overview language in s= ection 2 does provide examples of such enumerations (CVE, CCE, CPE). Becau= se this enumeration reference format is tied closely to IODEF, I'm not conv= inced we need to go down the road of defining what we mean when those invol= ved in security automation are probably very familiar with CVE, CCE, CPE, a= nd so on. I'm especially not convinced given the suggested abstract rewrit= e, which I like. >=20 > 2. Why introduce two child elements, rather than just add an=20 > attribute? Here's the example: >=20 > > 1 > CXI-1234-XYZ > >=20 > An attribute would feel more idiomatic. Why not >=20 > CXI-1234-XYZ ? This is a reasonable suggestion. I'm fine with either choice. Does one me= thod have value over the other from an implementation perspective (I'm aski= ng all)? >=20 > Suggested improvements to the spec: >=20 > Abstract: This at least should be comprehensible to nonspecialists. > Here is a suggested rewrite: >=20 > The The Incident Object Description Exchange Format (IODEF) is an XML=20 > construct which contains identifiers, using an element called=20 > ReferenceName, that come from enumerations of fixed string values. At=20 > the moment the content of ReferenceName is just a string field, which=20 > is unsatisfactory because it is necessary to know both the value and=20 > the enumeration from which it comes. This specification changes the=20 > definition of ReferenceName by adding structure which identifies both=20 > the value and the enumeration from which it comes. This is done=20 > indirectly through an IANA registry. If there are no objections, I quite like this modification to the abstract. >=20 > In the first paragraph of section 2, the word "resulting" is wrong. I=20 > think the sentence is trying to say "to require that the ReferenceName=20 > element identify both the enumeration from which the name comes and=20 > the name itself, and to identify enumerations via an IANA registry,=20 > which includes useful metadata such as a link to the enumeration's=20 > specification." Would it be enough to change from "...resulting reference formats" to "...r= esulting values in the specified format." ? The final sentence would read:= "There are several ways to accomplish this goal, but the most appropriate = at this point is to require a specific format for the ReferenceName string = of the IODEF [IODEF] Reference class, and use an IANA registry to manage th= e resulting values in the specified format." This change was recommended b= y our responsible AD. >=20 > FIGURE 1 identifies the structure of Reference *before* this draft. > Why not provide before-and-after pictures? Is an "after" picture really necessary given the XML listings and language = descriptions? I'm not convinced it would be. Additionally, if an "after" = picture were created, it would probably turn out to be a picture of Referen= ceName rather than the overall picture, which may then be viewed as disjoin= ted from the "before" picture anyway. >=20 > Section 2, para beginning "Per IODEF", language is clumsy "specific=20 > references, such as ... are referenced." Perhaps something like=20 > "becomes problematic when the ReferenceName comes from a particular=20 > enumeration such as CVE [CVE], CCE [CCE], or CPE [CPE] and it is not=20 > obvious to an implementer how to determine which. One solution,=20 > presented here, is to add structure to the ReferenceName to identify=20 > both the value and the enumeration it comes from". I have no issues making this change. >=20 > Section 2.1, should the title become something like "Revised=20 > ReferenceName Format"? I have no issues making this change. >=20 > Also, sort of roundabout. How about "... and requires a child elements=20 > named "Index" and "ID"; the first contains an integer which identifies=20 > an entry in an IANA registry (see Section 4), which specifies the=20 > specification the actual enumeration value, provided as the content of=20 > the "ID" child element. Or, as suggested above, make Index an=20 > attribute, then you don't need ID. I'm not entirely sure I followed this one, but let's see if using an attrib= ute will fly and then address this one. >=20 > The name "Index" is lousy. Yes, it's an integer index into an IANA=20 > registry, but element names should describe what the content means,=20 > not its data format. This identifies is a enumeration or a namespace=20 > or a specification. Maybe SpecIndex? or Enumeration? Agreed. SpecIndex or Enumeration would work for me, but I think SpecIndex = is better because it's a bit more generic than Enumeration. Are there othe= r suggestions here? >=20 > Also, in the IANA table, shouldn't the spec say something about what=20 > kind of thing the Specification URI is supposed to identify? An I-D? > An RFC? An XSD? The Specification URI is a list of one or more URIs. Then, we'd need a des= criptor for each potential URI associated with the Index. Is that what you= had in mind, or something else? >=20 > -- > - Tim Bray (If you'd like to send me a private message, see > https://keybase.io/timbray) From nobody Thu Jul 3 10: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 D43531B2855; Wed, 2 Jul 2014 10:43:01 -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 x7FuM53F3_sK; Wed, 2 Jul 2014 10:43:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23C1A03B4; Wed, 2 Jul 2014 10:43:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: mnot@mnot.net X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702174300.26172.33832.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 10:43:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/604XZtk-J-FIZpT0nriljdOiPbU X-Mailman-Approved-At: Thu, 03 Jul 2014 10:58:36 -0700 Cc: apps-discuss@ietf.org, Pete Resnick , Mark Nottingham , Barry Leiba Subject: [apps-discuss] New Liaison Statement, "Proposed URI Scheme Registration Process Changes" 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, 02 Jul 2014 17:43:02 -0000 Title: Proposed URI Scheme Registration Process Changes Submission Date: 2014-07-02 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1340/ From: Applications Area Working Group (Murray Kucherawy ) To: W3C (mnot@mnot.net) Cc: Mark Nottingham ,Murray Kucherawy ,Salvatore Loreto ,Pete Resnick ,Barry Leiba , apps-discuss@ietf.org Response Contact: superuser@gmail.com Technical Contact: dthaler@microsoft.com Purpose: For information Body: W3C, The IETF is considering some changes to the URI scheme registration process to address problems documented in http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-00. In addition, the IETF APPSAWG discussed whether to allow for registering scheme name prefixes (to reserve them for a specific purpose or organization), and has tentatively decided to not make any changes in this regard. The changes being considered notably include the following: 1) Lowering the bar for Provisional (but not Permanent) allocation to be First-Come-First-Served without requiring Expert Review, since today this seems to be a disincentive for many to register and seems to result in using Wikipedia (http://en.wikipedia.org/wiki/URI_scheme) or http://www.w3.org/wiki/UriSchemes to claim or look up scheme names instead of the IANA registry. 2) Reserving the use of dots in new scheme names to indicate that they are constructed from a domain name suffix (as already allowed in RFC 4395). This avoids conflicts such as could occur today were ".iris" or ".soap" allocated as gTLDs for instance. Please let us know if there are concerns with these changes that the IETF needs to take into account. M. Kucherawy Co-chair, Applications Area Working Group Attachments: No document has been attached From nobody Thu Jul 3 12:03: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 135D21B2B3D; Thu, 3 Jul 2014 12:03: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 WA0X9EempL-F; Thu, 3 Jul 2014 12:03:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6161B1B2983; Thu, 3 Jul 2014 12:03:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140703190347.24899.45193.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 12:03:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qBBJ_37yITt-J5FsOzgDsVOvAzw Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:03:49 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'A NULL MX Resource Record for Domains that Accept No Mail' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 3 12:03: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 5AD731B2B63 for ; Thu, 3 Jul 2014 12:03: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 drTJdASHMPEO; Thu, 3 Jul 2014 12:03:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 531D41B2983; Thu, 3 Jul 2014 12:03:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703190349.24899.61790.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 12:03:49 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FeqXGtQPTuVJspU8772XJ9JqPNI Subject: [apps-discuss] ID Tracker State Update Notice: 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: Thu, 03 Jul 2014 19:03:52 -0000 Last call has been made for draft-ietf-appsawg-nullmx and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Thu Jul 3 14:53: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 E38ED1B2A3A; Thu, 3 Jul 2014 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 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] 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 on99np0K07s7; Thu, 3 Jul 2014 14:53:45 -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 9624D1B29C8; Thu, 3 Jul 2014 14:53:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.150.156]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s63LrUaU020917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 14:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404424423; x=1404510823; bh=f8FrmTRa8Hdsmvwwfzq/HH2v+oY+ff0pgx4XPjvoZYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hhJabpynX30vFJrePN0NDVvY/mGOPpVeJuPS4dPJqIbLhXX6WBZ1VgWw8KzCBevZC tN8/j8nY2i5vPrQAgA2ArTzraey3r7S59O2qNBwiG6ugmd+zVue3Wg3ZfwIZSJoqr/ 5SdH4Y6e6GDZCQzkuhmPDMmxuvaNC9yMOAh2U0rg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404424423; x=1404510823; i=@elandsys.com; bh=f8FrmTRa8Hdsmvwwfzq/HH2v+oY+ff0pgx4XPjvoZYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xKKHCzGpuRJ68zQT//0TTUVHozNh9l9FH//S5Gz3WY+/4eiB8jvffH6Np1laF+oWk E//rZ0eyInSbDmxnIDpKENgaQ/4xCmiLw8TCZzPbVd6Qx63H+I5D4x+DjFncuIyJfg tJ/0jHIWKUEwCr2+Er4G+SjD6LPfIlsOVleH180I= Message-Id: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 Jul 2014 14:32:07 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7MVvMj2s7bomy_S1r3WnXcx3MlU Cc: iesg@ietf.org Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 03 Jul 2014 21:53:48 -0000 At 08:06 20-06-2014, Barry Leiba wrote: >Cyrus Daboo has proposed a new working group in the Applications Area, >and I'm initiating charter discussion on it: > >https://datatracker.ietf.org/doc/charter-ietf-tzdist/ > >We'll have the charter discussion here on apps-discuss. Assuming a >working group comes out of this, we'll create a new mailing list for >the actual work, once the charter is done. I took a quick look at the proposed charter. "The following are Out of scope for the working group: - Any changes to the IANA timezone database process or infrastructure, as documented in RFC 6557, other than recommendations for possible security enhancements." A few months ago there was a hearing in the United States. A member of the legislature asked the ICANN President a question (I do not recall the exact words): What is the ccTLD for Crimea? http://www.bbc.com/news/world-europe-28144334 The TZ database itself is not an IETF Contribution. Any enhancements is up to the TZ Coordinator. I suggest that the IETF does not make any recommendations about the TZ database. I think that it is better for the IETF to stay away from that process. According to BCP 175: 'TZ Database: The Time Zone Database, sometimes referred to as the "Olson Database". This database consists of information about offsets from UTC for different localities, including daylight saving time (DST) transition information.' There isn't any mention of a "IANA timezone database" in that BCP. Would the IESG like to include the TZ Database in discussions about the IANA Transition? 'The working group can consider adding a mechanism, such as a "namespace" prefix, to differentiate different timezone sources, but the nature of the timezone identifiers used will be controlled by the sources themselves.' Formalizing time zone sources may lead down a path where the question of the authoritative source is raised. "namespace" could create the conditions for contentious strings [1]. Regards, S. Moonesamy 1. I haven't given much thought to all this. From nobody Thu Jul 3 15:59: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 A3C1E1B29C2; Thu, 3 Jul 2014 15:59:41 -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 djkSKAAEv0-r; Thu, 3 Jul 2014 15:59:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6D1B2A90; Thu, 3 Jul 2014 15:59:39 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703225939.1804.71226.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 15:59:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mMc8pjAMWD2j1JOcU0BxrQFpdtU Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-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: Thu, 03 Jul 2014 22:59:42 -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 : Guidelines and Registration Procedures for New URI Schemes Authors : Dave Thaler Tony Hansen Ted Hardie Larry Masinter Filename : draft-ietf-appsawg-uri-scheme-reg-01.txt Pages : 19 Date : 2014-07-03 Abstract: This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-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 Thu Jul 3 16:49: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 5D26F1B2B5B for ; Thu, 3 Jul 2014 16:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.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, 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 3FkZvDDnp6R0 for ; Thu, 3 Jul 2014 16:49:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A9F1B2A75 for ; Thu, 3 Jul 2014 16:49:38 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 3 Jul 2014 23:49:36 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0980.000; Thu, 3 Jul 2014 23:49:36 +0000 From: Dave Thaler To: Apps Discuss Thread-Topic: Status of URI scheme prefix issue Thread-Index: Ac+XGKFchZ482wW2Tk+/oIeaAHBf7QAALpFg Date: Thu, 3 Jul 2014 23:49:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(86612001)(74502001)(81342001)(87936001)(46102001)(15202345003)(31966008)(21056001)(86362001)(74662001)(79102001)(76482001)(105586002)(80022001)(85306003)(99286002)(107046002)(19580395003)(95666004)(85852003)(81542001)(77982001)(50986999)(15975445006)(99396002)(54356999)(83322001)(92566001)(74316001)(64706001)(20776003)(33646001)(229853001)(76576001)(101416001)(2656002)(106356001)(83072002)(107886001)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zofpuchvBqm748A26D3PCnjK-ak Subject: [apps-discuss] Status of URI scheme prefix issue 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, 03 Jul 2014 23:49:41 -0000 UmVnYXJkaW5nICJzdXBwb3J0IGZvciBzY2hlbWUgcHJlZml4IHJlZ2lzdHJhdGlvbi9kZWxlZ2F0 aW9uIiAodGlja2V0ICMxNiksIGxhc3QgSUVURiB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGlu IHJvb20gZm9yIE5PVCBhbGxvd2luZyByZWdpc3RlcmluZyBhIHByZWZpeCwgYW5kIHRoYXQgd2Ug d291bGQgY29tbXVuaWNhdGUgdGhpcyB0byB0aGUgVzNDIGFuZCBkaXNjdXNzIHdpdGggdGhlbSwg YW5kIHRoZW4gY29tZSBiYWNrIHRvIHRoZSBXRy4NCg0KV2UganVzdCBzZW50IGEgbGlhaXNvbiBz dGF0ZW1lbnQgdG8gdGhlIFczQyBvbiB0aGlzIChhbmQgb3RoZXIgaXNzdWVzIHdlIHNhaWQgd2Ug d291bGQgd2VsY29tZSBXM0MgaW5wdXQgb24pLCBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzEyMjg5Lmh0bWwuDQoNClNlcGFy YXRlbHksIEkgYWxzbyBtYW5hZ2VkIHRvIGdldCBhaG9sZCBvZiBzb21lIGludGVyZXN0aW5nIGRh dGEgb24gY3VycmVudCB1c2UuDQoNClRvdGFsICMgb2Ygc2NoZW1lcyBjdXJyZW50bHkgcmVnaXN0 ZXJlZCB3aXRoIElBTkE6IDE4OCAob2Ygd2hpY2ggNzQgd2VyZSBkb25lIGJ5IEFsZXhleSBhbmQg bWUgZHVyaW5nIHRoZSB0aGlyZC1wYXJ0eSByZWdpc3RyYXRpb24gZXhwZXJpbWVudCkNCg0KVG90 YWwgIyBvZiBhbGwgcmVnaXN0ZXJlZCBzY2hlbWVzIG91dHNpZGUgb2Ygb3VyIGV4cGVyaW1lbnQ6 IDExNA0KDQpYYm94IExpdmUgaGFzIGFwcGFyZW50bHkgYWx3YXlzIHVzZWQgYSBwcmVmaXggdG8g Z2VuZXJhdGUgYSBVUkkgc2NoZW1lIGZvciBldmVyeSBnYW1lIHRpdGxlLCB3aGljaCBpcyB1c2Vk IHRvIGxhdW5jaCB0aGUgZ2FtZS4gVGhhdCBpcyAibXMteGJsLTxndWlkPiIgd2hlcmUgPGd1aWQ+ IGlzIHJlcGxhY2VkIHdpdGggYSBHVUlELg0KQXBwcm94aW1hdGUgIyBvZiBYYm94IExpdmUgc2No ZW1lIG5hbWVzIHVzZWQ6IDY4NzMNCg0KSSBzdHJvbmdseSBzdXNwZWN0IHRoYXQgWGJveCBMaXZl IGlzbid0IHRoZSBvbmx5IHN1Y2ggZGVwbG95ZWQgZXhhbXBsZS4gIEFzIHByZXZpb3VzbHkgZGlz Y3Vzc2VkLCB1c2luZyBVUkkgc2NoZW1lcyB0byBsYXVuY2ggYXNzb2NpYXRlZCBhcHBzIGlzIGFs cmVhZHkgYSBkZSBmYWN0byBzdGFuZGFyZCBvbiBtb3N0IHBsYXRmb3JtcyAoQW5kcm9pZCwgaU9T LCBXaW5kb3dzLCBldGMuKSB3aGV0aGVyIHdlIGxpa2UgaXQgb3Igbm90LiAgVGhpcyBuZXcgZGF0 YSBwb2ludCBpbXBsaWVzIHRoYXQgd2lkZWx5IGRlcGxveWVkIHVzZSBvZiBwcmVmaXhlcyBwcm9i YWJseSBkd2FyZiB0aGUgbnVtYmVyIG9mIGFsbCByZWdpc3RlcmVkIHNjaGVtZXMgYnkgdHdvIG9y ZGVycyBvZiBtYWduaXR1ZGUuDQoNCkluIGxpZ2h0IG9mIHRoaXMgZGF0YSwgdGhlIHZpZXcgb2Yg Im5vIHByZWZpeGVzIiBzdGFydHMgc291bmRpbmcgc3VzcGljaW91c2x5IGxpa2UgdGhlICJubyBO QVRzIg0KcG9zaXRpb24gb2YgZGVuaWFsIHRoYXQgdGhlIElFVEYgd2FzIG9uY2UgaW4gYmVmb3Jl IEJlaGF2ZSB3YXMgY2hhcnRlcmVkLg0KSXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHdlIHNob3Vs ZCB0aGluayBhYm91dCBob3cgd2UgRE8gd2FudCB0byBkZWFsIHdpdGggcHJlZml4ZXMsIGlmIG5v dCBieSByZWdpc3RlcmluZyB0aGUgcHJlZml4IGl0c2VsZi4NCg0KLURhdmUNCg0K From nobody Thu Jul 3 17:44: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 66CD41B2B8E for ; Thu, 3 Jul 2014 17:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, 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 2VRU2A6uvJ5q for ; Thu, 3 Jul 2014 17:44:40 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FE51B2B89 for ; Thu, 3 Jul 2014 17:44:40 -0700 (PDT) Received: from 180.sub-70-208-130.myvzw.com ([70.208.130.180]:6331 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2rcC-0000j4-9T for apps-discuss@ietf.org; Thu, 03 Jul 2014 17:44:37 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_1D5DDC01-34B2-4FBF-BF04-0EFC03FB3B52"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 3 Jul 2014 20:44:35 -0400 References: To: Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fq0tzkqLq6nhSmERozy22iTQ2sM Subject: Re: [apps-discuss] Status of URI scheme prefix issue 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, 04 Jul 2014 00:44:42 -0000 --Apple-Mail=_1D5DDC01-34B2-4FBF-BF04-0EFC03FB3B52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Is there a way of not breaking everything all at once? What is the = difference between a prefixed =91scheme=92 and a scheme with a = parameter? I.e., instead of ms-xbl-:mumble, one has = ms-xbl:mumble;guid=3D? Or, ms-xbl:///mumble? Or, = ms-xbl://foo//mumble? The particular way is registered by MS in = this case. There may be two orders of magnitude of prefixed =91schemes=92 than = registered schemes, but I would bet there are seven or nine orders of = magnitude more usage of the registered schemes than the prefixed = schemes. And, since these are really only happening in the past few = months with the advent of "deep application links,=94 I would offer it = is not too late to do the right thing. The thing we call a prefixed =91scheme=92 is not a scheme at all. There = is no interoperability, there is no directives for how to interpret the = scheme, it breaks standards-based tools, it is less than ideal. On Jul 3, 2014, at 7:49 PM, Dave Thaler wrote: > Regarding "support for scheme prefix registration/delegation" (ticket = #16), last IETF there was rough consensus in room for NOT allowing = registering a prefix, and that we would communicate this to the W3C and = discuss with them, and then come back to the WG. >=20 > We just sent a liaison statement to the W3C on this (and other issues = we said we would welcome W3C input on), see = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12289.html. >=20 > Separately, I also managed to get ahold of some interesting data on = current use. >=20 > Total # of schemes currently registered with IANA: 188 (of which 74 = were done by Alexey and me during the third-party registration = experiment) >=20 > Total # of all registered schemes outside of our experiment: 114 >=20 > Xbox Live has apparently always used a prefix to generate a URI scheme = for every game title, which is used to launch the game. That is = "ms-xbl-" where is replaced with a GUID. > Approximate # of Xbox Live scheme names used: 6873 >=20 > I strongly suspect that Xbox Live isn't the only such deployed = example. As previously discussed, using URI schemes to launch = associated apps is already a de facto standard on most platforms = (Android, iOS, Windows, etc.) whether we like it or not. This new data = point implies that widely deployed use of prefixes probably dwarf the = number of all registered schemes by two orders of magnitude. >=20 > In light of this data, the view of "no prefixes" starts sounding = suspiciously like the "no NATs" > position of denial that the IETF was once in before Behave was = chartered. > It would seem to me that we should think about how we DO want to deal = with prefixes, if not by registering the prefix itself. >=20 > -Dave >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_1D5DDC01-34B2-4FBF-BF04-0EFC03FB3B52 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----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTtfjzAAoJEDY/T2tCIPW359QP/RrYSeD5FKyBYvoA2Saqfere DLELDnral8qj9HqaoF4O+aOSsvovVC29w8zz1fFtQtaB8Co0wNK6nSICNOoNJwK3 rMaGgp0ND0M9njfNeVSNeYNA7ddICNkHorE9+4Km1queDCmASQql7STSG9HJntYR 5LjrOIkj+TOVbg9c8ApN+hos/bm2Dh3g7JyNpAU3gARu1eseFGyVWo/ZomutnuAF AOEsSnR6rORoNn3jgIYTORYEg29iGPoWmfx6yDdCIwiLy2zxe4Ios3qFl0oO9pxd es6JaImMk2l/4JHZbFeOYj4rbwI9Vxv+kqjTbkcus7VcNhl6xHu/g87ftpH0x6pI UaR51YQbZoHrRJj77cgDANV9TRooJbgYu92eQ1Kr4hFOI8TGZl/y0GdQwJb1zg2q DhenYN3nlAm0b8K2lfpwCPcaLwmSlgR72ha1to01RbZAHqWkoy7ol4NaE+E71Rrn IG+CoMQF1BmcJpq2MtPeAN2r6hBFQJsDAqtvI6kNdOZ5zuQDJumAcGbWD+h3wWSF 22siSCSjd5XitVT4jis3pajy9CLBKa0rQIooIdIDzJIdTAos46MZCjQNjQS53CVU F8GpEXWVM/3bqeKxNTMDATkQclt13QQJUrGjon6PoW5N1Wj40BPO6YLTKjpaso7Z venTfuSdXyWVxool17xv =IwTd -----END PGP SIGNATURE----- --Apple-Mail=_1D5DDC01-34B2-4FBF-BF04-0EFC03FB3B52-- From nobody Thu Jul 3 17:58: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 2BC401B2BA8 for ; Thu, 3 Jul 2014 17:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 o_xkgM_tw_Bl for ; Thu, 3 Jul 2014 17:58:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480891B2B9B for ; Thu, 3 Jul 2014 17:58:12 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.974.11; Fri, 4 Jul 2014 00:58:03 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0980.000; Fri, 4 Jul 2014 00:58:03 +0000 From: Dave Thaler To: Eric Burger , Apps Discuss Thread-Topic: [apps-discuss] Status of URI scheme prefix issue Thread-Index: Ac+XGKFchZ482wW2Tk+/oIeaAHBf7QAALpFgAAHxMIAAAEmNQA== Date: Fri, 4 Jul 2014 00:58:03 +0000 Message-ID: <410c439cefa74f37acf6f9dc86f65929@BY2PR03MB412.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(24454002)(189002)(51704005)(199002)(21056001)(80022001)(15202345003)(86362001)(83322001)(85306003)(101416001)(54356999)(76176999)(92566001)(19580405001)(74316001)(50986999)(19580395003)(20776003)(87936001)(86612001)(64706001)(2656002)(76482001)(77982001)(83072002)(81542001)(74502001)(46102001)(76576001)(33646001)(107046002)(81342001)(99396002)(85852003)(79102001)(99286002)(107886001)(31966008)(106356001)(95666004)(15975445006)(105586002)(74662001)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1fEX4yJK-Z-wovkMzHYp53MZ5wQ Subject: Re: [apps-discuss] Status of URI scheme prefix issue 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, 04 Jul 2014 00:58:15 -0000 > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Eric Burger > Sent: Thursday, July 3, 2014 5:45 PM > To: Apps Discuss > Subject: Re: [apps-discuss] Status of URI scheme prefix issue >=20 > Is there a way of not breaking everything all at once? What is the differ= ence > between a prefixed 'scheme' and a scheme with a parameter? I.e., instead = of > ms-xbl-:mumble, one has ms-xbl:mumble;guid=3D? Or, ms- > xbl:///mumble? Or, ms-xbl://foo//mumble? The particular way > is registered by MS in this case. It might be nice to define a scheme that was an applaunch:///mumble o= r whatever, for many years now, all common OS's (Android/iOS/Windows/etc.) have already= been using app-specific scheme names to launch. Having an 'applaunch' (or whatev= er) generic scheme would not be usable for some time since it would require changes in = the launching logic of the OS, and apps want to run on the widely deployed OS's= and not future ones that aren't the vast majority of deployed base. So in the mean= time, everyone will continue existing practice. >=20 > There may be two orders of magnitude of prefixed 'schemes' than registere= d > schemes, but I would bet there are seven or nine orders of magnitude more > usage of the registered schemes than the prefixed schemes. I'd agree with you there. > And, since these > are really only happening in the past few months with the advent of "deep > application links," I would offer it is not too late to do the right thin= g. Not sure where "past few months" comes from. This has been going on for years. -Dave >=20 > The thing we call a prefixed 'scheme' is not a scheme at all. There is no > interoperability, there is no directives for how to interpret the scheme,= it > breaks standards-based tools, it is less than ideal. >=20 > On Jul 3, 2014, at 7:49 PM, Dave Thaler wrote: >=20 > > Regarding "support for scheme prefix registration/delegation" (ticket #= 16), > last IETF there was rough consensus in room for NOT allowing registering = a > prefix, and that we would communicate this to the W3C and discuss with > them, and then come back to the WG. > > > > We just sent a liaison statement to the W3C on this (and other issues w= e > said we would welcome W3C input on), see http://www.ietf.org/mail- > archive/web/apps-discuss/current/msg12289.html. > > > > Separately, I also managed to get ahold of some interesting data on > current use. > > > > Total # of schemes currently registered with IANA: 188 (of which 74 wer= e > done by Alexey and me during the third-party registration experiment) > > > > Total # of all registered schemes outside of our experiment: 114 > > > > Xbox Live has apparently always used a prefix to generate a URI scheme > for every game title, which is used to launch the game. That is "ms-xbl- > " where is replaced with a GUID. > > Approximate # of Xbox Live scheme names used: 6873 > > > > I strongly suspect that Xbox Live isn't the only such deployed example.= As > previously discussed, using URI schemes to launch associated apps is alre= ady > a de facto standard on most platforms (Android, iOS, Windows, etc.) > whether we like it or not. This new data point implies that widely deplo= yed > use of prefixes probably dwarf the number of all registered schemes by tw= o > orders of magnitude. > > > > In light of this data, the view of "no prefixes" starts sounding suspic= iously > like the "no NATs" > > position of denial that the IETF was once in before Behave was chartere= d. > > It would seem to me that we should think about how we DO want to deal > with prefixes, if not by registering the prefix itself. > > > > -Dave > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Jul 3 18:25: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 DA1A41A0177 for ; Thu, 3 Jul 2014 18:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, 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 Ix_1EXMvNiMA for ; Thu, 3 Jul 2014 18:25:47 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B00F1B28BC for ; Thu, 3 Jul 2014 18:25:44 -0700 (PDT) Received: from 180.sub-70-208-130.myvzw.com ([70.208.130.180]:6325 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2sFv-0007rf-4n; Thu, 03 Jul 2014 18:25:41 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_1DE7F7C6-0FF4-4FAA-9539-45344AB55B86"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Eric Burger In-Reply-To: <410c439cefa74f37acf6f9dc86f65929@BY2PR03MB412.namprd03.prod.outlook.com> Date: Thu, 3 Jul 2014 21:25:37 -0400 Message-Id: References: <410c439cefa74f37acf6f9dc86f65929@BY2PR03MB412.namprd03.prod.outlook.com> To: Dave Thaler X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BVW0KlUjeDJWakZOLnNfU3y92a4 Cc: Apps Discuss Subject: Re: [apps-discuss] Status of URI scheme prefix issue 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, 04 Jul 2014 01:25:48 -0000 --Apple-Mail=_1DE7F7C6-0FF4-4FAA-9539-45344AB55B86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This argument would fly if (1) it was a small deviation from the = definition of a scheme and (2) the IETF would not be willing to = acknowledge there is a problem to be solved. I would offer we do see there is a problem to be solved. I would offer we can solve this problem with minimal changes to what is = deployed. I would offer if we relatively quickly solve the problem, the bad stuff = will go away over the next three years. Remember, we are talking mobile = phones with average life spans of 18 months, not desktop PC that are = still running WindowsXP or DOS 5.1. In fact, fix it now before this leaks much more into the desktop realm.=20= What is being done today is a misguided attempt to enshrine silos (iOS, = Android, etc.) that will not talk with each other. Apple, MS, and Google = might not want a working scheme, but developers (and users) do. There is still 20 hours before the -00 cutoff=85 On Jul 3, 2014, at 8:58 PM, Dave Thaler wrote: > It might be nice to define a scheme that was an = applaunch:///mumble or whatever, > for many years now, all common OS's (Android/iOS/Windows/etc.) have = already been > using app-specific scheme names to launch. Having an 'applaunch' (or = whatever) generic > scheme would not be usable for some time since it would require = changes in the > launching logic of the OS, and apps want to run on the widely deployed = OS's and not > future ones that aren't the vast majority of deployed base. So in the = mean time, > everyone will continue existing practice. --Apple-Mail=_1DE7F7C6-0FF4-4FAA-9539-45344AB55B86 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----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTtgKRAAoJEDY/T2tCIPW3CVUP/RPB9y6gx2bE9wVSy5aaJJka aDPx3iOXKjd5J5G63UXL7u5b55VHSpKM2sJ7rHCX6fhEE/jhqmBuNiXH91OLJfDU hLm8yP0xgTAPKNp1XpbSdWjKnvV8sjAEB0Kq167r6ftXFnIpY6julFFlvOv5l2cp EFUl/Qa6OhFkaOeABhVkDNRJmulwqfjtYhGywsz2hlJ10ykXdFGupIXnwXBd8Xto ggAlUVC3D3RqNgAkkCA5cdMCKmh4RsU9MKO2EirmAxzi4V62EA9wV0jJYwryHxIT Bl6mo7kR2wAwUSWvlVXVNOoaj76ceFLAXZ5VqJNfrdVSyzmBP7nV+1BdtVLhYXTb 38g+ZUTduJkeFMQY7ZXUz1p9um1Q1bxrbTPgR2Ppv6b796JP8kqSj0EwYRtbw4CD sQP2nq57S7ZhLLLt0STf0+m8u23Q3Mv/zzUzCR1blYLSbcMeRpB/wfPnjd15QvHB +HOsgPZwmHDJQNlFRIfnoTZgdKTGtFWFkbFqOixlSrBbzoIWTgFr5w36MxIdS7UM b76Bxd755+1csC9e7qggqt9sR49hbKs3/V8Tq2jnugffrvSNIYkm0EDiLDq5NLea GdJWr0N4wYpuWfUQkAigZ+lk5dq09j+efD24VkiK//loP2+KyIfCnnkaowwucGlO acmY0sxqhS3Drd1VGzLc =tCOX -----END PGP SIGNATURE----- --Apple-Mail=_1DE7F7C6-0FF4-4FAA-9539-45344AB55B86-- From nobody Thu Jul 3 18:25: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 8ED131B28BC; Thu, 3 Jul 2014 18:25:54 -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 TEPbIBl5_A7M; Thu, 3 Jul 2014 18:25:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2AB1B28B8; Thu, 3 Jul 2014 18:25:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1D2DD180095; Thu, 3 Jul 2014 18:25:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140704012539.1D2DD180095@rfc-editor.org> Date: Thu, 3 Jul 2014 18:25:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SNIA_nYr_VceOm-93bqTvFUxiPI Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7293 on The Require-Recipient-Valid-Since Header Field and SMTP Service Extension 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, 04 Jul 2014 01:25:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7293 Title: The Require-Recipient-Valid-Since Header Field and SMTP Service Extension Author: W. Mills, M. Kucherawy Status: Standards Track Stream: IETF Date: July 2014 Mailbox: wmills_92105@yahoo.com, msk@fb.com Pages: 24 Characters: 54440 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-rrvs-header-field-11.txt URL: http://www.rfc-editor.org/rfc/rfc7293.txt This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension. The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jul 3 18:40: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 4C6A31B2B8F for ; Thu, 3 Jul 2014 18:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.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, 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 WM053VB26iTD for ; Thu, 3 Jul 2014 18:40:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A55D1A0AE3 for ; Thu, 3 Jul 2014 18:40:41 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.974.11; Fri, 4 Jul 2014 01:40:37 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0980.000; Fri, 4 Jul 2014 01:40:37 +0000 From: Dave Thaler To: Eric Burger Thread-Topic: [apps-discuss] Status of URI scheme prefix issue Thread-Index: Ac+XGKFchZ482wW2Tk+/oIeaAHBf7QAALpFgAAHxMIAAAEmNQAABJVGAAABfEvA= Date: Fri, 4 Jul 2014 01:40:36 +0000 Message-ID: <20e1c7e4252c480e83a986f863f124bf@BY2PR03MB412.namprd03.prod.outlook.com> References: <410c439cefa74f37acf6f9dc86f65929@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(189002)(51704005)(24454002)(199002)(95666004)(74316001)(2656002)(99286002)(93886003)(87936001)(54356999)(106356001)(107046002)(80022001)(64706001)(81342001)(31966008)(20776003)(86362001)(77982001)(83322001)(79102001)(85306003)(33646001)(76482001)(85852003)(83072002)(21056001)(46102001)(105586002)(50986999)(76576001)(81542001)(76176999)(101416001)(19580395003)(74662001)(19580405001)(86612001)(92566001)(74502001)(99396002)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hCL0ZCjNCsSZf0HIxbu9Oww_M9c Cc: Apps Discuss Subject: Re: [apps-discuss] Status of URI scheme prefix issue 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, 04 Jul 2014 01:40:43 -0000 > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Thursday, July 3, 2014 6:26 PM > To: Dave Thaler > Cc: Apps Discuss > Subject: Re: [apps-discuss] Status of URI scheme prefix issue >=20 > This argument would fly if (1) it was a small deviation from the definiti= on of a > scheme and (2) the IETF would not be willing to acknowledge there is a > problem to be solved. >=20 > I would offer we do see there is a problem to be solved. >=20 > I would offer we can solve this problem with minimal changes to what is > deployed. >=20 > I would offer if we relatively quickly solve the problem, the bad stuff w= ill go > away over the next three years. Remember, we are talking mobile phones > with average life spans of 18 months, not desktop PC that are still runni= ng > WindowsXP or DOS 5.1. It's not just mobile phones. App launch is used on mobile phones, desktop PCs, and other devices like Xboxes. > In fact, fix it now before this leaks much more into the desktop realm. It's been in the desktop realm already for at least 2 years. > What is being done today is a misguided attempt to enshrine silos (iOS, > Android, etc.) that will not talk with each other. Apple, MS, and Google = might > not want a working scheme, but developers (and users) do. I'm not sure anyone "might not want" one (i.e. I think they do or would). > There is still 20 hours before the -00 cutoff... Go ahead :) -Dave >=20 > On Jul 3, 2014, at 8:58 PM, Dave Thaler wrote: >=20 > > It might be nice to define a scheme that was an > > applaunch:///mumble or whatever, for many years now, all > common > > OS's (Android/iOS/Windows/etc.) have already been using app-specific > > scheme names to launch. Having an 'applaunch' (or whatever) generic > > scheme would not be usable for some time since it would require > > changes in the launching logic of the OS, and apps want to run on the > > widely deployed OS's and not future ones that aren't the vast majority = of > deployed base. So in the mean time, everyone will continue existing > practice. From nobody Thu Jul 3 20:27: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 D299C1A0AEB for ; Thu, 3 Jul 2014 20:27:01 -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 5hjff1FwgfxG for ; Thu, 3 Jul 2014 20:26:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B26C1A0ACC for ; Thu, 3 Jul 2014 20:26:58 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 4 Jul 2014 03:26:56 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Fri, 4 Jul 2014 03:26:56 +0000 From: Larry Masinter To: "apps-discuss@ietf.org" , Dave Thaler , Ted Hardie , Tony Hansen Thread-Topic: New Version Notification for draft-ietf-appsawg-uri-scheme-reg-01.txt Thread-Index: AQHPlxKSHyZ8DKfCKEeOeL9+ed6yRpuPOkSw Date: Fri, 4 Jul 2014 03:26:55 +0000 Message-ID: References: <20140703225940.1804.1232.idtracker@ietfa.amsl.com> In-Reply-To: <20140703225940.1804.1232.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(80022001)(64706001)(46102001)(74662001)(74502001)(31966008)(33646001)(20776003)(15975445006)(101416001)(1511001)(79102001)(81542001)(66066001)(95666004)(99286002)(76482001)(83072002)(81342001)(85306003)(85852003)(86362001)(77982001)(50986999)(99396002)(76176999)(21056001)(92566001)(74316001)(54356999)(87936001)(83322001)(107886001)(19580395003)(2656002)(105586002)(106356001)(106116001)(15202345003)(107046002)(76576001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0JLG4GQez26hJfLOC4Na6JQDilQ Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-uri-scheme-reg-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: Fri, 04 Jul 2014 03:27:02 -0000 SSBkb24ndCB0aGluayB3ZSdyZSBnb2luZyBmYXIgZW5vdWdoIHRvIHNpbXBsaWZ5IHRoZSBwcm9j ZXNzLCB0byBoYXZlIGFueSBob3BlIElBTkEgd2lsbCBiZSBtb3JlIHVzZWZ1bCB0aGFuIFdpa2lw ZWRpYSBvciBzZWFyY2ggZm9yIHRoZSBzY2hlbWUsIGZvciBhbnl0aGluZyBvdGhlciB0aGFuIHBl ZGFudGljIG9yIGxlZ2FsIHB1cnBvc2VzLg0KDQpUaGUgJ2d1aWRlbGluZXMnIGFyZSBvaywgYnV0 IHRoZSBwcm9jZXNzIGlzIHdheSB0b28gY29tcGxpY2F0ZWQsIHJhdGUgbGltaXRlZCwgZG9lc24n dCBoZWxwIHdhbm5hLWJlJ3MgaW1wbGVtZW50IHRoaW5ncyBjb21wYXRpYmx5LCAgYW5kIGRvZXNu J3QgcHJvdmlkZSBlbm91Z2ggaW5jZW50aXZlIHRvIHJlZ2lzdGVyIGZvciByZWdpc3RyYXRpb24g dG8gYmUgbmVhci11bml2ZXJzYWxseSB0aW1lbHkuIFRpbWVseSBjb21wbGV0ZW5lc3MgaXMgdGhl IHJlcXVpcmVtZW50IHRvIGJlIGFibGUgdG8gYW5zd2VyIHF1ZXN0aW9ucyBsaWtlICJhcmUgdGhl cmUgYW55IHNjaGVtZXMgdGhhdCBkbyBYIiBhbmQgdGhlIGxpa2UsIGFuZCBhbHNvIHRvIGtub3cg d2hlbiB0aGUgJ2F1dGhvcml0YXRpdmUnIGluZm9ybWF0aW9uIGluIHRoZSByZWdpc3RyeSBoYXMg YmVlbiBzdXBwbGFudGVkIHN1cnJlcHRpdGlvdXNseS4gDQoNCkknbSBsZWFuaW5nIHRvd2FyZCBy ZWNvbW1lbmRlZCBjcm93ZC1zb3VyY2UgdGVjaG5vbG9neS0tIGdldCBwZXJtaXNzaW9uIHRvIGdp dmUgZWFjaCBzY2hlbWUgYSBwYWdlIHdoaWNoIHBlb3BsZSBjYW4gJ0xpa2UnIG9yICdDb21tZW50 Jy4gDQoNCkkgdW5kZXJzdGFuZCB0aGVyZSdzIGEgbW9uYXJjaHkgcGVyc3BlY3RpdmUgd2hpY2gg d291bGQgcHJlZmVyIGEgc2luZ2xlICJMaXZpbmcgU3RhbmRhcmQiIGxpc3Qgb2YgcGxhdGZvcm0g c2NoZW1lIG5hbWVzIHJhdGhlciB0aGFuIGEgcmVnaXN0cnkuIFRoaXMgd291bGQgaGF2ZSB0aGUg YWR2YW50YWdlIGZvciBjb250ZW50IGNyZWF0b3JzIG9mIHR1cm5pbmcgYSBjb21iaW5hdG9yaWFs IHRlc3Rpbmcgam9iIGludG8gYSBsaW5lYXIgb25lLCB3aGljaCBtYXkgYmUgd2h5IGl0J3MgcG9w dWxhci4gQXJlIHRoZSB0d28gbW9kZWxzIHJlY29uY2lsYWJsZT8gDQoNCkxhcnJ5IChEdWtlIG9m IFVybCkNCi0tDQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQo= From nobody Fri Jul 4 06:14: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 CDD5A1B291C; Fri, 4 Jul 2014 06:14:20 -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 wYKO6dN5sZUG; Fri, 4 Jul 2014 06:14:17 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BA51B2873; Fri, 4 Jul 2014 06:14:16 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id z11so1156437lbi.38 for ; Fri, 04 Jul 2014 06:14:15 -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=DNeYJaaIcGvL1iKiIdzoruan+2W9BpXubjWWAx+cYZE=; b=s82v8IwmAbevJuZ1I75k5KwV7Cnc+B7zGE7O0/P3voch2VyaZ+1tkkKFhgR3YfgWj3 OUx/+1apEiP0t6WtWMgRafwljr64ueH4Jyy9VqI2oz40fe/b9+ZkmYGTQcZAB50xVYLt zODHVubqshIjnyHAQoLhdzLs1H7h86zaISYsF+qHDhGOYGw3bgZ0rkU3QDEPZ0Aq50y/ Q/BDokYJ7G52iRaTCJapBzfbPiQjziBz6xwUsWGzX8Ij3bmQlMCbRel5cvFE8KthNxju lz+83HMKsYu1Ke5gjM1ExlxoMrDIDbeX+GbjrSZKzujQNc7nMyW6br99b+gncQASh172 VwKw== MIME-Version: 1.0 X-Received: by 10.112.155.129 with SMTP id vw1mr7961684lbb.7.1404479655359; Fri, 04 Jul 2014 06:14:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 4 Jul 2014 06:14:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> Date: Fri, 4 Jul 2014 09:14:15 -0400 X-Google-Sender-Auth: QeGJbYWjtk5uOP4KNPI25gWDVVE Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mprAokDnQiTX86LpTt6K72ycjmo Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 04 Jul 2014 13:14:21 -0000 Hi, SM. I don't see much in your message that's actionable. For the bits that are: > The TZ database itself is not an IETF Contribution. Any enhancements is up > to the TZ Coordinator. I suggest that the IETF does not make any > recommendations about the TZ database. I think that it is better for the > IETF to stay away from that process. The only thing that the charter leaves in scope with regard to that happens if we find security issues, while building the distribution protocol. I think it's a good idea to leave that in scope (and I don't expect it to be triggered). The IESG will consider your comment in this regard. > There isn't any mention of a "IANA timezone database" in that BCP. Indeed; I changed "IANA Time Zone Database" and "IANA timezone database" to "Time Zone Database" in version -03. Thanks. Barry On Thu, Jul 3, 2014 at 5:32 PM, S Moonesamy wrote: > At 08:06 20-06-2014, Barry Leiba wrote: >> >> Cyrus Daboo has proposed a new working group in the Applications Area, >> and I'm initiating charter discussion on it: >> >> https://datatracker.ietf.org/doc/charter-ietf-tzdist/ >> >> We'll have the charter discussion here on apps-discuss. Assuming a >> working group comes out of this, we'll create a new mailing list for >> the actual work, once the charter is done. > > > I took a quick look at the proposed charter. > > "The following are Out of scope for the working group: > > > - Any changes to the IANA timezone database process or infrastructure, > as documented in RFC 6557, other than recommendations for possible > security enhancements." > > A few months ago there was a hearing in the United States. A member of the > legislature asked the ICANN President a question (I do not recall the exact > words): > > What is the ccTLD for Crimea? > > http://www.bbc.com/news/world-europe-28144334 > > The TZ database itself is not an IETF Contribution. Any enhancements is up > to the TZ Coordinator. I suggest that the IETF does not make any > recommendations about the TZ database. I think that it is better for the > IETF to stay away from that process. > > According to BCP 175: > > 'TZ Database: The Time Zone Database, sometimes referred to as the > "Olson Database". This database consists of information about > offsets from UTC for different localities, including daylight > saving time (DST) transition information.' > > There isn't any mention of a "IANA timezone database" in that BCP. Would > the IESG like to include the TZ Database in discussions about the IANA > Transition? > > 'The working group can consider adding a mechanism, such as a > > "namespace" prefix, to differentiate different timezone sources, > but the nature of the timezone identifiers used will be > controlled by the sources themselves.' > > Formalizing time zone sources may lead down a path where the question of the > authoritative source is raised. "namespace" could create the conditions for > contentious strings [1]. > > Regards, > S. Moonesamy > > 1. I haven't given much thought to all this. From nobody Fri Jul 4 08:24: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 4813E1B2A98 for ; Fri, 4 Jul 2014 08:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_FILL_THIS_FORM_SHORT=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 xdi5S2NtKJJu for ; Fri, 4 Jul 2014 08:24:20 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EF81B2A15 for ; Fri, 4 Jul 2014 08:24:19 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so1579260qgd.10 for ; Fri, 04 Jul 2014 08:24:19 -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=MhjzY7itF8BaRrRVukuH3+Ou4xqTwVZBCwZD1CGtCr0=; b=T8pAGKQXAIM8cnIRmctpHvAiJ2gowilNKISWn50ydjyMYPLO+oVyfKa3I2eErZXQ3q x7LYTMDRJRngOgEV+PWBQXtYHYMR1nY2YQWHaZ6MmzFe43BL5GLJ4eFhHXu73S8VLqIn A3ZruVmohMyB5wNYD8HR8BTDwcUnXKl/d3J12G3Ojzs2wtXLAl2Wg+p44lHlGpTGLN8M +jkL18mpkNeK9/xcTg4PwUKEnRpcN4jFG2ozRZqnAsMy/zKXh9UCZBbcEZGjPIOG7k9U WLqiDeURf50WhEPr1ZXCwg6so4ocK5dRqlKy/Hdn5AGARWyQAgd3oUeTWf20b19rl70V qhBQ== MIME-Version: 1.0 X-Received: by 10.224.128.193 with SMTP id l1mr19176611qas.91.1404487459091; Fri, 04 Jul 2014 08:24:19 -0700 (PDT) Received: by 10.140.104.106 with HTTP; Fri, 4 Jul 2014 08:24:19 -0700 (PDT) Date: Fri, 4 Jul 2014 23:24:19 +0800 Message-ID: From: Neng Geng Huang To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a11c31a3a173bca04fd5fb828 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Tkh5yOQ7cWWG7KFbaiIvxOTz3Xk Subject: [apps-discuss] Two new Internet Drafts (Independent Submissions) 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, 04 Jul 2014 15:24:23 -0000 --001a11c31a3a173bca04fd5fb828 Content-Type: text/plain; charset=UTF-8 Hello, everybody: I have submitted two revised Internet Drafts as Independent Submissions. https://datatracker.ietf.org/doc/draft-huangng-utid/ https://datatracker.ietf.org/doc/draft-huangng-idtp/ Here is a brief introduction to the concepts of UTID and IDTP and discuss their use through three small examples, showing the potential to construct a new kind of application architecture for the Internet of Things. UTID is a unique identifier for a physical thing or a virtual thing in the world, which consists of three components with the following syntax: Id~catalog$dns It is a character-based identifier, where dns is a domain name of organization who named the thing, catalog is used by the organization to classify the thing, and id is unique in the scope of dns and catalog. Examples are 125.product~db$com1.test, ~db$com1.test, 125.product~$com1.test, and ~$com1.test. IDTP is a communication protocol to tracing messages of things identified by UTIDs, which adapt request/response model and like a hybrid of HTTP and Web Service but using JSON data format rather than XML format. It is characterized by using UTID rather than URL to indicate the destination address and using build-in forward mechanism to trace the messages of UTIDs. The forward rules are UTID suffix match (called *tracing rule* in this paper) and namespace match (called *tracing track* in this paper). The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web Service, or local handling without forwarding. The first example is tracing of products message. A company (com1.test) produced a product and then sold it to another company (com2.test), where UTID is used to identify the product and IDTP is used to trace the message of the product. Fig. 1 Tracing reference between two databases (visit http://www.utid.org/utid/NewArchitecture.html to see the pictures) A record was inserted into database of company com1.test with empty value of tracing key when a product was produced by company com1.test and marked as 125.product~db$com1.test, which may be used to trace to the record by IDTP in the company com1.test (Fig. 1). A record was inserted into database of company com2.test when the product was purchased by company com2.test and re-marked as 312.purchase~db$com2.test, whose message was send back to company com1.test by the following IDTP request: idtp:0.9/1 utid:125.product~db$com1.test ns:u.iot.db name:UtidEcho len:39 {"refUtid":"312.purchase~db$com2.test"} This request was forwarded to the database of company com1.test by the tracing mechanism of IDTP using the UTID carried by the request as destination address and was used to update the field of tracing key of the record. Then a response was returned back: idtp:0.9/1 code:200 OK len:17 {"msg":"success"} Therefore, tracing references between the two databases were established, just like a foreign key reference in a relational database system. The difference is that the tracing reference is build between two independent databases and any client application may trace any UTIDs through tracing references by IDTP protocol. The second example is tracing different properties of same UTID. A company (com1.test) has a temperature sensor, which sends temperature value to a database server every 10 minutes. The company has an internal network, which consists of a database server that saves historical temperature value, a tracing bridge that connect to the temperature sensor, and a tracing gateway that forwards request based on tracing rule and tracing track. A tracing bridge may be a system with very low capacity of computation, such as a single chip microcomputer with Ethernet interface, which acts as a connection node between IDTP node and non-IDTP node (Fig. 2). The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded to the tracing bridge by the tracing gateway if the namespace (field ns in the request) is u.iot.sensor when a user sent a request for real time temperature value. The tracing bridge got temperature value from the sensor and returned the value to the requester. A request with the same UTID was forwarded to the database server by the tracing gateway if the namespace is u.iot.db when a user sent a request for historical temperature value. The database server retrieved temperature values from database and returned the value to the requester. Fig. 2 Tracing to different node by namespace with same UTID (visit http://www.utid.org/utid/NewArchitecture.html to see the pictures) The tracing rule and tracing track on the tracing gateway is listed in Tab. 1 and Tab. 2. Tab. 1 Tracing rule on the tracing gateway *utid suffix* *Rule* $com1.test ruel1 Tab. 2 Tracing track on the tracing gateway *Rule* *Namespace* *Protocol* *Address* *Port* rule1 u.iot.db tcp db.com1.test 8091 rule1 u.iot.sensor tcp bridge.com1.test 8092 The third example is for local request and remote request. A database server of a company (com1.test) has various kinks of tracing keys, which reference to local database or remote databases. A request may be handled locally or forwarded to remote servers. In this case, the server may deal with this situation easily by set up settings as listed in Tab. 3 and Tab. 4. There is no tracing rule for dns other than itself dns because that IDTP will forward all unmatched requests to TCP port 25604 (default port number for IDTP, registered in IANA) of the server indicated by the dns of the UTID carried by a request. Tab. 3 Tracing rule on the database server *utid suffix* *Rule* $com1.test ruel1 Tab. 4 Tracing track on the database server *Rule* *Namespace* *Protocol* *Address* *Port* rule1 * local It is encouraged to use IDTP request for local calls because of its high efficiency to form a unified API both for local calls and remote calls. This mechanism will help designers to develop highly interoperable application. Despite of the differences between IDTP and Web Service, IDTP is conditional compatible with Web Service, adapts WSDL as data format definition of request and response, and adapt UDDI for the discovery of IDTP service. In summary, UTID and IDTP suggested a new kind of application architecture for the Internet of Things that is universal, simple, low cost, and high efficiency. The architecture simplifies the design of application framework, promote the efficiency of system development, and increase the interoperability of application system. Best regards, Huang -- ------------------------------ Mr. Huang Neng Geng ------------------------------ Associate Professor School of the Internet of Things Wuxi Institute of Technology Wuxi, Jiangsu, China, 214121 Mobile: 86-13921501950 email: huangng@gmail.com --001a11c31a3a173bca04fd5fb828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, everybody:

I have submitted two revised Internet Drafts as= Independent Submissions.


<= /font>
Here is a brief introduction to the c= oncepts of UTID and IDTP and discuss their use through three small examples= , showing the potential to construct a new kind of application architecture= for the Internet of Things.

UTID is a unique identifier for a physical thing o= r a virtual thing in the world, which consists of three components with the following syntax:

Id~catalog$dns

It is a character-based identifier,= where dns is a domain name of organization who named the thing, catalog is used by the organization to classify the thing, and id is unique in the scope of dns an= d catalog. Examples are 125.product~db$com1.test, ~db$com1.test, 125.product~= $com1.test, and ~$com1.test.

IDTP is a communication protocol to= tracing messages of things identified by UTIDs, which adapt request/response model and like a hybrid of HTTP and Web Service but using JSON data format rather than XML format. It is characterized by using UTID rather than URL to indicate the destination address and using build-in forward mechanism to trace the messa= ges of UTIDs. The forward rules are UTID suffix match (called tracing rul= e in this paper) and namespace match (called tracing track in this pape= r). The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web Servi= ce, or local handling without forwarding.

The first example is tracing of pro= ducts message. A company (com1.test) produced a product and then sold it to another company (com2.test), where UTID is used to identify the product and IDTP is used to trace the message of the product.

Fig. 1 Tracing re= ference between two databases=C2=A0=C2=A0(= visit http://www.= utid.org/utid/NewArchitecture.html=C2=A0to see the pictures)

A record was inserted into database= of company com1.test with empty value of tracing key when a product was produced by company com1.test and marked as 125.product~db$com1.test, which may be used= to trace to the record by IDTP in the company com1.test (Fig. 1).

A record was inserted into database= of company com2.test when the product was purchased by company com2.test and re-marked= as 312.purchase~db$com2.test, whose message was send back to company com1.test= by the following IDTP request:

idtp:0.9/1

utid:125.product~db$com1.test

ns:u.iot.db

name:UtidEcho

len:39

=C2=A0

{"refUtid":"312.purchase~db$com2.= test"}

This request was forwarded to the d= atabase of company com1.test by the tracing mechanism of IDTP using the UTID carried by the request as destination address and was used to update the field of tracing = key of the record. Then a response was returned back:

idtp:0.9/1

code:200 OK

len:17

=C2=A0

{"msg":"success"}

Therefore, tracing references betwe= en the two databases were established, just like a foreign key reference in a relational databas= e system. The difference is that the tracing reference is build between two independent databases and any client application may trace any UTIDs throug= h tracing references by IDTP protocol.

The second example is tracing diffe= rent properties of same UTID. A company (com1.test) has a temperature sensor, which sends temperature value to a database server every 10 minutes. The company has an internal network, which consists of a database server that saves historical temperature value, a tracing bridge that connect to the temperature sensor,= and a tracing gateway that forwards request based on tracing rule and tracing t= rack. A tracing bridge may be a system with very low capacity of computation, suc= h as a single chip microcomputer with Ethernet interface, which acts as a connec= tion node between IDTP node and non-IDTP node (Fig. 2).

The sensor was marked as 56.loc1.t~= s$com1.test. A request was forwarded to the tracing bridge by the tracing gateway if the namespace (field ns in the request) is u.iot.sensor when a user sent a requ= est for real time temperature value. The tracing bridge got temperature value f= rom the sensor and returned the value to the requester. A request with the same= UTID was forwarded to the database server by the tracing gateway if the namespac= e is u.iot.db when a user sent a request for historical temperature value. The d= atabase server retrieved temperature values from database and returned the value to= the requester.

Fig. 2 Tracing to= different node by namespace with same UTID (visit = http://www.utid.org/utid/NewArchitecture.html=C2=A0to see the pictures)=

The tracing rule and tracing track = on the tracing gateway is listed in Tab. 1 and Tab. 2.

Tab. 1 Tracing ru= le on the tracing gateway

utid suffix

Rule

$com1= .test

ruel1=

Tab. 2 Tracing tr= ack on the tracing gateway

Rule

Namespace

Protocol

Address

Port

rule1=

u.iot= .db

tcp

db.co= m1.test

8091<= /span>

rule1=

u.iot= .sensor

tcp

bridg= e.com1.test

8092<= /span>

=C2= =A0

The third example is for local requ= est and remote request. A database server of a company (com1.test) has various kinks of tracing keys, which reference to local database or remote databases. A requ= est may be handled locally or forwarded to remote servers. In this case, the se= rver may deal with this situation easily by set up settings as listed in Tab. 3 = and Tab. 4. There is no tracing rule for dns other than itself dns because that IDTP will forward all unmatched requests to TCP port 25604 (default port nu= mber for IDTP, registered in IANA) of the server indicated by the dns of the UTI= D carried by a request.

Tab. 3 Tracing ru= le on the database server

utid suffix

Rule

$com1= .test

ruel1=

Tab. 4 Tracing tr= ack on the database server

Rule

Namespace

Protocol

Address

Port

rule1=

*

local=

=C2= =A0

=C2= =A0

=C2=A0

It is encouraged to use IDTP reques= t for local calls because of its high efficiency to form a unified API both for local calls and remot= e calls. This mechanism will help designers to develop highly interoperable a= pplication.

Despite of the differences between = IDTP and Web Service, IDTP is conditional compatible with Web Service, adapts WSDL as data format definition of request and response, and adapt UDDI for the discovery of IDT= P service.

In summary, UTID and IDTP suggested= a new kind of application architecture for the Internet of Things that is universal, simple, low cost= , and high efficiency. The architecture simplifies the design of application fram= ework, promote the efficiency of system development, and increase the interoperabi= lity of application system.


<= /p>

Be= st regards,


Huang


--
------------------------= ------
Mr. Huang Neng Geng
------------------------------
Associat= e Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, J= iangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com

<= /div>
--001a11c31a3a173bca04fd5fb828-- From nobody Fri Jul 4 11:44: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 C74BF1B2996; Fri, 4 Jul 2014 11:44:48 -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 yGxM5GhM0v-1; Fri, 4 Jul 2014 11:44:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE081B2E96; Fri, 4 Jul 2014 11:44:45 -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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 11:44:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sEqNuP6bIyXu3tlH7Riyn0xTLCE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-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: Fri, 04 Jul 2014 18:44:48 -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 : JSON Merge Patch Authors : Paul Hoffman James M Snell Filename : draft-ietf-appsawg-json-merge-patch-04.txt Pages : 8 Date : 2014-07-04 Abstract: This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a subset of target resource's content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-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 Fri Jul 4 11:48: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 C4AFC1B2EB2 for ; Fri, 4 Jul 2014 11:48:26 -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 PGNMN72uXstl for ; Fri, 4 Jul 2014 11:48:26 -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 E1B2E1B2B19 for ; Fri, 4 Jul 2014 11:48:25 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s64ImNUt021754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Jul 2014 11:48:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] 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.6\)) From: Paul Hoffman In-Reply-To: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> Date: Fri, 4 Jul 2014 11:48:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qzJ_jMub0Bdk2kEpmaju7yeUnjg Subject: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 04 Jul 2014 18:48:26 -0000 Greetings again. This draft incorporates the proposed changes from = Carsten and James, as well as removing the charset option from the MIME = type (based on input from Ned Freed).=20 Please review my new pseudocode, and the new examples at the end. --Paul Hoffman On Jul 4, 2014, at 11:44 AM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : JSON Merge Patch > Authors : Paul Hoffman > James M Snell > Filename : draft-ietf-appsawg-json-merge-patch-04.txt > Pages : 8 > Date : 2014-07-04 >=20 > Abstract: > This specification defines the JSON merge patch format and = processing > rules. The merge patch format is primarily intended for use with = the > HTTP PATCH method as a means of describing a set of modifications to > a subset of target resource's content. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-merge-patch-04 From nobody Fri Jul 4 11:51: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 7952E1B2D60 for ; Fri, 4 Jul 2014 11:51: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 xbCq_C0hJWpy for ; Fri, 4 Jul 2014 11:51:19 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7615D1B2AEE for ; Fri, 4 Jul 2014 11:51:19 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id va2so2180730obc.32 for ; Fri, 04 Jul 2014 11:51:18 -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=9kXZ2Zu5RWidF4ssFWzW7ETKrb2n0X0enIloTB4kcX0=; b=UKkVSdF7taKhYckwRdNa7lp9UWBT53hB9/Wi9jxajcf2P/S013cgA4eXKzWknGr28K oTycNGY1Igu3egTxLQzYDQLHLg9Q1uJMfB2zO1Z/Gc4t5/RgWtHQ/MCTeOe6deVSkqs4 3K+vJqlHhWe+YR7TEy4lktQS4Hc3JIUjEKdV6m7KjV0n6YqNO+TtBBljXpScRvit7pRt X9Ssacc+cVt0B/J5q4cPmD82EFqRYTV2SUwhEBWMP/84bHaK2VVvmRQHitQCE15hDAEn ua0MWUVRCMEuWWNjnYbu0TdVU3cWq9v8rWKK/Nr7fr3QyUkWK/XJg+knoj7tWQy2YAn2 W0IQ== MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr12457919obr.78.1404499878801; Fri, 04 Jul 2014 11:51:18 -0700 (PDT) Received: by 10.60.179.81 with HTTP; Fri, 4 Jul 2014 11:51:17 -0700 (PDT) Received: by 10.60.179.81 with HTTP; Fri, 4 Jul 2014 11:51:17 -0700 (PDT) In-Reply-To: <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> Date: Fri, 4 Jul 2014 11:51:17 -0700 Message-ID: From: James M Snell To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01538ad85cf62d04fd629c37 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hYMvcKFCuYcTbBdePyXuItSUb4A Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 04 Jul 2014 18:51:22 -0000 --089e01538ad85cf62d04fd629c37 Content-Type: text/plain; charset=UTF-8 +1... On Jul 4, 2014 11:48 AM, "Paul Hoffman" wrote: > Greetings again. This draft incorporates the proposed changes from Carsten > and James, as well as removing the charset option from the MIME type (based > on input from Ned Freed). > > Please review my new pseudocode, and the new examples at the end. > > --Paul Hoffman > > On Jul 4, 2014, at 11:44 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 : JSON Merge Patch > > Authors : Paul Hoffman > > James M Snell > > Filename : draft-ietf-appsawg-json-merge-patch-04.txt > > Pages : 8 > > Date : 2014-07-04 > > > > Abstract: > > This specification defines the JSON merge patch format and processing > > rules. The merge patch format is primarily intended for use with the > > HTTP PATCH method as a means of describing a set of modifications to > > a subset of target resource's content. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-04 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e01538ad85cf62d04fd629c37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1...

On Jul 4, 2014 11:48 AM, "Paul Hoffman"= ; <paul.hoffman@vpnc.org>= ; wrote:
Greetings again. This draft incorporates the proposed changes from Carsten = and James, as well as removing the charset option from the MIME type (based= on input from Ned Freed).

Please review my new pseudocode, and the new examples at the end.

--Paul Hoffman

On Jul 4, 2014, at 11:44 AM, in= ternet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = JSON Merge Patch
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Paul = Hoffman
> =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=A0James M Snell
> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-= appsawg-json-merge-patch-04.txt
> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 8
> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2= 014-07-04
>
> Abstract:
> =C2=A0 This specification defines the JSON merge patch format and proc= essing
> =C2=A0 rules. =C2=A0The merge patch format is primarily intended for u= se with the
> =C2=A0 HTTP PATCH method as a means of describing a set of modificatio= ns to
> =C2=A0 a subset of target resource's content.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-a= ppsawg-json-merge-patch/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-jso= n-merge-patch-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-appsawg-json-merge-patch-04

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--089e01538ad85cf62d04fd629c37-- From nobody Sat Jul 5 06:37: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 3A0431A0644 for ; Sat, 5 Jul 2014 06:37:22 -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 dFraJiaMqm2i for ; Sat, 5 Jul 2014 06:37:20 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1313E1A0A86 for ; Sat, 5 Jul 2014 06:37:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,607,1399989600"; d="scan'208";a="17764341" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 05 Jul 2014 23:29:03 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7489"; a="233172838" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 05 Jul 2014 23:37:18 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Sat, 5 Jul 2014 23:37:17 +1000 From: "Manger, James" To: Paul Hoffman , IETF Apps Discuss Date: Sat, 5 Jul 2014 23:37:15 +1000 Thread-Topic: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model Thread-Index: Ac+XuI9JFMEeJcucTCGxoiGgXyaK5QAmDdvA Message-ID: <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> In-Reply-To: <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> 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/Z7PaIRApew8893_krVET4r9OL1g Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 05 Jul 2014 13:37:22 -0000 KzENCg0KUHNldWRvIGNvZGUgd29ya3Mgd2VsbCBmb3IgZGVzY3JpYmluZyB0aGUgbWVyZ2UgcHJv Y2Vzcy4NCg0KVGhlIG9ubHkgcmVtYWluaW5nIG5vbi1lZGl0b3JpYWwgY2hhbmdlIHJlcXVpcmVk IGlzIHRvIHJlbW92ZSB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGZyb20gc2VjdGlvbiAxICJJbnRy b2R1Y3Rpb24iOg0KDQogICBBIEpTT04gbWVyZ2UgcGF0Y2ggZG9jdW1lbnQgY2FuIG9ubHkgYmUg YSBKU09OIGFycmF5IG9yIGEgSlNPTg0KICAgb2JqZWN0Lg0KDQpUaGUgcHNldWRvIGNvZGUgZG9l cyBub3QgaW1wbGVtZW50IHRoaXMgcmVzdHJpY3Rpb24uIFR3byBvZiB0aGUgdGVzdCBjYXNlcyBp biBhcHBlbmRpeCBBIHZpb2xhdGUgdGhpcyByZXN0cmljdGlvbi4NCg0KDQpFZGl0b3JpYWwgc3Vn Z2VzdGlvbnM6DQoNCiogQ2hhbmdlICJtYXJnZSIgdG8gIm1lcmdlIiBbc2VjdGlvbiAyLCAybmQg cGFyYWdyYXBoLCBwYWdlIDNdDQoNCiogVGhlIGFic3RyYWN0IGFuZCBpbnRvIGJvdGggaW5jbHVk ZSB0aGUgZm9sbG93aW5nIHBocmFzZSB0aGF0IGlzIGEgYml0IGF3a3dhcmQ6DQoNCiAgIG1vZGlm aWNhdGlvbnMgdG8gYSBzdWJzZXQgb2YgdGFyZ2V0IHJlc291cmNlJ3MgY29udGVudC4NCg0KTWln aHQgcmVhZCBiZXR0ZXIgYXM6DQoNCiAgIG1vZGlmaWNhdGlvbnMgdG8gYSB0YXJnZXQgcmVzb3Vy Y2UncyBjb250ZW50Lg0KDQoqIEl0IHdvdWxkIGJlIHdvcnRoIGV4cGxpY2l0bHkgc3RhdGluZyB0 aGF0IHRoZSB0YXJnZXQgcmVzb3VyY2UgYW5kIG1lcmdlIHBhdGNoIGFyZSBKU09OIHZhbHVlcy4g QWRkIGEgc2VudGVuY2UgdG8gdGhlIGVuZCBvZiB0aGUgMm5kIHBhcmFncmFwaCBvZiBzZWN0aW9u IDIgc28gaXQgcmVhZHM6DQoNCiAgIE1lcmdlUGF0Y2ggLi4uIHRha2VzIHR3byBhcmd1bWVudHM6 IHRoZSB0YXJnZXQgcmVzb3VyY2UgZG9jdW1lbnQNCiAgIGFuZCB0aGUgbWVyZ2UgcGF0Y2ggZG9j dW1lbnQuIFRoZSBUYXJnZXQgYXJndW1lbnQgY2FuIGJlIGFueQ0KICAgSlNPTiB2YWx1ZSwgb3Ig dW5kZWZpbmVkLiBUaGUgUGF0Y2ggYXJndW1lbnQgY2FuIGJlIGFueSBKU09OIHZhbHVlLg0KDQoq IElzIHRoZSBjb250YWN0IGluIHRoZSBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbiAoc2VjdGlvbiA0 ICJJQU5BIENvbnNpZGVyYXRpb25zIikgdXN1YWxseSBhbiBhdXRob3IgYXMgaW4gdGhlIGRyYWZ0 LCBvciBpcyBpdCBiZXR0ZXIgdG8gdXNlLCBzYXksIElFU0cgPGllc2dAaWV0Zi5vcmc+Pw0KDQoq IEluIHNlY3Rpb24gNCAiSUFOQSBDb25zaWRlcmF0aW9ucyIgY2hhbmdlOg0KICAic2FtZSBlbmNv ZGluZyBjb25zaWRlcmF0aW9ucyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2IFtSRkM3MTU5XS4iDQog IFRvDQogICJzYW1lIGVuY29kaW5nIGNvbnNpZGVyYXRpb25zIHNwZWNpZmllZCBpbiBTZWN0aW9u IDggW1JGQzcxNTldLiINCg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEhvZmZtYW4NClNlbnQ6IFNhdHVyZGF5LCA1IEp1 bHkgMjAxNCA0OjQ4IEFNDQpUbzogSUVURiBBcHBzIERpc2N1c3MNClN1YmplY3Q6IFthcHBzLWRp c2N1c3NdIGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLW1lcmdlLXBhdGNoLTA0OiBub3cgd2l0aCBh IG5ldyBwcm9jZXNzaW5nIG1vZGVsDQoNCkdyZWV0aW5ncyBhZ2Fpbi4gVGhpcyBkcmFmdCBpbmNv cnBvcmF0ZXMgdGhlIHByb3Bvc2VkIGNoYW5nZXMgZnJvbSBDYXJzdGVuIGFuZCBKYW1lcywgYXMg d2VsbCBhcyByZW1vdmluZyB0aGUgY2hhcnNldCBvcHRpb24gZnJvbSB0aGUgTUlNRSB0eXBlIChi YXNlZCBvbiBpbnB1dCBmcm9tIE5lZCBGcmVlZCkuIA0KDQpQbGVhc2UgcmV2aWV3IG15IG5ldyBw c2V1ZG9jb2RlLCBhbmQgdGhlIG5ldyBleGFtcGxlcyBhdCB0aGUgZW5kLg0KDQotLVBhdWwgSG9m Zm1hbg0KDQpPbiBKdWwgNCwgMjAxNCwgYXQgMTE6NDQgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyB3cm90ZToNCg0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDog SlNPTiBNZXJnZSBQYXRjaA0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUGF1bCBIb2ZmbWFu DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKYW1lcyBNIFNuZWxsDQo+IAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1tZXJnZS1wYXRjaC0wNC50eHQNCj4gCVBh Z2VzICAgICAgICAgICA6IDgNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTQtMDctMDQNCj4gDQo+ IEFic3RyYWN0Og0KPiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZSBKU09OIG1lcmdl IHBhdGNoIGZvcm1hdCBhbmQgcHJvY2Vzc2luZw0KPiAgIHJ1bGVzLiAgVGhlIG1lcmdlIHBhdGNo IGZvcm1hdCBpcyBwcmltYXJpbHkgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIHRoZQ0KPiAgIEhUVFAg UEFUQ0ggbWV0aG9kIGFzIGEgbWVhbnMgb2YgZGVzY3JpYmluZyBhIHNldCBvZiBtb2RpZmljYXRp b25zIHRvDQo+ICAgYSBzdWJzZXQgb2YgdGFyZ2V0IHJlc291cmNlJ3MgY29udGVudC4NCj4gDQo+ IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdnLWpz b24tbWVyZ2UtcGF0Y2gvDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBz YXdnLWpzb24tbWVyZ2UtcGF0Y2gtMDQNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tbWVyZ2UtcGF0Y2gtMDQNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5n IGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== From nobody Sat Jul 5 13:26: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 6DEFA1B2829 for ; Sat, 5 Jul 2014 13:26:05 -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 FfTax9VC_rol for ; Sat, 5 Jul 2014 13:26:04 -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 AC2591B282C for ; Sat, 5 Jul 2014 13:26:03 -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 s65KPwJS028227; Sat, 5 Jul 2014 22:25:58 +0200 (CEST) Received: from [192.168.217.106] (p54892E19.dip0.t-ipconnect.de [84.137.46.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0CC19C3; Sat, 5 Jul 2014 22:25:57 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> Date: Sat, 5 Jul 2014 22:25:58 +0200 X-Mao-Original-Outgoing-Id: 426284758.748996-6e040c1b5cc6dc9ec97164edab1e65f2 Content-Transfer-Encoding: quoted-printable Message-Id: <3C04BB73-CF1A-490A-9C89-13B4210325A2@tzi.org> References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GtrDcahsS2WDLPpmdFhFVKniYgI Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 05 Jul 2014 20:26:05 -0000 On 05 Jul 2014, at 15:37, Manger, James = wrote: > +1 >=20 > Pseudo code works well for describing the merge process. >=20 > The only remaining non-editorial change required is to remove the = following sentence from section 1 "Introduction": >=20 > A JSON merge patch document can only be a JSON array or a JSON > object. >=20 > The pseudo code does not implement this restriction. Two of the test = cases in appendix A violate this restriction. Correct, With the new stance on this in RFC 7159, it would also be a = rather undesirable restriction. I agree with your editorial points (except that I don=92t have an = opinion about contacts in media type registrations). Other editorial points: =97 Please make use of the errata to RFC 2119 (add =93NOT RECOMMENDED=94).= [This really should be in IDNITS=85] =97 s/execute the following function/realize the effect of the following = function/ We are not constraining implementations here. [The MUST in section 2 is above my threshold for gratuitous MUSTs as = well.] =97 s/Section 5 [RFC5789]/Section 5 of [RFC5789]/ (and similarly s/Section 8 [RFC7159]/Section 8 of [RFC7159]/) =97 please left-align the headings in Annex A (this makes the examples = easier to process automatically, see = https://gist.github.com/cabo/7888768). I=92m not entirely sure that RFC5789 is really a normative reference, as = "The merge patch format is primarily intended for use with the HTTP = PATCH method=94 and might very well used outside it. Apart from the one remnant sentence and the editorial points, this is = ready to ship. Gr=FC=DFe, Carsten From nobody Sat Jul 5 21:40: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 83EF51A019B for ; Sat, 5 Jul 2014 21:40:27 -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 RWWnSMk5DCY5 for ; Sat, 5 Jul 2014 21:40:26 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C051A019A for ; Sat, 5 Jul 2014 21:40:25 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so2979127wgh.35 for ; Sat, 05 Jul 2014 21:40:24 -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=g+aStvGCdM9yiJy0LoX3mvyWZVSG9f0ZH55bj+F/v1I=; b=ajYujGghqZjz7+wCOQVZO4mUmrRoMLt33wo6dCK0Lzy8x5a+i9JSiuHwXJSdJeC/f5 5fURmq6harq7tWstaE+ltUCXbRVoqBZQRMRCFJg1cKp9sz96aBnUZqQR4Tx+KYrWzdNk PQ5MIeyKvFYGKjZAsY7bG1903rwB9pM8PtzEVLBajgLqRCcwqnZwhbikhX9u7VHS4fdH dtXgJUOZNxBYioaYEtg0wZZbbqlmknbPS6ZFyeh3TTFuZqcuIkeGBOo2fVQZQlwV/Hjt Mq23jSevbCeYQs2vPpXob/kEdBd5ikdN7y15x6ZyuZikJv0UCxwKKz7TDjdI0pmxfYhn ZKLA== MIME-Version: 1.0 X-Received: by 10.194.90.201 with SMTP id by9mr23642123wjb.94.1404621624277; Sat, 05 Jul 2014 21:40:24 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Sat, 5 Jul 2014 21:40:24 -0700 (PDT) In-Reply-To: <3C04BB73-CF1A-490A-9C89-13B4210325A2@tzi.org> References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> <3C04BB73-CF1A-490A-9C89-13B4210325A2@tzi.org> Date: Sat, 5 Jul 2014 21:40:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7bd91482f57f4e04fd7ef4b5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3KsbB2HQqrqczDKnhPyIChLi3sw Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 06 Jul 2014 04:40:27 -0000 --047d7bd91482f57f4e04fd7ef4b5 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 5, 2014 at 1:25 PM, Carsten Bormann wrote: > > Apart from the one remnant sentence and the editorial points, this is > ready to ship. > > I'm inclined to wait until these can be handled in a revision (which will have to wait until the embargo is lifted in Toronto) before sending it to Barry, but if people (including Barry) are OK with these being handled as part of IETF Last Call instead, then I'm happy to send it sooner. Opinions? -MSK --047d7bd91482f57f4e04fd7ef4b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 5, 2014 at 1:25 PM, Carsten Bormann <cabo@tzi.org= > wrote:

Apart from the one remnant sentence and the editorial points, this is ready= to ship.


I'm inclined to wait until these c= an be handled in a revision (which will have to wait until the embargo is l= ifted in Toronto) before sending it to Barry, but if people (including Barr= y) are OK with these being handled as part of IETF Last Call instead, then = I'm happy to send it sooner.=C2=A0 Opinions?

-MSK
--047d7bd91482f57f4e04fd7ef4b5-- From nobody Sat Jul 5 21:43: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 790451A019D for ; Sat, 5 Jul 2014 21:43:29 -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 ZE4Z_I7Yvp8Y for ; Sat, 5 Jul 2014 21:43:28 -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 EBF5E1A019A for ; Sat, 5 Jul 2014 21:43:27 -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 s664hO3i016382; Sun, 6 Jul 2014 06:43:24 +0200 (CEST) Received: from [192.168.217.145] (p54892E19.dip0.t-ipconnect.de [84.137.46.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C69369E2; Sun, 6 Jul 2014 06:43:23 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sun, 6 Jul 2014 06:43:22 +0200 X-Mao-Original-Outgoing-Id: 426314602.44453-d195db535856d4dc08d5629ca817dbb9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> <3C04BB73-CF1A-490A-9C89-13B4210325A2@tzi.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ymm0EqW5SCNGYBoQUnO_aCDXRUA Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 06 Jul 2014 04:43:29 -0000 There is an AD override for the embargo. I have no idea how much of a waste of time it is for everyone involved, = but this strikes me as a good use of the concept. Gr=FC=DFe, Carsten On 06 Jul 2014, at 06:40, Murray S. Kucherawy = wrote: > On Sat, Jul 5, 2014 at 1:25 PM, Carsten Bormann wrote: >=20 > Apart from the one remnant sentence and the editorial points, this is = ready to ship. >=20 >=20 > I'm inclined to wait until these can be handled in a revision (which = will have to wait until the embargo is lifted in Toronto) before sending = it to Barry, but if people (including Barry) are OK with these being = handled as part of IETF Last Call instead, then I'm happy to send it = sooner. Opinions? >=20 > -MSK=20 From nobody Sun Jul 6 06:51: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 2CABC1A0305 for ; Sun, 6 Jul 2014 06:51:21 -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 T0J2X7wFQ_AX for ; Sun, 6 Jul 2014 06:51:20 -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 82F761A02FC for ; Sun, 6 Jul 2014 06:51:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s66DpGOW037512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 Jul 2014 06:51:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] 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.6\)) From: Paul Hoffman In-Reply-To: Date: Sun, 6 Jul 2014 06:51:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140704184445.14784.76271.idtracker@ietfa.amsl.com> <2AF6C659-63C0-4956-A299-E07D1D15D4F4@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1154991F2C1@WSMSG3153V.srv.dir.telstra.com> <3C04BB73-CF1A-490A-9C89-13B4210325A2@tzi.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jDyDF6JxCtJlD34-wJ3gd5nQUZg Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-json-merge-patch-04: now with a new processing model 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, 06 Jul 2014 13:51:21 -0000 We are in no rush for this document. I will include the changes that = come in the next few weeks, issue a new draft on the 21st, give people a = few days to be sure the changes are OK (since Barry will be too busy = with the meeting anyway), and then ask Murray to move it to Barry. --Paul Hoffman= From nobody Sun Jul 6 07:51: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 BB0A21A0337; Sun, 6 Jul 2014 07:51:05 -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 YGiEEL7tiFPy; Sun, 6 Jul 2014 07:51:04 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F113D1A0336; Sun, 6 Jul 2014 07:51:03 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id sa20so3134111veb.10 for ; Sun, 06 Jul 2014 07:51:03 -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=lP8Dxbs6uloptR/7wfqrwoak75P5z167YGZikqXkRMc=; b=OS07mb1UdESuZwlcRIaLq5Xn9qG/yX4xd82Js+JWn3eb8bIxvOacDe2OoeQlZCiA6l yC5S8vJc9mV6t6v/usaIb3uerK4JC8JZZECXltkCbuJgZ34hf9TsCt0NA1FadCFwa7rq l7CwT6GuuexcDT/QWEwiAjpR2vX3tRboeHHH0BwAfGmNKWVdutMHo2HMruA+JKh5nxkM FqYQK2WytpkajC5H9G+Sq2+/0yL1JKgrE79NGCoVzkkjzj5aXHOOdhL2rE9MFNEWAjQw nOKqrIyD/HXV/0PlVqgOV8mQZkdQ/pJyTaq/QeHbXw95sEyNnZ5fBHBgUj+iuqoyyJVf rQQg== MIME-Version: 1.0 X-Received: by 10.58.210.97 with SMTP id mt1mr3417782vec.42.1404658262916; Sun, 06 Jul 2014 07:51:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Sun, 6 Jul 2014 07:51:02 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> Date: Sun, 6 Jul 2014 10:51:02 -0400 X-Google-Sender-Auth: 6qs-D-NddRBAzpqLlctTiEo4rCA Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gcUDzedeYK_5-hUe--nbuNCfpl8 Cc: IESG Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 06 Jul 2014 14:51:05 -0000 >> There isn't any mention of a "IANA timezone database" in that BCP. > > Indeed; I changed "IANA Time Zone Database" and "IANA timezone > database" to "Time Zone Database" in version -03. Thanks. Further, in response to comments from the list, I've changed all instances of "timezone" in the charter to "time zone" (in -04). I've asked the Secretariat to change it in the working group name: I can't change that bit. I'm happy to see that the spelling of "time zone" was the only flaw in the proposed charter. Barry From nobody Sun Jul 6 08:20: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 B83681A037A for ; Sun, 6 Jul 2014 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 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_48=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 T_Ang40t5ONZ for ; Sun, 6 Jul 2014 08:20:48 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1176B1A0377 for ; Sun, 6 Jul 2014 08:20:47 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so3012268vcb.15 for ; Sun, 06 Jul 2014 08:20: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=iZXcw2JB7v0i8FYA5qFSZ3zac55vgQdylq9BkjBGPe4=; b=uwn1ZypLOQ7Tuxav/hKuh0TdcApZwQ0HiG+C3uSq07SvALHxAUDimm3py5ByT7uLNG SJomjPrVh09zxE6Pc720MzE1nG94NXtcNOaOOvI0f58Lpzs2Rfv3k3UIL1RUIjhuA+SO TECRubyZIJgYQSpgmRycHXZbNkSAh3bwj5E+lbsuulmckZQcg922x27Y8UQGKa3+S72h npk2A01bgFeqBLZFi/qjNDyd4I3T5iwaE1EdkHMA922MZRX88IkBhfbw6pfpdMmNGywB OL5Rh5qMcyJ7EcOdxCTcpANRr31Ij7/8k1DuVOOze5SOokTNesVNUOkLTNeul5hu2WdF 60Xw== MIME-Version: 1.0 X-Received: by 10.220.15.8 with SMTP id i8mr1894456vca.45.1404660047091; Sun, 06 Jul 2014 08:20:47 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Sun, 6 Jul 2014 08:20:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Jul 2014 11:20:47 -0400 X-Google-Sender-Auth: LbeD3Pae0x_drOULp4Ibb4W_L7E Message-ID: From: Barry Leiba To: Neng Geng Huang Content-Type: multipart/alternative; boundary=001a11c3e09e231e4604fd87e78e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kOoM9oPgYDbyxXGzqoOwaPc6dAA Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Two new Internet Drafts (Independent Submissions) 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, 06 Jul 2014 15:20:50 -0000 --001a11c3e09e231e4604fd87e78e Content-Type: text/plain; charset=UTF-8 App Area folks: The Independent Stream Editor really needs comments on these as part of his decision to publish them. The primary question is whether what's proposed is in conflict with IETF work. Please have a look, and comment. Barry On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang wrote: > Hello, everybody: > > I have submitted two revised Internet Drafts as Independent Submissions. > > https://datatracker.ietf.org/doc/draft-huangng-utid/ > https://datatracker.ietf.org/doc/draft-huangng-idtp/ > > Here is a brief introduction to the concepts of UTID and IDTP and discuss > their use through three small examples, showing the potential to construct > a new kind of application architecture for the Internet of Things. > > UTID is a unique identifier for a physical thing or a virtual thing in the > world, which consists of three components with the following syntax: > > Id~catalog$dns > > It is a character-based identifier, where dns is a domain name of > organization who named the thing, catalog is used by the organization to > classify the thing, and id is unique in the scope of dns and catalog. > Examples are 125.product~db$com1.test, ~db$com1.test, > 125.product~$com1.test, and ~$com1.test. > > IDTP is a communication protocol to tracing messages of things identified > by UTIDs, which adapt request/response model and like a hybrid of HTTP and > Web Service but using JSON data format rather than XML format. It is > characterized by using UTID rather than URL to indicate the destination > address and using build-in forward mechanism to trace the messages of > UTIDs. The forward rules are UTID suffix match (called *tracing rule* in > this paper) and namespace match (called *tracing track* in this paper). > The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web > Service, or local handling without forwarding. > > The first example is tracing of products message. A company (com1.test) > produced a product and then sold it to another company (com2.test), where > UTID is used to identify the product and IDTP is used to trace the message > of the product. > > Fig. 1 Tracing reference between two databases (visit > http://www.utid.org/utid/NewArchitecture.html to see the pictures) > > A record was inserted into database of company com1.test with empty value > of tracing key when a product was produced by company com1.test and marked > as 125.product~db$com1.test, which may be used to trace to the record by > IDTP in the company com1.test (Fig. 1). > > A record was inserted into database of company com2.test when the product > was purchased by company com2.test and re-marked as > 312.purchase~db$com2.test, whose message was send back to company com1.test > by the following IDTP request: > > idtp:0.9/1 > > utid:125.product~db$com1.test > > ns:u.iot.db > > name:UtidEcho > > len:39 > > > > {"refUtid":"312.purchase~db$com2.test"} > > This request was forwarded to the database of company com1.test by the > tracing mechanism of IDTP using the UTID carried by the request as > destination address and was used to update the field of tracing key of the > record. Then a response was returned back: > > idtp:0.9/1 > > code:200 OK > > len:17 > > > > {"msg":"success"} > > Therefore, tracing references between the two databases were established, > just like a foreign key reference in a relational database system. The > difference is that the tracing reference is build between two independent > databases and any client application may trace any UTIDs through tracing > references by IDTP protocol. > > The second example is tracing different properties of same UTID. A company > (com1.test) has a temperature sensor, which sends temperature value to a > database server every 10 minutes. The company has an internal network, > which consists of a database server that saves historical temperature > value, a tracing bridge that connect to the temperature sensor, and a > tracing gateway that forwards request based on tracing rule and tracing > track. A tracing bridge may be a system with very low capacity of > computation, such as a single chip microcomputer with Ethernet interface, > which acts as a connection node between IDTP node and non-IDTP node (Fig. > 2). > > The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded to > the tracing bridge by the tracing gateway if the namespace (field ns in the > request) is u.iot.sensor when a user sent a request for real time > temperature value. The tracing bridge got temperature value from the sensor > and returned the value to the requester. A request with the same UTID was > forwarded to the database server by the tracing gateway if the namespace is > u.iot.db when a user sent a request for historical temperature value. The > database server retrieved temperature values from database and returned the > value to the requester. > > Fig. 2 Tracing to different node by namespace with same UTID (visit > http://www.utid.org/utid/NewArchitecture.html to see the pictures) > > The tracing rule and tracing track on the tracing gateway is listed in > Tab. 1 and Tab. 2. > > Tab. 1 Tracing rule on the tracing gateway > > *utid suffix* > > *Rule* > > $com1.test > > ruel1 > > Tab. 2 Tracing track on the tracing gateway > > *Rule* > > *Namespace* > > *Protocol* > > *Address* > > *Port* > > rule1 > > u.iot.db > > tcp > > db.com1.test > > 8091 > > rule1 > > u.iot.sensor > > tcp > > bridge.com1.test > > 8092 > > > > The third example is for local request and remote request. A database > server of a company (com1.test) has various kinks of tracing keys, which > reference to local database or remote databases. A request may be handled > locally or forwarded to remote servers. In this case, the server may deal > with this situation easily by set up settings as listed in Tab. 3 and Tab. > 4. There is no tracing rule for dns other than itself dns because that IDTP > will forward all unmatched requests to TCP port 25604 (default port number > for IDTP, registered in IANA) of the server indicated by the dns of the > UTID carried by a request. > > Tab. 3 Tracing rule on the database server > > *utid suffix* > > *Rule* > > $com1.test > > ruel1 > > Tab. 4 Tracing track on the database server > > *Rule* > > *Namespace* > > *Protocol* > > *Address* > > *Port* > > rule1 > > * > > local > > > > > > > > It is encouraged to use IDTP request for local calls because of its high > efficiency to form a unified API both for local calls and remote calls. > This mechanism will help designers to develop highly interoperable > application. > > Despite of the differences between IDTP and Web Service, IDTP is > conditional compatible with Web Service, adapts WSDL as data format > definition of request and response, and adapt UDDI for the discovery of > IDTP service. > > In summary, UTID and IDTP suggested a new kind of application architecture > for the Internet of Things that is universal, simple, low cost, and high > efficiency. The architecture simplifies the design of application > framework, promote the efficiency of system development, and increase the > interoperability of application system. > > > Best regards, > > > Huang > > -- > ------------------------------ > Mr. Huang Neng Geng > ------------------------------ > Associate Professor > School of the Internet of Things > Wuxi Institute of Technology > Wuxi, Jiangsu, China, 214121 > Mobile: 86-13921501950 > email: huangng@gmail.com > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a11c3e09e231e4604fd87e78e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
App Area folks:
The Independent Stream Editor really n= eeds comments on these as part of his decision to publish them. =C2=A0The p= rimary question is whether what's proposed is in conflict with IETF wor= k. =C2=A0Please have a look, and comment.

Barry


On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang <= huangng@gmail.com> wrote:
Hello, everybody:
I have submitted two revised Internet Drafts as Independ= ent Submissions.


Here is a brief introduction to the c= oncepts of UTID and IDTP and discuss their use through three small examples= , showing the potential to construct a new kind of application architecture= for the Internet of Things.

UTID is a unique identifier for a physical thing o= r a virtual thing in the world, which consists of three components with the following syntax:

Id~catalog$dns

It is a character-based identifier,= where dns is a domain name of organization who named the thing, catalog is used by the organization to classify the thing, and id is unique in the scope of dns an= d catalog. Examples are 125.product~db$com1.test, ~db$com1.test, 125.product~= $com1.test, and ~$com1.test.

IDTP is a communication protocol to= tracing messages of things identified by UTIDs, which adapt request/response model and like a hybrid of HTTP and Web Service but using JSON data format rather than XML format. It is characterized by using UTID rather than URL to indicate the destination address and using build-in forward mechanism to trace the messa= ges of UTIDs. The forward rules are UTID suffix match (called tracing rul= e in this paper) and namespace match (called tracing track in this pape= r). The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web Servi= ce, or local handling without forwarding.

The first example is tracing of pro= ducts message. A company (com1.test) produced a product and then sold it to another company (com2.test), where UTID is used to identify the product and IDTP is used to trace the message of the product.

Fig. 1 Tracing reference be= tween two databases=C2=A0=C2=A0(visit htt= p://www.utid.org/utid/NewArchitecture.html=C2=A0to see the pictures)

A record was inserted into database= of company com1.test with empty value of tracing key when a product was produced by company com1.test and marked as 125.product~db$com1.test, which may be used= to trace to the record by IDTP in the company com1.test (Fig. 1).

A record was inserted into database= of company com2.test when the product was purchased by company com2.test and re-marked= as 312.purchase~db$com2.test, whose message was send back to company com1.test= by the following IDTP request:

idtp:0.9/1

utid:125.product~db$com1.test

ns:u.iot.db

name:UtidEcho

len:39

=C2=A0

{"refUtid":"312.purchase~db$com2.= test"}

This request was forwarded to the d= atabase of company com1.test by the tracing mechanism of IDTP using the UTID carried by the request as destination address and was used to update the field of tracing = key of the record. Then a response was returned back:

idtp:0.9/1

code:200 OK

len:17

=C2=A0

{"msg":"success"}

Therefore, tracing references betwe= en the two databases were established, just like a foreign key reference in a relational databas= e system. The difference is that the tracing reference is build between two independent databases and any client application may trace any UTIDs throug= h tracing references by IDTP protocol.

The second example is tracing diffe= rent properties of same UTID. A company (com1.test) has a temperature sensor, which sends temperature value to a database server every 10 minutes. The company has an internal network, which consists of a database server that saves historical temperature value, a tracing bridge that connect to the temperature sensor,= and a tracing gateway that forwards request based on tracing rule and tracing t= rack. A tracing bridge may be a system with very low capacity of computation, suc= h as a single chip microcomputer with Ethernet interface, which acts as a connec= tion node between IDTP node and non-IDTP node (Fig. 2).

The sensor was marked as 56.loc1.t~= s$com1.test. A request was forwarded to the tracing bridge by the tracing gateway if the namespace (field ns in the request) is u.iot.sensor when a user sent a requ= est for real time temperature value. The tracing bridge got temperature value f= rom the sensor and returned the value to the requester. A request with the same= UTID was forwarded to the database server by the tracing gateway if the namespac= e is u.iot.db when a user sent a request for historical temperature value. The d= atabase server retrieved temperature values from database and returned the value to= the requester.

Fig. 2 Tracing to different= node by namespace with same UTID (visit http://www.utid.org/utid/NewArchitecture.html=C2=A0to= see the pictures)

The tracing rule and tracing track = on the tracing gateway is listed in Tab. 1 and Tab. 2.

Tab. 1 Tracing rule on the = tracing gateway

utid suffix

Rule

$com1= .test

ruel1=

Tab. 2 Tracing track on the= tracing gateway

Rule

Namespace

Protocol

Address

Port

rule1=

u.iot= .db

tcp

db.co= m1.test

8091<= /span>

rule1=

u.iot= .sensor

tcp

bridg= e.com1.test

8092<= /span>

=C2= =A0

The third example is for local requ= est and remote request. A database server of a company (com1.test) has various kinks of tracing keys, which reference to local database or remote databases. A requ= est may be handled locally or forwarded to remote servers. In this case, the se= rver may deal with this situation easily by set up settings as listed in Tab. 3 = and Tab. 4. There is no tracing rule for dns other than itself dns because that IDTP will forward all unmatched requests to TCP port 25604 (default port nu= mber for IDTP, registered in IANA) of the server indicated by the dns of the UTI= D carried by a request.

Tab. 3 Tracing rule on the = database server

utid suffix

Rule

$com1= .test

ruel1=

Tab. 4 Tracing track on the= database server

Rule

Namespace

Protocol

Address

Port

rule1=

*

local=

=C2= =A0

=C2= =A0

=C2=A0

It is encouraged to use IDTP reques= t for local calls because of its high efficiency to form a unified API both for local calls and remot= e calls. This mechanism will help designers to develop highly interoperable a= pplication.

Despite of the differences between = IDTP and Web Service, IDTP is conditional compatible with Web Service, adapts WSDL as data format definition of request and response, and adapt UDDI for the discovery of IDT= P service.

In summary, UTID and IDTP suggested= a new kind of application architecture for the Internet of Things that is universal, simple, low cost= , and high efficiency. The architecture simplifies the design of application fram= ework, promote the efficiency of system development, and increase the interoperabi= lity of application system.


<= /p>

Be= st regards,


Huang


-= -
------------------------------
Mr. Huang Neng Gen= g
------------------------------
Associate Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, J= iangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com


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


--001a11c3e09e231e4604fd87e78e-- From nobody Sun Jul 6 09:06: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 B720E1A0454 for ; Sun, 6 Jul 2014 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 dZ4sALpdQDtf for ; Sun, 6 Jul 2014 09:06:27 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194D21A044B for ; Sun, 6 Jul 2014 09:06:26 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id la4so3123617vcb.0 for ; Sun, 06 Jul 2014 09:06:25 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B6ACXNbDskGjF8Z6iDKc944W0ShfItoQYLQ5++Iya8E=; b=IPXvzTUiCvb30e+4GutVqOfL8AbgtlKyiY32Vk64rEpRDkp4cb+H3yquXwOgDQHNsM amV1mh5MnGd84WtNRwrW9LPc7tUFV7/PN64gQjjWu9QLv/Nb4ineKac6rfGOGPltFG3O T5DsCAnheEJnEQJiOTE6RZzWkqImM0mCMUBoBRGlz7hK3x2Jn2VX/0GCmzsfvLBXqi0x 07PpVFVkesAsNuJRSlFln4yMCG9rJDzoppIcyP+joTitPrN8/vM6M8FF31Yo5MgS1TsU Kyr01aCLPDakWS5osEzdINJkHXkR0qmTsRTDtEyLhWov5lhuxE8+A7r1wkMZJB0cDuF1 oQuA== X-Gm-Message-State: ALoCoQlrEa4IlF0AQ2xhgaOs1GJTYQ1EdVfT50xB0m+VYpLTZ6XEP5/nSHvUTuM7D/By06gmwifo MIME-Version: 1.0 X-Received: by 10.220.252.198 with SMTP id mx6mr5633977vcb.15.1404662784885; Sun, 06 Jul 2014 09:06:24 -0700 (PDT) Received: by 10.221.49.199 with HTTP; Sun, 6 Jul 2014 09:06:24 -0700 (PDT) X-Originating-IP: [24.84.235.32] Received: by 10.221.49.199 with HTTP; Sun, 6 Jul 2014 09:06:24 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Jul 2014 09:06:24 -0700 Message-ID: From: Tim Bray To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013a044a529cdf04fd888a09 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bq_ALyU5vCuTx0f_RQROhJlv76g Cc: Neng Geng Huang , apps-discuss@ietf.org Subject: Re: [apps-discuss] Two new Internet Drafts (Independent Submissions) 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, 06 Jul 2014 16:06:29 -0000 --089e013a044a529cdf04fd888a09 Content-Type: text/plain; charset=UTF-8 My primary question would be "are there implementations, and what useful things do they do?" On Jul 6, 2014 8:20 AM, "Barry Leiba" wrote: > App Area folks: > The Independent Stream Editor really needs comments on these as part of > his decision to publish them. The primary question is whether what's > proposed is in conflict with IETF work. Please have a look, and comment. > > Barry > > > On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang > wrote: > >> Hello, everybody: >> >> I have submitted two revised Internet Drafts as Independent Submissions. >> >> https://datatracker.ietf.org/doc/draft-huangng-utid/ >> https://datatracker.ietf.org/doc/draft-huangng-idtp/ >> >> Here is a brief introduction to the concepts of UTID and IDTP and >> discuss their use through three small examples, showing the potential to >> construct a new kind of application architecture for the Internet of Things. >> >> UTID is a unique identifier for a physical thing or a virtual thing in >> the world, which consists of three components with the following syntax: >> >> Id~catalog$dns >> >> It is a character-based identifier, where dns is a domain name of >> organization who named the thing, catalog is used by the organization to >> classify the thing, and id is unique in the scope of dns and catalog. >> Examples are 125.product~db$com1.test, ~db$com1.test, >> 125.product~$com1.test, and ~$com1.test. >> >> IDTP is a communication protocol to tracing messages of things identified >> by UTIDs, which adapt request/response model and like a hybrid of HTTP and >> Web Service but using JSON data format rather than XML format. It is >> characterized by using UTID rather than URL to indicate the destination >> address and using build-in forward mechanism to trace the messages of >> UTIDs. The forward rules are UTID suffix match (called *tracing rule* in >> this paper) and namespace match (called *tracing track* in this paper). >> The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web >> Service, or local handling without forwarding. >> >> The first example is tracing of products message. A company (com1.test) >> produced a product and then sold it to another company (com2.test), where >> UTID is used to identify the product and IDTP is used to trace the message >> of the product. >> >> Fig. 1 Tracing reference between two databases (visit >> http://www.utid.org/utid/NewArchitecture.html to see the pictures) >> >> A record was inserted into database of company com1.test with empty value >> of tracing key when a product was produced by company com1.test and marked >> as 125.product~db$com1.test, which may be used to trace to the record by >> IDTP in the company com1.test (Fig. 1). >> >> A record was inserted into database of company com2.test when the product >> was purchased by company com2.test and re-marked as >> 312.purchase~db$com2.test, whose message was send back to company com1.test >> by the following IDTP request: >> >> idtp:0.9/1 >> >> utid:125.product~db$com1.test >> >> ns:u.iot.db >> >> name:UtidEcho >> >> len:39 >> >> >> >> {"refUtid":"312.purchase~db$com2.test"} >> >> This request was forwarded to the database of company com1.test by the >> tracing mechanism of IDTP using the UTID carried by the request as >> destination address and was used to update the field of tracing key of the >> record. Then a response was returned back: >> >> idtp:0.9/1 >> >> code:200 OK >> >> len:17 >> >> >> >> {"msg":"success"} >> >> Therefore, tracing references between the two databases were established, >> just like a foreign key reference in a relational database system. The >> difference is that the tracing reference is build between two independent >> databases and any client application may trace any UTIDs through tracing >> references by IDTP protocol. >> >> The second example is tracing different properties of same UTID. A >> company (com1.test) has a temperature sensor, which sends temperature value >> to a database server every 10 minutes. The company has an internal network, >> which consists of a database server that saves historical temperature >> value, a tracing bridge that connect to the temperature sensor, and a >> tracing gateway that forwards request based on tracing rule and tracing >> track. A tracing bridge may be a system with very low capacity of >> computation, such as a single chip microcomputer with Ethernet interface, >> which acts as a connection node between IDTP node and non-IDTP node (Fig. >> 2). >> >> The sensor was marked as 56.loc1.t~s$com1.test. A request was forwarded >> to the tracing bridge by the tracing gateway if the namespace (field ns in >> the request) is u.iot.sensor when a user sent a request for real time >> temperature value. The tracing bridge got temperature value from the sensor >> and returned the value to the requester. A request with the same UTID was >> forwarded to the database server by the tracing gateway if the namespace is >> u.iot.db when a user sent a request for historical temperature value. The >> database server retrieved temperature values from database and returned the >> value to the requester. >> >> Fig. 2 Tracing to different node by namespace with same UTID (visit >> http://www.utid.org/utid/NewArchitecture.html to see the pictures) >> >> The tracing rule and tracing track on the tracing gateway is listed in >> Tab. 1 and Tab. 2. >> >> Tab. 1 Tracing rule on the tracing gateway >> >> *utid suffix* >> >> *Rule* >> >> $com1.test >> >> ruel1 >> >> Tab. 2 Tracing track on the tracing gateway >> >> *Rule* >> >> *Namespace* >> >> *Protocol* >> >> *Address* >> >> *Port* >> >> rule1 >> >> u.iot.db >> >> tcp >> >> db.com1.test >> >> 8091 >> >> rule1 >> >> u.iot.sensor >> >> tcp >> >> bridge.com1.test >> >> 8092 >> >> >> >> The third example is for local request and remote request. A database >> server of a company (com1.test) has various kinks of tracing keys, which >> reference to local database or remote databases. A request may be handled >> locally or forwarded to remote servers. In this case, the server may deal >> with this situation easily by set up settings as listed in Tab. 3 and Tab. >> 4. There is no tracing rule for dns other than itself dns because that IDTP >> will forward all unmatched requests to TCP port 25604 (default port number >> for IDTP, registered in IANA) of the server indicated by the dns of the >> UTID carried by a request. >> >> Tab. 3 Tracing rule on the database server >> >> *utid suffix* >> >> *Rule* >> >> $com1.test >> >> ruel1 >> >> Tab. 4 Tracing track on the database server >> >> *Rule* >> >> *Namespace* >> >> *Protocol* >> >> *Address* >> >> *Port* >> >> rule1 >> >> * >> >> local >> >> >> >> >> >> >> >> It is encouraged to use IDTP request for local calls because of its high >> efficiency to form a unified API both for local calls and remote calls. >> This mechanism will help designers to develop highly interoperable >> application. >> >> Despite of the differences between IDTP and Web Service, IDTP is >> conditional compatible with Web Service, adapts WSDL as data format >> definition of request and response, and adapt UDDI for the discovery of >> IDTP service. >> >> In summary, UTID and IDTP suggested a new kind of application >> architecture for the Internet of Things that is universal, simple, low >> cost, and high efficiency. The architecture simplifies the design of >> application framework, promote the efficiency of system development, and >> increase the interoperability of application system. >> >> >> Best regards, >> >> >> Huang >> >> -- >> ------------------------------ >> Mr. Huang Neng Geng >> ------------------------------ >> Associate Professor >> School of the Internet of Things >> Wuxi Institute of Technology >> Wuxi, Jiangsu, China, 214121 >> Mobile: 86-13921501950 >> email: huangng@gmail.com >> >> >> _______________________________________________ >> 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 > > --089e013a044a529cdf04fd888a09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

My primary question would be "are there implementations= , and what useful things do they do?"

On Jul 6, 2014 8:20 AM, "Barry Leiba" = <barryleiba@computer.org&= gt; wrote:
App Area folks:
The Independent Stream Editor really n= eeds comments on these as part of his decision to publish them. =C2=A0The p= rimary question is whether what's proposed is in conflict with IETF wor= k. =C2=A0Please have a look, and comment.

Barry


On Fri, Jul 4, 2014 at 11:24 AM, Neng Geng Huang <= huangng@gmail.com> wrote:
Hello, everybody:
I have submitted two revised Internet Drafts as Independ= ent Submissions.


Here is a brief introduction to the c= oncepts of UTID and IDTP and discuss their use through three small examples= , showing the potential to construct a new kind of application architecture= for the Internet of Things.

UTID is a unique identifier for a physical thing o= r a virtual thing in the world, which consists of three components with the following syntax:

Id~catalog$dns

It is a character-based identifier,= where dns is a domain name of organization who named the thing, catalog is used by the organization to classify the thing, and id is unique in the scope of dns an= d catalog. Examples are 125.product~db$com1.test, ~db$com1.test, 125.product~= $com1.test, and ~$com1.test.

IDTP is a communication protocol to= tracing messages of things identified by UTIDs, which adapt request/response model and like a hybrid of HTTP and Web Service but using JSON data format rather than XML format. It is characterized by using UTID rather than URL to indicate the destination address and using build-in forward mechanism to trace the messa= ges of UTIDs. The forward rules are UTID suffix match (called tracing rul= e in this paper) and namespace match (called tracing track in this pape= r). The underlying protocol of IDTP may be TCP, UDP, UDP multicast, HTTP, Web Servi= ce, or local handling without forwarding.

The first example is tracing of pro= ducts message. A company (com1.test) produced a product and then sold it to another company (com2.test), where UTID is used to identify the product and IDTP is used to trace the message of the product.

Fig. 1 Tracing reference be= tween two databases=C2=A0=C2=A0(visit htt= p://www.utid.org/utid/NewArchitecture.html=C2=A0to see the pictures)

A record was inserted into database= of company com1.test with empty value of tracing key when a product was produced by company com1.test and marked as 125.product~db$com1.test, which may be used= to trace to the record by IDTP in the company com1.test (Fig. 1).

A record was inserted into database= of company com2.test when the product was purchased by company com2.test and re-marked= as 312.purchase~db$com2.test, whose message was send back to company com1.test= by the following IDTP request:

idtp:0.9/1

utid:125.product~db$com1.test

ns:u.iot.db

name:UtidEcho

len:39

=C2=A0

{"refUtid":"312.purchase~db$com2.= test"}

This request was forwarded to the d= atabase of company com1.test by the tracing mechanism of IDTP using the UTID carried by the request as destination address and was used to update the field of tracing = key of the record. Then a response was returned back:

idtp:0.9/1

code:200 OK

len:17

=C2=A0

{"msg":"success"}

Therefore, tracing references betwe= en the two databases were established, just like a foreign key reference in a relational databas= e system. The difference is that the tracing reference is build between two independent databases and any client application may trace any UTIDs throug= h tracing references by IDTP protocol.

The second example is tracing diffe= rent properties of same UTID. A company (com1.test) has a temperature sensor, which sends temperature value to a database server every 10 minutes. The company has an internal network, which consists of a database server that saves historical temperature value, a tracing bridge that connect to the temperature sensor,= and a tracing gateway that forwards request based on tracing rule and tracing t= rack. A tracing bridge may be a system with very low capacity of computation, suc= h as a single chip microcomputer with Ethernet interface, which acts as a connec= tion node between IDTP node and non-IDTP node (Fig. 2).

The sensor was marked as 56.loc1.t~= s$com1.test. A request was forwarded to the tracing bridge by the tracing gateway if the namespace (field ns in the request) is u.iot.sensor when a user sent a requ= est for real time temperature value. The tracing bridge got temperature value f= rom the sensor and returned the value to the requester. A request with the same= UTID was forwarded to the database server by the tracing gateway if the namespac= e is u.iot.db when a user sent a request for historical temperature value. The d= atabase server retrieved temperature values from database and returned the value to= the requester.

Fig. 2 Tracing to different= node by namespace with same UTID (visit http://www.utid.org/utid/NewArchitecture.html=C2=A0to= see the pictures)

The tracing rule and tracing track = on the tracing gateway is listed in Tab. 1 and Tab. 2.

Tab. 1 Tracing rule on the = tracing gateway

utid suffix

Rule

$com1= .test

ruel1=

Tab. 2 Tracing track on the= tracing gateway

Rule

Namespace

Protocol

Address

Port

rule1=

u.iot= .db

tcp

db.co= m1.test

8091<= /span>

rule1=

u.iot= .sensor

tcp

bridg= e.com1.test

8092<= /span>

=C2= =A0

The third example is for local requ= est and remote request. A database server of a company (com1.test) has various kinks of tracing keys, which reference to local database or remote databases. A requ= est may be handled locally or forwarded to remote servers. In this case, the se= rver may deal with this situation easily by set up settings as listed in Tab. 3 = and Tab. 4. There is no tracing rule for dns other than itself dns because that IDTP will forward all unmatched requests to TCP port 25604 (default port nu= mber for IDTP, registered in IANA) of the server indicated by the dns of the UTI= D carried by a request.

Tab. 3 Tracing rule on the = database server

utid suffix

Rule

$com1= .test

ruel1=

Tab. 4 Tracing track on the= database server

Rule

Namespace

Protocol

Address

Port

rule1=

*

local=

=C2= =A0

=C2= =A0

=C2=A0

It is encouraged to use IDTP reques= t for local calls because of its high efficiency to form a unified API both for local calls and remot= e calls. This mechanism will help designers to develop highly interoperable a= pplication.

Despite of the differences between = IDTP and Web Service, IDTP is conditional compatible with Web Service, adapts WSDL as data format definition of request and response, and adapt UDDI for the discovery of IDT= P service.

In summary, UTID and IDTP suggested= a new kind of application architecture for the Internet of Things that is universal, simple, low cost= , and high efficiency. The architecture simplifies the design of application fram= ework, promote the efficiency of system development, and increase the interoperabi= lity of application system.


<= /p>

Be= st regards,


Huang


--
------------------------------
Mr. Huang Neng Geng
------------------------------
Associate Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, J= iangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.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

--089e013a044a529cdf04fd888a09-- From nobody Sun Jul 6 09:41: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 4A4491A05D1 for ; Sun, 6 Jul 2014 09:41:46 -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_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, 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 UoOvMRQaVrym for ; Sun, 6 Jul 2014 09:41:45 -0700 (PDT) Received: from mail-qa0-x244.google.com (mail-qa0-x244.google.com [IPv6:2607:f8b0:400d:c00::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A3F1A05C0 for ; Sun, 6 Jul 2014 09:41:45 -0700 (PDT) Received: by mail-qa0-f68.google.com with SMTP id v10so1093148qac.11 for ; Sun, 06 Jul 2014 09:41:44 -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=GXDXVi3vDbXhQ/dwM9HIM83xkuRAOQVIWtS28JAyHNY=; b=GMUhjEPYuyHj1gnoR59lxJRgYgWmwSKx3t0/7fMLACEI2ACVVNkPJYwnWNhLgyptae uZa/oR6N6FD5QKtsQtqAwQVjLfbvzgdNwsePhZDEeI3cA/t8ADI+VX4N4pv2daWoFmwx Y9FJg+4zrZQM/BgaNIUFNapEh1SS7jWZ0HZQagIF2/oV6ekolg+7cMxozYAd0KXherrz wEac0G9262bVFRYL5uFJJbv+XLKEMiJZAk77uDMgij7cUcx0fcYnwfvEdzA/1wf5BmMl j47hR7hsUEgfgVIrLh/UBo714ghIQGzAWwbteepIwsiMOT+67dc1S7Fylu5GaKZsHidD ebPQ== MIME-Version: 1.0 X-Received: by 10.140.37.9 with SMTP id q9mr31052172qgq.32.1404664904918; Sun, 06 Jul 2014 09:41:44 -0700 (PDT) Received: by 10.224.180.142 with HTTP; Sun, 6 Jul 2014 09:41:44 -0700 (PDT) Received: by 10.224.180.142 with HTTP; Sun, 6 Jul 2014 09:41:44 -0700 (PDT) Date: Mon, 7 Jul 2014 00:41:44 +0800 Message-ID: From: Bobby Dulay To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a11c1358aafacbc04fd89089f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NuWNdl7l8MUYWr-kdgqQtKHi9Jc Subject: [apps-discuss] true 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, 06 Jul 2014 16:41:46 -0000 --001a11c1358aafacbc04fd89089f Content-Type: text/plain; charset=UTF-8 --001a11c1358aafacbc04fd89089f Content-Type: text/html; charset=UTF-8 --001a11c1358aafacbc04fd89089f-- From nobody Sun Jul 6 14:36: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 26DCF1A0AAD; Sun, 6 Jul 2014 14:36:42 -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 Rg2_FtPqKndw; Sun, 6 Jul 2014 14:36:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9376B1A0601; Sun, 6 Jul 2014 14:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404682600; x=1436218600; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aFMi+4L+6v2K/qFNZEaN8trHdRelQdMBIWSljzJNySs=; b=ZdcRC6VLUm40HB0YGRO7m3/2DX2BU2lYqZNo7W5RP1cI7OkudOB5o8hT eb+fBLwk1RgXUuKoDf3EY6klplteumFJJcE7kpN7II2i2PoME3jqbfP29 19ouAOOh6cLqvgnZwpdYB/mmw1YzgDwpvtPZphaLApQqA63S43J17Q6v6 I=; X-IronPort-AV: E=McAfee;i="5600,1067,7491"; a="139479600" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 06 Jul 2014 14:36:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,613,1400050800"; d="scan'208";a="671074941" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Jul 2014 14:36:40 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 6 Jul 2014 14:36:39 -0700 Message-ID: <53B9C161.4050502@qti.qualcomm.com> Date: Mon, 7 Jul 2014 00:36:33 +0300 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kTgBmRV4mI9R8i49IfyeFAx_vKs Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 06 Jul 2014 21:36:42 -0000 On 7/4/14 4:14 PM, Barry Leiba wrote: > The only thing that the charter leaves in scope with regard to that > happens if we find security issues, while building the distribution > protocol. Perhaps Cyrus could better explain, but: What sort of "security issues", and security issues with *what*, was this referring to? I'm mildly inclined to remove that line from the charter, but I'd like to hear what was being considered. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Jul 6 14:52: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 82F8E1A0AB0 for ; Sun, 6 Jul 2014 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jmPs4amHQ6ib for ; Sun, 6 Jul 2014 14:52:44 -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 537BC1A0AAE for ; Sun, 6 Jul 2014 14:52: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 s66LqepP008981; Sun, 6 Jul 2014 23:52:40 +0200 (CEST) Received: from [192.168.217.106] (p54893088.dip0.t-ipconnect.de [84.137.48.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 87D4DBFC; Sun, 6 Jul 2014 23:52:39 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Sun, 6 Jul 2014 23:52:38 +0200 X-Mao-Original-Outgoing-Id: 426376357.90511-1b28e46d48f79332a62abb9d024d34e0 Content-Transfer-Encoding: quoted-printable Message-Id: <830DA3D5-4D5E-45EB-B4FF-09FDDEF59667@tzi.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MCagQ9vvEPt57ZbQmrSkfvhOh-4 Cc: Neng Geng Huang , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Two new Internet Drafts (Independent Submissions) 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, 06 Jul 2014 21:52:46 -0000 On 06 Jul 2014, at 17:20, Barry Leiba wrote: > https://datatracker.ietf.org/doc/draft-huangng-idtp/ After a cursory check: I do not think this is a complete specification of a protocol, so it is = hard to say anything definite. It seems to be interested in some of the use cases of CoAP, and I wonder = why it doesn=92t discuss its relationship with CoAP, which has been = around since before this work started. The draft does mention HTTP, but = only in a superficial way as in [IDTP] "is similar to HTTP, Web Service, = Java RMI, or CORBA.=94 It says it maps to TCP, UDP, and HTTP, but = doesn=92t say how (it does say it uses port 25604 for TCP, which indeed = has been allocated in 2011). I was hoping to find some answers in the reference implementation, which = has some 7000 lines of Java. There you can find gems such as an XOR =93encryption=94. As the drafts didn't really help me find out about their motivation, I = was interested to find an =93overview.html=94 there that has to say = this: > 1.4 Why a new protocol? >=20 > There are various coding system and communication protocols widely = used in the IOT. The EPC and Web Service are the typical that makes a = great contributes to the development of IOT. However, any technology = inevitably has some disadvantages. For example, EPC is mainly used in = identify products in production process and shipping goods in logistics = and is the best coding system in the context. But in the era of IOT, = after being produced, a product will go through circulation process, = storage process, and consumption process. The same product might need to = be recoded in different process by different company using different = coding system to provide and share the information of the same product = in the different status from different company. For example, no company = would like to identify its fixed assets using EPC system, which is = originally designed for identify products. The problem is that the = communication among these different company and different coding system. = The result is the producer is difficult to trace the outgoing process = and the consumer is difficult to find the information in the circulation = process except the producer. Another example is IP protocol, the key = technology in the Internet. But it could not be applied to a network = consists of sensors that do not have IP address. >=20 > In generally, we need a coding system and a protocol that are more = open, more generalized. This specification provides such an open = solution that is independent to any industry or any context. I gave up there, because I cannot make sense of this. Gr=FC=DFe, Carsten From nobody Sun Jul 6 17:38: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 E6CBD1A0069 for ; Sun, 6 Jul 2014 17:37: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 1jR5auHdDhHU for ; Sun, 6 Jul 2014 17:37:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309AD1A0064 for ; Sun, 6 Jul 2014 17:37:55 -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 s670bmDZ019693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 6 Jul 2014 17:37:51 -0700 Message-ID: <53B9EB81.4020702@dcrocker.net> Date: Sun, 06 Jul 2014 17:36:17 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Bray , Barry Leiba 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]); Sun, 06 Jul 2014 17:37:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YAwWj5ln8aTuKhGhnWwNO4zW5FE Cc: Neng Geng Huang , apps-discuss@ietf.org Subject: Re: [apps-discuss] Two new Internet Drafts (Independent Submissions) 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: Mon, 07 Jul 2014 00:37:59 -0000 On 7/6/2014 9:06 AM, Tim Bray wrote: > My primary question would be "are there implementations, and what useful > things do they do?" > > On Jul 6, 2014 8:20 AM, "Barry Leiba" > wrote: > > App Area folks: > The Independent Stream Editor really needs comments on these as part > of his decision to publish them. The primary question is whether > what's proposed is in conflict with IETF work. Please have a look, > and comment. Tim, et al, The "IETF" has a limited role in commenting on Independent Stream RFC drafts. Barry's query summarized the key point that is /within/ the IETF's purview. We do not get to comment on whether we like a protocol spec or what its deficiencies are. Individually, we might, if we are asked by the Independent Stream Editor. But the question "The IETF" is alloed to ask is much more limited: http://tools.ietf.org/html/rfc5742 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 6 23:29:59 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 997751A0B0D for ; Sun, 6 Jul 2014 23:29:57 -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 dJ8flWW7bF1E for ; Sun, 6 Jul 2014 23:29:56 -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 A34691A0347 for ; Sun, 6 Jul 2014 23:29:56 -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 CF52C32E02B; Mon, 7 Jul 2014 15:29:54 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1a68_4866_49648997_2ff6_41f4_9400_a11770be4462; Mon, 07 Jul 2014 15:29:53 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1EA60BF510; Mon, 7 Jul 2014 15:29:54 +0900 (JST) Message-ID: <53BA3E51.7080308@it.aoyama.ac.jp> Date: Mon, 07 Jul 2014 15:29:37 +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.6.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" , Dave Thaler , Ted Hardie , Tony Hansen References: <20140703225940.1804.1232.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/kwfsRvKqWUW4oJDiQM66HzGaL7Y Subject: Re: [apps-discuss] New Version Notification for draft-ietf-appsawg-uri-scheme-reg-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: Mon, 07 Jul 2014 06:29:57 -0000 On 2014/07/04 12:26, Larry Masinter wrote: > I don't think we're going far enough to simplify the process, to have any hope IANA will be more useful than Wikipedia or search for the scheme, for anything other than pedantic or legal purposes. How successful is Wikipedia or search currently for some of the "long-tail" (i.e. not widely deployed) schemes? > The 'guidelines' are ok, but the process is way too complicated, rate limited, doesn't help wanna-be's implement things compatibly, and doesn't provide enough incentive to register for registration to be near-universally timely. Timely completeness is the requirement to be able to answer questions like "are there any schemes that do X" and the like, and also to know when the 'authoritative' information in the registry has been supplanted surreptitiously. > > I'm leaning toward recommended crowd-source technology-- get permission to give each scheme a page which people can 'Like' or 'Comment'. Crowd-sourcing technology has a lot of advantages. But it also comes with some burdens. What do we do if two people (or more) disagree about the information on a scheme and swap out each other's edits? What do we do against spambots? Please remember that every successful crow-sourcing technology comes with carefully designed management functions that often involve some heavy human work. Wikipedia would be the prime example. > I understand there's a monarchy perspective which would prefer a single "Living Standard" list of platform scheme names rather than a registry. This would have the advantage for content creators of turning a combinatorial testing job into a linear one, which may be why it's popular. Are the two models reconcilable? If all scheme pages are on the same site, or otherwise within "reach", I don't see any fundamental difficulty in updating an overall list in (linear or sublinear) real time. So I think there are no essential differences in terms of computability. > Larry (Duke of Url) Why not "Url of Masinter" (aka Earl of Masinter)? Regards, Martin. From nobody Mon Jul 7 05:59: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 2DB251A0406 for ; Mon, 7 Jul 2014 05:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 LuEKkLsVx3Xu for ; Mon, 7 Jul 2014 05:58:52 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6158F1A0008 for ; Mon, 7 Jul 2014 05:58:52 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id nu7so4557004obb.41 for ; Mon, 07 Jul 2014 05:58:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RNVZDJf3GXP1V7xJWTKk/vzsXt9r70RvCXAVHf+NIqU=; b=eQ4jM0Zawnz8RMSW3NTsCX6hBvVi4WZITCs0jGGcm7Va+3znfjj4MiAAM3tcRy02SZ tSOmnXeCwBc5AX5eB3Kd+xKNZxXCyzHsp+kgD8vW1r0AsLIGAj/wmwGiEmP8a9cfddjf uVFnMtSORVnE5yU94ptx+uYmA8xLZ9wPsI29tkvBCp3ypypO2jxb7B4aWXLURsTldyut ndeSmhaqjTl/OnuW5cOzW6k+WQYsvxlsRVuT0Yc/IEv4Q3UkYGnJFhCSBh7X0pExLfoh rx5aiHU3AraQGr1GgsbmhCar13FKkb0y+Ydy4rnE/GYy/f1sCYds+dIQkpxCQpMgFgB2 1gyQ== X-Gm-Message-State: ALoCoQlj4VgS/IZQBtSc4CzD2NrZZEEJlE/BmPinsCMnJ1QhT1hjlyZDFSV6ozeC5lQk0ivpmayp X-Received: by 10.182.85.228 with SMTP id k4mr30277770obz.37.1404737931879; Mon, 07 Jul 2014 05:58:51 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:3429:90e6:4231:9e43? ([2602:306:3406:4f00:3429:90e6:4231:9e43]) by mx.google.com with ESMTPSA id g7sm105724506oek.14.2014.07.07.05.58.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 05:58:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D0E71021-14EF-472A-91D7-C37D0396F446"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "Adam W. Montville" In-Reply-To: Date: Mon, 7 Jul 2014 07:57:31 -0500 Message-Id: <79779032-CA9B-4232-B406-F56D8F42C056@stoicsecurity.com> References: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> To: Tim Bray X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fJnZVkRPB40mRM-avtNS7zOC56k Cc: mile@ietf.org, draft-ietf-mile-enum-reference-format.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-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: Mon, 07 Jul 2014 12:58:55 -0000 --Apple-Mail=_D0E71021-14EF-472A-91D7-C37D0396F446 Content-Type: multipart/alternative; boundary="Apple-Mail=_775E16EC-DE05-440D-8FBA-2B84D8DDB793" --Apple-Mail=_775E16EC-DE05-440D-8FBA-2B84D8DDB793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 3, 2014, at 12:20 PM, Tim Bray wrote: > > Also, in the IANA table, shouldn=E2=80=99t the spec say something = about what > > kind of thing the Specification URI is supposed to identify? An = I-D? > > An RFC? An XSD? >=20 > The Specification URI is a list of one or more URIs. Then, we=E2=80=99d= need a descriptor for each potential URI associated with the Index. Is = that what you had in mind, or something else? >=20 > =E2=80=8BHm, no, I mean, are there any constraints on who=E2=80=99s = allowed to specify enumerations, what kinds of things should = implementers be prepared to deal with? Can any storefront publish a = one-page description of some values and expect implementers to find use = in it? I have no ideas or opinions about the answers to this question, = but I think it=E2=80=99s a real question. When I see a =E2=80=9CURL of = the specification=E2=80=9D with no remarks about what kind of beast it = might be or where it comes from, that makes me nervous (and it might = make the IESG nervous too).=E2=80=8B Ah, I see. We do have a requirement for expert review of entries, which = should reduce the likelihood of odd publications to the IANA table. Any = entry being made to the IANA table, in being subject to expert review, = would have the specification URL vetted to ensure that the URL is = suitable for implementers to reference. --Apple-Mail=_775E16EC-DE05-440D-8FBA-2B84D8DDB793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 3, 2014, at 12:20 PM, Tim Bray = <tbray@textuality.com> = wrote:

> Also, = in the IANA table, shouldn=E2=80=99t the spec say something about = what
> kind of thing the Specification URI is supposed to = identify?  An I-D?
> An RFC? An XSD?

The = Specification URI is a list of one or more URIs.  Then, we=E2=80=99d = need a descriptor for each potential URI associated with the Index. =  Is that what you had in mind, or something = else?

=E2=80=8BHm, no, I = mean, are there any constraints on who=E2=80=99s allowed to specify = enumerations, what kinds of things should implementers be prepared to = deal with?  Can any storefront publish a one-page description of = some values and expect implementers to find use in it?  I have no = ideas or opinions about the answers to this question, but I think it=E2=80= =99s a real question.  When I see a =E2=80=9CURL of the = specification=E2=80=9D with no remarks about what kind of beast it might = be or where it comes from, that makes me nervous (and it might make the = IESG nervous too).=E2=80=8B

Ah, I = see.  We do have a requirement for expert review of entries, which = should reduce the likelihood of odd publications to the IANA table. =  Any entry being made to the IANA table, in being subject to expert = review, would have the specification URL vetted to ensure that the URL = is suitable for implementers to reference.
= --Apple-Mail=_775E16EC-DE05-440D-8FBA-2B84D8DDB793-- --Apple-Mail=_D0E71021-14EF-472A-91D7-C37D0396F446 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTupk7AAoJELhc5c4zaVWHUUwH/2XvMC2D4847we9eUBMEFKd6 DqlJpsR6Mrm02uWDdIS6h+pnl4jaSDueSX0v6K0W+axdV+bsOv+elzGqqGwU1u4S bdgFd8PcqqdcUVwIv6QBV2/LopIAvRlVc6tGryZAJ5iQvMMUhtRIFqVHpBZ+WGwt VdFsycD4V9T0TZxmOp7Z42T24JueeSX1GCwqVjMHXLqOo9E2FrVoxSgb9IhZjDL/ wcs3/mQczJbAbsItLT2djw8tx/+msMYNPZrp2uO6JiMxJ5QFiNxBJhiTqzq4bDEe syWt1XUy8oqoCrmPoxQpl1y94AjMGP/la30Kr36SZ3ubXCiVVdWPuWYo+liIfD8= =vh9x -----END PGP SIGNATURE----- --Apple-Mail=_D0E71021-14EF-472A-91D7-C37D0396F446-- From nobody Mon Jul 7 06:03: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 ED8971B284F; Mon, 7 Jul 2014 06:03: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 gMnKEMarK-lR; Mon, 7 Jul 2014 06:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8744A1A0400; Mon, 7 Jul 2014 06:03:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140707130350.28906.72882.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 06:03:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ON92FNoySrP8XLhcYXpxyg6Fdg0 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (IMAP4 Multimailbox SEARCH Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:03:52 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'IMAP4 Multimailbox SEARCH Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 7 09:34:19 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 D120B1A0340; Mon, 7 Jul 2014 09:34:16 -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 BYL5R3qnd64H; Mon, 7 Jul 2014 09:34:14 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5AA1A036D; Mon, 7 Jul 2014 09:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 587D41C5B44; Mon, 7 Jul 2014 12:34:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbGQZI1pcnf0; Mon, 7 Jul 2014 12:33:58 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id BB55E1C5B21; Mon, 7 Jul 2014 12:33:56 -0400 (EDT) Date: Mon, 07 Jul 2014 12:34:03 -0400 From: Cyrus Daboo To: Pete Resnick , Barry Leiba Message-ID: <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> In-Reply-To: <53B9C161.4050502@qti.qualcomm.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1043 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GuQu812tHIpV0SejjIkIoeHurkI Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 07 Jul 2014 16:34:16 -0000 Hi Pete, --On July 7, 2014 at 12:36:33 AM +0300 Pete Resnick wrote: >> The only thing that the charter leaves in scope with regard to that >> happens if we find security issues, while building the distribution >> protocol. > > Perhaps Cyrus could better explain, but: What sort of "security issues", > and security issues with *what*, was this referring to? I'm mildly > inclined to remove that line from the charter, but I'd like to hear what > was being considered. During apps-discuss discussion, it was suggested that we might want to digitally sign the time zone data, rather than just rely on transport layer security (TLS) to validate the data service server. If we opt for such a thing, we may want to have the Olson data signed in a more reliable manner than at present. RFC 6557 did indicate that IANA would be in charge of maintaining the private key used to sign the data, but I think right now the available signature is created using the TZ co-ordinator's own private key. -- Cyrus Daboo From nobody Mon Jul 7 10:43: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 672E81A0522 for ; Mon, 7 Jul 2014 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 FWM01P_tYbHI for ; Mon, 7 Jul 2014 10:43:34 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7AF1B278F for ; Mon, 7 Jul 2014 10:43:34 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id lf12so4284263vcb.18 for ; Mon, 07 Jul 2014 10:43:33 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SCWYB5okgKKYWaxtKOJLrga/K5noCLVgjt/GpHM/nXw=; b=Ii+YSCjbap+YmgXOstgl6rRsftmZflHscUd8PPCoW2lXpPl3EKqv2fUXt7Sva41Mdh ARLGJk485ouE/8HSRD+sXqtHAcWvTwgn0SiyELRdEKU8HTjD04oShywvAMm8cHKYeVEG bKM5b8Pm3c7JN/iIXTxoXZ4jPCgGJKw8MLPvRFl420oPFcxKIU/Lz/4cHdFZD+b61K3q qkQ9fUDC8aaeqZuwTu/DUeEN1YC5nBdsMu9a7kLRIOf71Rz4QsRnWhgz8qdRnqqIx2Br xMSy68Y5nyJFdl4/poBe8fJXGU0ZkIQY+c4sQOLqkWYuKVSGKQ5Yeh8d5z0de99jRKcK M7OQ== X-Gm-Message-State: ALoCoQk/S5vTAMZiTg1sA6G+4e37dHU/fYizpv1vehn0AYwv9H5znD9kbWM0alFExDx7HUCMBToQ X-Received: by 10.58.11.234 with SMTP id t10mr2476095veb.8.1404755013775; Mon, 07 Jul 2014 10:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Mon, 7 Jul 2014 10:43:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <79779032-CA9B-4232-B406-F56D8F42C056@stoicsecurity.com> References: <5A7D2557-1E55-40DC-A326-6D0FF69D6408@stoicsecurity.com> <79779032-CA9B-4232-B406-F56D8F42C056@stoicsecurity.com> From: Tim Bray Date: Mon, 7 Jul 2014 10:43:13 -0700 Message-ID: To: "Adam W. Montville" Content-Type: multipart/alternative; boundary=e89a8f2355a597c5f004fd9e037f Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fHFVk2YykeN8A0aLuz4yT216KwQ Cc: mile@ietf.org, draft-ietf-mile-enum-reference-format.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-ietf-mile-enum-reference-format-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: Mon, 07 Jul 2014 17:43:37 -0000 --e89a8f2355a597c5f004fd9e037f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, right, the expert review is better than nothing. Might it be useful to provide guidance for expert reviewers in this RFC as to what implementers need to find in an enumeration spec? Just giving a URL-for-a-spec does leave the feeling of a missing piece. On Mon, Jul 7, 2014 at 5:57 AM, Adam W. Montville wrote: > > On Jul 3, 2014, at 12:20 PM, Tim Bray wrote: > > > Also, in the IANA table, shouldn=E2=80=99t the spec say something about= what >> > kind of thing the Specification URI is supposed to identify? An I-D? >> > An RFC? An XSD? >> >> The Specification URI is a list of one or more URIs. Then, we=E2=80=99d= need a >> descriptor for each potential URI associated with the Index. Is that wh= at >> you had in mind, or something else? >> > > =E2=80=8BHm, no, I mean, are there any constraints on who=E2=80=99s allow= ed to specify > enumerations, what kinds of things should implementers be prepared to dea= l > with? Can any storefront publish a one-page description of some values a= nd > expect implementers to find use in it? I have no ideas or opinions about > the answers to this question, but I think it=E2=80=99s a real question. = When I see > a =E2=80=9CURL of the specification=E2=80=9D with no remarks about what k= ind of beast it > might be or where it comes from, that makes me nervous (and it might make > the IESG nervous too).=E2=80=8B > > > Ah, I see. We do have a requirement for expert review of entries, which > should reduce the likelihood of odd publications to the IANA table. Any > entry being made to the IANA table, in being subject to expert review, > would have the specification URL vetted to ensure that the URL is suitabl= e > for implementers to reference. > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --e89a8f2355a597c5f004fd9e037f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah,= right, the expert review is better than nothing. =C2=A0Might it be useful = to provide guidance for expert reviewers in this RFC as to what implementer= s need to find in an enumeration spec? =C2=A0Just giving a URL-for-a-spec d= oes leave the feeling of a missing piece.


On Mon,= Jul 7, 2014 at 5:57 AM, Adam W. Montville <adam@stoicsecurity.com> wrote:


> Also, in the IANA table, shouldn=E2=80=99t the spec say something= about what
> kind of thing the Specification URI is supposed to iden= tify? =C2=A0An I-D?
> An RFC? An XSD?

The Specification = URI is a list of one or more URIs. =C2=A0Then, we=E2=80=99d need a descript= or for each potential URI associated with the Index. =C2=A0Is that what you= had in mind, or something else?

=E2=80=8BHm, no, I m= ean, are there any constraints on who=E2=80=99s allowed to specify enumerat= ions, what kinds of things should implementers be prepared to deal with? = =C2=A0Can any storefront publish a one-page description of some values and = expect implementers to find use in it? =C2=A0I have no ideas or opinions ab= out the answers to this question, but I think it=E2=80=99s a real question.= =C2=A0When I see a =E2=80=9CURL of the specification=E2=80=9D with no rema= rks about what kind of beast it might be or where it comes from, that makes= me nervous (and it might make the IESG nervous too).=E2=80=8B

Ah, I see. =C2=A0We do have a requirement= for expert review of entries, which should reduce the likelihood of odd pu= blications to the IANA table. =C2=A0Any entry being made to the IANA table,= in being subject to expert review, would have the specification URL vetted= to ensure that the URL is suitable for implementers to reference.



--
- Tim Bray (If you=E2=80=99d like to send me a private mess= age, see https://k= eybase.io/timbray)
--e89a8f2355a597c5f004fd9e037f-- From nobody Mon Jul 7 11:20: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 C45631A02D5 for ; Mon, 7 Jul 2014 11:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, 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 lYqi9N5_mB5i for ; Mon, 7 Jul 2014 11:20:41 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE53E1A0255 for ; Mon, 7 Jul 2014 11:20:40 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so4235321qcv.12 for ; Mon, 07 Jul 2014 11:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uiNsdBw7VMpRVSBUMZzFS7CwruYnW1LlBKQHxNUG6zI=; b=lX6QWBx7fbIggO/9N8UejAQs6wLT2geeN1WVxk+TSF4upZwrVYEnm2hoWEK5uPGuoK 36VBhEdtfQkaO0cvujadcC/CqFrYIfoAgki+hN6wvxMGrdL8vwwQeoSoMPyTeI+huMtD ulYFapwX58LTyCotK/2UjVJIECDE5m+iryJJHFr8UtIRG+vngzskCyETNRTdqXVE/HWF fgB6c0AnFz0NDVpggf7WRzzA2tG+2Mg3LnHyBVX0IjQOuT279BaGeuSC2CFrGnPyQ94A /u2esS6GKL/XwsaJl4cgtq9LCGCW1rFjPYCKCtrXpvOp3VC7KEdOL/k94OZV7UK+FA3I 2n0A== 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:from:date :message-id:subject:to:cc:content-type; bh=uiNsdBw7VMpRVSBUMZzFS7CwruYnW1LlBKQHxNUG6zI=; b=W/NbRPpZ//0qtxWGArOcsPzlBMlSVRtV3kdYndd0A/JImmsGmzbJiKch4qDAwvB3OT NDMKNF9AZuUyuDaTle3MPpxBRbkGWrCxBezP1qZWhXhwmPYusW+YbXD/Y5EVz8CnIdgD JqBj1SuT2vh50v8E9nxAXIuYkGKBAEQ/cNgKKAcr21zuxofyHE2id6zWu9iUbsgG4tJC CwW88MWnhKi7zq7F38fU0HZDhDt6mGl8Xb6aHIYS7Ch4oVrSI2umi0mOrFH68Tp++3c2 j73RvFh6WEtEsptDPj2FphJykgdjAU82oU6Ac8eVykCm5on6FRK6yCECWtIx/N1EPh/z 9O1A== X-Gm-Message-State: ALoCoQnCBAJiTzjgVzQRFhm9gPpbumwj29jpMreTGDrk4JaQZ68hnHxcXmDNAMKoBKN2Jt3Uz3YO X-Received: by 10.140.27.215 with SMTP id 81mr27680357qgx.18.1404757239911; Mon, 07 Jul 2014 11:20:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Mon, 7 Jul 2014 11:20:19 -0700 (PDT) In-Reply-To: <01P9O32XP18I0049PU@mauve.mrochek.com> References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> From: Wei Chuang Date: Mon, 7 Jul 2014 11:20:19 -0700 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a11c14ae04809c904fd9e8877 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ndllusw1RhNke39-w1G2OWhj6DA Cc: John R Levine , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 07 Jul 2014 18:20:42 -0000 --001a11c14ae04809c904fd9e8877 Content-Type: text/plain; charset=ISO-8859-1 I'm sorry I missed the significance of the MIME tree hashing in draft-kucherawy-dkim-list-canon with respect to the DKIM diff proposal. A common place action that mailing lists do, is to strip a MIME part e.g. text/html. MIME tree hashing is particular good at recognizing that a part has been removed leaving other parts unchanged. If the removed part is within a MIME multipart/alternative, then the change is acceptable as the information can be found in another part, and the message can pass. Using the MIME tree hashing means that the diff for the removed part won't be needed as the tree hash will indicate this and protect the unchanged sections. However if a part is added, a diff should still be required in this proposal for spam analysis by the final recipient. (I wonder if it would be helpful if mailing-lists publish the static content they intent to add to messages via some DNS record...) -Wei On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed wrote: > > I posted a draft that captures an idea originally proposed by Ned Freed: > > I think Merkle got there first on the whole tree thing, but whatever. > > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > > > It's a canonicalization that hashes each piece of the MIME structure > > individually, as a tree. This allows for easy detection of modifications > > of an individual part, or of a subtree. It's also able to withstand > > encoding changes so long as the encoded content itself isn't changed. > > Surviving encoding changes was the original motivation for doing this, > albeit in the context of multipart/signed, not DKIM. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c14ae04809c904fd9e8877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm sorry I missed the significance of the MIME tree h= ashing in draft-kucherawy-dkim-list-canon with respect to the DKIM diff pro= posal. =A0A common place action that mailing lists do, is to strip a MIME p= art e.g. text/html. =A0MIME tree hashing is particular good at recognizing = that a part has been removed leaving other parts unchanged. =A0If the remov= ed part is within a MIME multipart/alternative, then the change is acceptab= le as the information can be found in another part, and the message can pas= s. =A0Using the MIME tree hashing means that the diff for the removed part = won't be needed as the tree hash will indicate this and protect the unc= hanged sections. =A0However if a part is added, a diff should still be requ= ired in this proposal for spam analysis by the final recipient. (I wonder i= f it would be helpful if mailing-lists publish the static content they inte= nt to add to messages via some DNS record...)=A0

-Wei


On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
> I posted a draft that c= aptures an idea originally proposed by Ned Freed:

I think Merkle got there first on the whole tree thing, but whatever.=

> https://datatracker.ietf.org/doc/draft-kucherawy-= dkim-list-canon/

> It's a canonicalization that hashes each piece of the MIME structu= re
> individually, as a tree. =A0This allows for easy detection of modifica= tions
> of an individual part, or of a subtree. =A0It's also able to withs= tand
> encoding changes so long as the encoded content itself isn't chang= ed.

Surviving encoding changes was the original motivation for doing this= ,
albeit in the context of multipart/signed, not DKIM.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned

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

--001a11c14ae04809c904fd9e8877-- From nobody Mon Jul 7 12:01: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 71D441B2874 for ; Mon, 7 Jul 2014 12:01:56 -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 1wrLfTNAb76p for ; Mon, 7 Jul 2014 12:01:55 -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 5B6341A0450 for ; Mon, 7 Jul 2014 12:01:52 -0700 (PDT) Received: (qmail 91659 invoked from network); 7 Jul 2014 19:01:51 -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; s=1660a.53baee9f.k1407; bh=18ODxz7sg1lKReDmDsI46f5GaTaWt2akHQHkJbKd/3Q=; b=VmhUl4IwAwbRPyCElFJCcM/2k+NeuvyRw0RHkIT61f+WzS4RWq+mAQ5XErZBQB0rq9P3jWosqsjtrkgiGxjKWy2mK+vCR+idY0Pj8oWnNiPrYr2aPLEAT49MrSzaVxfa+48oQQL/06dAQCnP8Cjb44wCxuffWf4uTfIb2ELL3wJ/Sj1z5Q/vgXQ7x6opkkaa9OQ2K/zeQMUJCd9TguXCKZLwUPlEvzLSPqE7oY0eBNlx6Be7KPs+pJ6NSrCqflbb 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; s=1660a.53baee9f.k1407; bh=18ODxz7sg1lKReDmDsI46f5GaTaWt2akHQHkJbKd/3Q=; b=uTL1P+kJmOdJgUf2WXK783glgShUizCUjPNrJKCVF5ZalYbd++Jy7h2M3z2yk4KffewrT+fNvoVTi1lGu4PXunboZxXOHQt9hWKNRL20qkB+Vdm1MpBiurponPVnYoQr2Gl1Nl1M6Kd45kekLUqs73jzdY48xKhpB6zZB6gEcUoeWv3iCOUZ8jVmFPs/aG2HG/TlfwAGH5LXOCWMxBPHOS/CxKEsACpbQr0yZMA+3tUCDkssAWKFriqEf8D39wns 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; 07 Jul 2014 19:01:51 -0000 Date: 7 Jul 2014 15:01:50 -0400 Message-ID: From: "John R Levine" To: "Wei Chuang" In-Reply-To: References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2vbQBpI7Hd5T1FY40vtKjNBsW28 Cc: apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 07 Jul 2014 19:01:56 -0000 > However if a part is added, a diff should still be required in > this proposal for spam analysis by the final recipient. (I wonder if it > would be helpful if mailing-lists publish the static content they intent to > add to messages via some DNS record...) Assuming the list signs its outgoing mail, there's no question that the modified message came from the list, so I don't see what that would add. Once again, this very complicated approach will only be useful if you can mechanically describe the how to tell modified messages that are "too different" from messages that are not. Please give us some hints about how that would work. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Jul 7 12: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 7C5921B28A1 for ; Mon, 7 Jul 2014 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 URKvk19yeJDr for ; Mon, 7 Jul 2014 12:21:28 -0700 (PDT) Received: from ntbbs.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E15E71B289C for ; Mon, 7 Jul 2014 12:21:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8743; t=1404760885; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=SuoYCX/ RHjLm18ZZymVYRYqGg38=; b=KStLN6Jy/w8mXaMHMZaKVblSVQ9IDS+RB8aF4AO fYuhq4Y0QfCQlzDN80hlTzTphQ6lxtVUeZ5vjTsgQ6hKJIaRPgR87UP6KeZNn92f TOQQN9S1MjvtbhxYxmoUuwal4+8kP/sJocj+j0PtAAgpisiRhaE/WZV8p3NH/fW2 te64= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 07 Jul 2014 15:21:25 -0400 Received: from [192.168.1.221] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4240981591.8197.5380; Mon, 07 Jul 2014 15:21:24 -0400 References: <20140629012552.81149.qmail@joyce.lan> <01P9O32XP18I0049PU@mauve.mrochek.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-605C4AE5-6114-48B0-B613-864F1DA520F6 Content-Transfer-Encoding: 7bit Message-Id: <3EC3EDC1-BFC5-471D-A237-D08BAB02A88E@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 7 Jul 2014 15:21:24 -0400 To: Wei Chuang Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/S7gQ1LQaexGX1QXY_uONRjDHhz4 Cc: Ned Freed , apps-discuss Subject: Re: [apps-discuss] DKIM Forwarding History (Provenance) Proposal 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, 07 Jul 2014 19:21:31 -0000 --Apple-Mail-605C4AE5-6114-48B0-B613-864F1DA520F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It has been historical acceptable for a backend to strip a multi-part altern= ative type .i.e. text/html, with the design presumption, the plain text cont= ext expresses the same meaning and interpretation. It would be the same idea= of just having different readers display fonts. For security reasons and a= lso backward compatibility, the operator had control on the local mail stora= ge policy including in what format it will be saved for its end users. It w= as not just security but there with storage limits, boundaries too. In fact, I don't think it is a given user right that "wysiwyg" was ever a gu= arantee. Perhaps today, we have more confidence in the security aspect of M= UAs. The controls are in place to protect users from client side scripting e= xploits, so we keep with raw "as is" RFC5322 storage. For example, in our p= ackage, after many years of only operator control, the user can now choose h= ow the backend hosting server should save direct private mail. Of course, i= t is probably common for MUAs to have a text vs simple HTML vs raw HTML disp= lay options. This is also based on the idea that all modes provide the user w= ith equivalent context reading. -- Hector Santos http://www.santronics.com > On Jul 7, 2014, at 2:20 PM, Wei Chuang wrote: >=20 > I'm sorry I missed the significance of the MIME tree hashing in draft-kuch= erawy-dkim-list-canon with respect to the DKIM diff proposal. A common plac= e action that mailing lists do, is to strip a MIME part e.g. text/html. MIM= E tree hashing is particular good at recognizing that a part has been remove= d leaving other parts unchanged. If the removed part is within a MIME multi= part/alternative, then the change is acceptable as the information can be fo= und in another part, and the message can pass. Using the MIME tree hashing m= eans that the diff for the removed part won't be needed as the tree hash wil= l indicate this and protect the unchanged sections. However if a part is ad= ded, a diff should still be required in this proposal for spam analysis by t= he final recipient. (I wonder if it would be helpful if mailing-lists publis= h the static content they intent to add to messages via some DNS record...)=20= >=20 > -Wei >=20 >=20 >> On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed wrote: >> > I posted a draft that captures an idea originally proposed by Ned Freed= : >>=20 >> I think Merkle got there first on the whole tree thing, but whatever. >>=20 >> > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >>=20 >> > It's a canonicalization that hashes each piece of the MIME structure >> > individually, as a tree. This allows for easy detection of modificatio= ns >> > of an individual part, or of a subtree. It's also able to withstand >> > encoding changes so long as the encoded content itself isn't changed. >>=20 >> Surviving encoding changes was the original motivation for doing this, >> albeit in the context of multipart/signed, not DKIM. >>=20 >> Ned >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-605C4AE5-6114-48B0-B613-864F1DA520F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It has been historical acceptable for a= backend to strip a multi-part alternative type .i.e. text/html, with the d= esign presumption, the plain text context expresses the same meaning and int= erpretation. It would be the same idea of just having different readers disp= lay fonts.  For security reasons and also backward compatibility, the o= perator had control on the local mail storage policy including in what forma= t it will be saved for its end users.   It was not just security but th= ere with storage limits, boundaries too.

In fact, I= don't think it is a given user right that "wysiwyg" was ever a guarantee. &= nbsp; Perhaps today, we have more confidence in the security aspect of MUAs.= The controls are in place to protect users from client side scripting explo= its, so we keep with raw "as is" RFC5322 storage.  For example, in our p= ackage, after many years of only operator control, the user can now choose h= ow the backend hosting server should save direct private mail.  Of cour= se, it is probably common for MUAs to have a text vs simple HTML vs raw HTML= display options. This is also based on the idea that all modes provide the u= ser with equivalent context reading.

--
Hector Santos

On Jul 7, 2014, at 2:20 PM, Wei Chuang <weihaw@google.com> wrote:

I'm sorry I missed the significance o= f the MIME tree hashing in draft-kucherawy-dkim-list-canon with respect to t= he DKIM diff proposal.  A common place action that mailing lists do, is= to strip a MIME part e.g. text/html.  MIME tree hashing is particular g= ood at recognizing that a part has been removed leaving other parts unchange= d.  If the removed part is within a MIME multipart/alternative, then th= e change is acceptable as the information can be found in another part, and t= he message can pass.  Using the MIME tree hashing means that the diff f= or the removed part won't be needed as the tree hash will indicate this and p= rotect the unchanged sections.  However if a part is added, a diff shou= ld still be required in this proposal for spam analysis by the final recipie= nt. (I wonder if it would be helpful if mailing-lists publish the static con= tent they intent to add to messages via some DNS record...) 

-Wei


On Tue, Jul 1, 2014 at 3:46 PM, Ned Freed <ned.freed@mr= ochek.com> wrote:
> I posted a draft that cap= tures an idea originally proposed by Ned Freed:

I think Merkle got there first on the whole tree thing, but whatever.<= br>

> https://datatracker.ietf.org/doc/draft-kucherawy-dk= im-list-canon/

> It's a canonicalization that hashes each piece of the MIME structure > individually, as a tree.  This allows for easy detection of modifi= cations
> of an individual part, or of a subtree.  It's also able to withsta= nd
> encoding changes so long as the encoded content itself isn't changed.
Surviving encoding changes was the original motivation for doing this,=
albeit in the context of multipart/signed, not DKIM.

                     =           Ned

_______________________________________________
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
<= /blockquote>= --Apple-Mail-605C4AE5-6114-48B0-B613-864F1DA520F6-- From nobody Mon Jul 7 12:47: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 838F11B28BC; Mon, 7 Jul 2014 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 TyW25aNzfcdm; Mon, 7 Jul 2014 12:47:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF771B28CC; Mon, 7 Jul 2014 12:47:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 826D6180015; Mon, 7 Jul 2014 12:46:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140707194653.826D6180015@rfc-editor.org> Date: Mon, 7 Jul 2014 12:46:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wmDM36vjJufq5bhayHBi6bMbFd4 Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7303 on XML Media Types 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, 07 Jul 2014 19:47:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7303 Title: XML Media Types Author: H. Thompson, C. Lilley Status: Standards Track Stream: IETF Date: July 2014 Mailbox: ht@inf.ed.ac.uk, chris@w3.org Pages: 35 Characters: 77654 Obsoletes: RFC 3023 Updates: RFC 6839 I-D Tag: draft-ietf-appsawg-xml-mediatypes-10.txt URL: http://www.rfc-editor.org/rfc/rfc7303.txt This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jul 7 14:35: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 362271B2905 for ; Mon, 7 Jul 2014 14:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 nB1ToDhbyyqS for ; Mon, 7 Jul 2014 14:35:18 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395071B2938 for ; Mon, 7 Jul 2014 14:35:15 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so5026702wes.22 for ; Mon, 07 Jul 2014 14:35:13 -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=qX9NVBs+Ayst/J+qzdrFokfU2e5ntq8Qf4jy/3QmQfg=; b=XnYo3yRyZmIYeRB8oMCJp7nLt/9rb8owjou/dMtSqSc3ING9aZaWxzPW/aSbZ6YYh9 8vdBjDD+Kv6IYG6JwJP85Xk1wdMRzLtQ9Oa+3780hs3irNWNHo4Isltje8dTzZL1wnWb Agvlnwp6oTWulLW6LHsdLc8AYQKOZgQuX22gxUam8eJK+BrzQujpAYVGqAk97BCiNCNi uPLrqCWNEizW1/xvlIU0rOAmVnUzBDfkPOpimMcDzLbzDV2j33i4KJafdMrgS8DLVboR O7iKD8hNU7e7MdDADAj3BkqLgmxi1aQ35Zx9QZ05ZRzo2NZJe/RWUIQ58PtnIGFpx81V A0Og== MIME-Version: 1.0 X-Received: by 10.180.10.168 with SMTP id j8mr79817450wib.73.1404768913620; Mon, 07 Jul 2014 14:35:13 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Mon, 7 Jul 2014 14:35:13 -0700 (PDT) Date: Mon, 7 Jul 2014 14:35:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2591816848f04fda140f4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_sNTu8rm3jx3afqHYLr5acwMBxw Subject: [apps-discuss] Authentication-Results ptype extensions 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, 07 Jul 2014 21:35:19 -0000 --001a11c2591816848f04fda140f4 Content-Type: text/plain; charset=UTF-8 Colleagues, The Authentication-Results header field (RFC 7001) restricts the types of information about which it can report results to four things: SMTP parameters, parts of the body, parts of the header, or local policy actions. Two different people have proposed extensions in the past that have run into this limitation, namely that they want to report results that aren't pulled from one of those four places. I've created a draft (link below) that makes this list extensible. I'd like to process it through APPSAWG if there's support for doing so. It needs to go through an IETF stream because it seeks to create a registry that requires a Designated Expert, so APPSAWG would be an ideal place to process it absent a working group that's actually currently doing this sort of thing. It is blissfully short. http://datatracker.ietf.org/doc/draft-kucherawy-authres-ptypes-registry/ Are there enough people who would be willing to review/comment/support its handling through APPSAWG? -MSK, hatless --001a11c2591816848f04fda140f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The Authentic= ation-Results header field (RFC 7001) restricts the types of information ab= out which it can report results to four things: SMTP parameters, parts of t= he body, parts of the header, or local policy actions.=C2=A0 Two different = people have proposed extensions in the past that have run into this limitat= ion, namely that they want to report results that aren't pulled from on= e of those four places.

I've created a draft (link below) that makes this list extens= ible.=C2=A0 I'd like to process it through APPSAWG if there's suppo= rt for doing so.=C2=A0 It needs to go through an IETF stream because it see= ks to create a registry that requires a Designated Expert, so APPSAWG would= be an ideal place to process it absent a working group that's actually= currently doing this sort of thing.=C2=A0 It is blissfully short.

http://datatracker.ietf.org/doc/draft-kucherawy-authres-ptype= s-registry/

Are there enough people who would be willing t= o review/comment/support its handling through APPSAWG?

-MSK, hatless

--001a11c2591816848f04fda140f4-- From nobody Mon Jul 7 14:45: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 469211B2959 for ; Mon, 7 Jul 2014 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, 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 lfbFj-QbAOaN for ; Mon, 7 Jul 2014 14:45:32 -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 1BA4D1B2955 for ; Mon, 7 Jul 2014 14:45:32 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id EBCF9D043A9; Mon, 7 Jul 2014 17:45:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1404769531; bh=lBwpBQvAUZQ25pU3KUmj72/4kqiNhjOrOLmrjWfqX0E=; h=In-Reply-To:References:Subject:From:Date:To:From; b=MhYp2foS2AvC34KlPOtP5hwxp9Xfla8yDFf4TtegNIPRMcq2oH3fRlXne0OtuBBv3 Zgir3bakk2WEsz9ar0e/t3pAGH3K3gPh8YB6A/GrifaM4H2zZs3pUMzHVsRA/DE+6K yj6MUcKR40nWxzwR3hObcJ/ovKbDRfY2xHSHrxZE= Received: from [IPV6:2600:1003:b128:9181:8866:1f53:9e0f:b22f] (unknown [IPv6:2600:1003:b128:9181:8866:1f53:9e0f:b22f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8A249D041B5; Mon, 7 Jul 2014 17:45:30 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Mon, 07 Jul 2014 17:44:45 -0400 To: IETF Apps Discuss Message-ID: <9cb7cd3f-eb11-4704-822c-2e238790020e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kYvhbSANgSPccUsasLCBUVH0bVA Subject: Re: [apps-discuss] Authentication-Results ptype extensions 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, 07 Jul 2014 21:45:33 -0000 On July 7, 2014 5:35:13 PM EDT, "Murray S. Kucherawy" wrote: >Colleagues, > >The Authentication-Results header field (RFC 7001) restricts the types >of >information about which it can report results to four things: SMTP >parameters, parts of the body, parts of the header, or local policy >actions. Two different people have proposed extensions in the past >that >have run into this limitation, namely that they want to report results >that >aren't pulled from one of those four places. > >I've created a draft (link below) that makes this list extensible. I'd >like to process it through APPSAWG if there's support for doing so. It >needs to go through an IETF stream because it seeks to create a >registry >that requires a Designated Expert, so APPSAWG would be an ideal place >to >process it absent a working group that's actually currently doing this >sort >of thing. It is blissfully short. > >http://datatracker.ietf.org/doc/draft-kucherawy-authres-ptypes-registry/ > >Are there enough people who would be willing to review/comment/support >its >handling through APPSAWG? > Yes. Please. I'm in. Scott K From nobody Mon Jul 7 15:08: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 2FDCE1B2969 for ; Mon, 7 Jul 2014 15:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, 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 cXPwJp45sbae for ; Mon, 7 Jul 2014 15:08:14 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9581B2963 for ; Mon, 7 Jul 2014 15:08:14 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id oy12so4886154veb.9 for ; Mon, 07 Jul 2014 15:08:13 -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:cc:content-type; bh=XN15En/X4ErtDIOilQklTvAEImt/Xfpm3UqYKxUN28E=; b=I+8+jUQqm3u0qEwi99YSgpd8uLepAjC34BWvg5xsLiP0cEEoDMt9re8lbE2r5SYi+W FEqFbMH4dA7ELLEb6V0s1Q4G+l/QmI368HnyNSwlkBa0kYxWTMLnflCewzKJdAh6fvz0 iuGOgM2IWsXnAJ/D/WuNEHPGEDqzTswhelgZVcJplK4HyF4+e1WJfzxT8tqpHh6s/54p AqrqHEk71kJZf02cA25BDtQElir9TvT0zVrK+CZf6EzFambgtNwSCTdLSKSKiyWvH2Q4 bYK25eInZk842/6YEJLplPbzhEvkT23RsW9ZYIMMgFn2PDLDmwL/WLMb10IZO1e1GhPQ i7Aw== MIME-Version: 1.0 X-Received: by 10.52.182.163 with SMTP id ef3mr24998750vdc.22.1404770893276; Mon, 07 Jul 2014 15:08:13 -0700 (PDT) Received: by 10.58.2.138 with HTTP; Mon, 7 Jul 2014 15:08:13 -0700 (PDT) Date: Tue, 8 Jul 2014 00:08:13 +0200 Message-ID: From: =?UTF-8?Q?Fatma_BEN_JEM=C3=82A?= To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=bcaec548a7a315af5504fda1b630 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gOTu_SU7awrBr5JgXe8AbIvQ5kU Cc: Michel Pariente , Guy Pujolle , barryleiba@computer.org Subject: [apps-discuss] Call for review and adoption: draft-benjemaa-vbs-urn 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, 07 Jul 2014 22:08:15 -0000 --bcaec548a7a315af5504fda1b630 Content-Type: text/plain; charset=UTF-8 Hello everybody, I have posted an IETF draft as an individual submission titled "Labels for common venue-based services". http://datatracker.ietf.org/doc/draft-benjemaa-vbs-urn/ It defines new URN service labels to identify the most known and common venue-based services which can be useful for service discovery in WLAN networks. I would like to invite you to read this draft and give your comments, propositions, concerns, support, etc. I found that the APPSAWG is the most appropriate venue for this draft and I hope it could be adopted into this working group as a work item. Thank you. Best Regards Fatma Ben Jemaa --bcaec548a7a315af5504fda1b630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everybody,

I have posted an IETF draft as an individual submission titled "Lab= els for common venue-based services".

It def= ines new URN service labels to identify the most known and common venue-bas= ed services which can be useful for service discovery in WLAN networks.

I would like to invite= you to read this draft and give your comments, propositions, concerns, sup= port, etc.

I found that the APPSA= WG is the most appropriate venue for this draft and I hope it could be adop= ted into this working group as a work item.

Thank you.

Best Regards
Fatma Ben Jemaa
--bcaec548a7a315af5504fda1b630-- From nobody Mon Jul 7 15:49: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 4B6D61B2977 for ; Mon, 7 Jul 2014 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, 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 9Qfv1_PN8NPI for ; Mon, 7 Jul 2014 15:49:13 -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 4C5611B28A5 for ; Mon, 7 Jul 2014 15:49:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s67MmpxI005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 15:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404773343; x=1404859743; bh=nhK/P3sbI++0XLrWxkOGEuqwOkkrOF+he3iR8hZkVJg=; h=Date:To:From:Subject:Cc; b=GliyG/SlK/0pjYmeRoGQZi+ETXwvNhIm8XACTrjE7pM4HE0UK83LS2R7coZAou9Ff BS2IlXxZc//8iyURJot+Byl/5npAQ2UzQQ1Hip2lDI7Xg67zgbtHDSCVClaIzZM8eH dgSbCSy5K0BZQYL9NICQSHazPNKDVX1y0Z6AhYH8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404773343; x=1404859743; i=@elandsys.com; bh=nhK/P3sbI++0XLrWxkOGEuqwOkkrOF+he3iR8hZkVJg=; h=Date:To:From:Subject:Cc; b=OLzJ+VKuxqb6hIE+T7tut1135U4MLGWm6b5xOP4UybJ1Czm6QzbCFJ+hwfshdcTqA RGa6gFsLQjkx2huofLoKB+xxp0Q99fXOZqsKBZXqX3mbyITQsmIabD+pXwLiRFGnkr kpTwS+Nw+k3FtlTZVdm/QYD2YSxrz/3HeIKPgAEE= Message-Id: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Jul 2014 15:34:43 -0700 To: "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/65a_atDmlNWSCOZrXjy4U99AF-c Cc: apps-discuss@ietf.org Subject: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-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: Mon, 07 Jul 2014 22:49:14 -0000 Hi Murray, I apologize for the long delay in sending the review of draft-ietf-appsawg-email-auth-codes-02. As an overall comment, should there be a comment in the registry as follows: "(Non-standards-track)"? In Section 3: "The following new status codes are defined:" I suggest mentioning "Enhanced" before "status codes". That applies to the title of that section too. From Section 3.1: "Code: X.7.20 Sample Text: No valid DKIM signature found Associated basic status code: 5" The digit "5" is not a basic status code. I suggest listing the basic status codes (see RFC 5321) or using the alternatives described in Section 2.1 of RFC 5248. In the above case you could use "550" as it is a local policy decision. From RFC 6371: "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." "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." It should be okay as there is a note about that in the first description in Section 3.1. "Sample Text: No valid author DKIM signature found Associated basic status code: 5 Description: This status code is returned when a message did not contain a valid DKIM signature matching the domain(s) found in the From header field, contrary to local policy requirements. (Note that this violates the advice of Section 6.1 of RFC6376.)" Please see my previous comment about the basic status code. Section 2.6 of RFC 6374 is about "Agent or User Identifier". There isn't any mention of "author DKIM signature". I gather that the request for two enhanced status codes is based on the identifiers mentioned in RFC 6374. From Section 3.2: "Code: X.7.22 Sample Text: SPF validation failed Associated basic status code: 5" And RFC 7208: "If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 and, if supported, the 5.7.1 enhanced status code" I suggest using "550" as the status code instead of "5". What should an implementation of RFC 7208 do? "Code: X.7.23 Sample Text: SPF validation error Associated basic status code: 5 Description: This status code is returned when evaluation of SPF relative to an arriving message resulted in an error." From RFC 7208: "If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported , the 4.4.3 enhanced status code" "If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code" What should an implementation of RFC 7208 do? From Section 3.3: "Code: X.7.24 Sample Text: Reverse DNS validation failed Associated basic status code: 5 Please see my first comment about basic status code. RFC 7001 is about communicating the results of message authentication efforts. Why is RFC 7001 being referenced for this enhanced status code? From Section 3.4: "Code: X.7.25 Sample Text: Multiple authentication checks failed Associated basic status code: 5" Please see my previous comment about basic status code. There was a discussion on the mailing list about what to do when the result is a combination of enhanced status codes. John Levine and Ned Freed commented about this [1][2]. "a message failed more than one message authentication check" does not convey much information to the other end as there isn't any definition of "authentication checks". There is a note in the description about the "specific mechanisms that failed are not specified". I suggest providing a reference to a specification or a clear description. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12094.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12102.html From nobody Mon Jul 7 18:07: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 A53CC1B29AE for ; Mon, 7 Jul 2014 18:07:23 -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 PxJve2a0_-mA for ; Mon, 7 Jul 2014 18:07:22 -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 608551B29A9 for ; Mon, 7 Jul 2014 18:07:21 -0700 (PDT) Received: (qmail 66416 invoked from network); 8 Jul 2014 01:07:20 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Jul 2014 01:07:20 -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=11467.53bb4448.k1406; i=johnl@user.iecc.com; bh=QhVbOrSBfKkkqPOt6ya5jvAYNRPWLEFXQnrN+rc4WlI=; b=PKEMBJIRXa272NaKpzQAgy/zToeOK5fZ0Sh2qcd/F7DrIOHAPasZYdLP5awX9pqE0eufHdvOyg88/EJVg56YV0UL9IPT7O/aZRc4tzo41kYFeI89qTfiRu7FVTBB6zXJVaAnvMu+l4B4GIc/etQ0RNnFs4CCOu8KJeUkewE9E/wAvpx4PJRgXwVTgNAH0nrMaoblbLJi1QHO0fOIKdWKcGOso+o33uZ8pTTm8twmL2zTZGCMmMCDsbXgSQ4N1zax 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=11467.53bb4448.k1406; olt=johnl@user.iecc.com; bh=QhVbOrSBfKkkqPOt6ya5jvAYNRPWLEFXQnrN+rc4WlI=; b=RrjVLerLyW02EW6F+pWwSXhasajFZQvFHsSmxfPakLySpwQAd5t+9wv0lKX3ChY1DdujloKsDVYoEYuO0yW/iahjAySAgJQWdskYMSuwlzmtMue5PQNFA0sWedklHS3HchRcU4yqjPJkPISYSAsyhJFwuJtKV8lODpXvjFtuum/Tibu2Lp00XhsNF55I3aWSQQITx0Osa+NxwyADZVaaIWTEPNWiTGOF1uDiWmI/UVTuO6Z31AzyHw0QXO4GxKRU Date: 8 Jul 2014 01:06:58 -0000 Message-ID: <20140708010658.70758.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/7hV1XBQpQtMpxau6xrjLJf4ShZo Subject: Re: [apps-discuss] Authentication-Results ptype extensions 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, 08 Jul 2014 01:07:23 -0000 >Are there enough people who would be willing to review/comment/support its >handling through APPSAWG? Sure, I'll kibitz. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nobody Mon Jul 7 22:14: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 94D7F1B2A3E for ; Mon, 7 Jul 2014 22:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 8mfJZzXe7p5Y for ; Mon, 7 Jul 2014 22:14:33 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6997D1B2A3D for ; Mon, 7 Jul 2014 22:14:33 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so5351851wes.19 for ; Mon, 07 Jul 2014 22:14:32 -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=1VVJ8POw8O1TtrNN5QylK1K2VwJmU86vYkgKs24ZnL4=; b=tJULdAjq10cBxEFXDiQvgqdYPkJFQQfLpZEmPCMLqFaYiM81u54GdVCt6DfdHqkFsx 4tEk2sH6QCpW6U/CKZB/EbOZb+n7LOuVgMyJdHUe5sdp4ZzjfcOLCDgKjUnfdxSkSJc0 JoPGYjELZu5+UjFkhdAeXPE+Y9RzfVM08ZmEoXYt0gWlFQRIPxt4xHNoHxdbqRsP6dW6 dtdO6A+EX/T3X7su/HrA/gaBiyEYkQ5olARPLgFs3Y/VQIT8Fo7h72uO50/Tsuo8Lpmo Wr79WbzEXh2F1SsHzEyyOiiTMLA0Q0lyICswuJcfK0aM1diuP8BWs0Lymoztnp8aAvMB Q2WQ== MIME-Version: 1.0 X-Received: by 10.180.189.79 with SMTP id gg15mr2520962wic.0.1404796471978; Mon, 07 Jul 2014 22:14:31 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Mon, 7 Jul 2014 22:14:31 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> References: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> Date: Mon, 7 Jul 2014 22:14:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c229d4b1b06404fda7aa29 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pxkX0ylN5Ju6C6MJH5WR1wsLUI0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-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: Tue, 08 Jul 2014 05:14:35 -0000 --001a11c229d4b1b06404fda7aa29 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 7, 2014 at 3:34 PM, S Moonesamy wrote: > I apologize for the long delay in sending the review of > draft-ietf-appsawg-email-auth-codes-02. > A late shepherd is better than no shepherd at all. :-) > As an overall comment, should there be a comment in the registry as > follows: "(Non-standards-track)"? > For these entries? I don't see why, as we're looking for Proposed Standard status here. In Section 3: > > "The following new status codes are defined:" > > I suggest mentioning "Enhanced" before "status codes". That applies to > the title of that section too. > Done. > From Section 3.1: > > "Code: X.7.20 > Sample Text: No valid DKIM signature found > Associated basic status code: 5" > > The digit "5" is not a basic status code. I suggest listing the basic > status codes (see RFC 5321) or using the alternatives described in Section > 2.1 of RFC 5248. In the above case you could use "550" as it is a local > policy decision. > Quite right. I've updated this in each case to be "5XX" or "4XX" to be consistent with existing entries in that registry. > > Section 2.6 of RFC 6374 is about "Agent or User Identifier". There isn't > any mention of "author DKIM signature". I gather that the request for two > enhanced status codes is based on the identifiers mentioned in RFC 6374. > (I assume you mean RFC 6376.) Right, DKIM itself makes no definition of an "author signature". The first place we ever saw that is ADSP (RFC5617), now Historic. Rather than cite a Historic RFC, I decided to give a brief definition here. To make the matching logic more specific, I suggest: Code: X.7.21 Sample Text: No valid author-aligned DKIM signature found Associated basic status code: 5XX Description: This status code is returned when a message did not contain a valid DKIM signature whose identifier(s) match the address(es) found in the From header field, contrary to local policy requirements. (Note that this violates the advice of Section 6.1 of RFC6376.) Reference: [this document]; RFC6376 Submitter: M. Kucherawy Change controller: IESG Does this satisfy your point? > From Section 3.2: > > "Code: X.7.22 > Sample Text: SPF validation failed > Associated basic status code: 5" > > And RFC 7208: > > "If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 and, if > supported, the 5.7.1 enhanced status code" > > I suggest using "550" as the status code instead of "5". What should an > implementation of RFC 7208 do? > I think you're looking at -02 rather than -03; this was addressed in -03. So, rather than saying "550 5.7.1" for the SPF "fail" case, an implementation of both RFC 7208 and this document would reply with "550 5.7.22". > "Code: X.7.23 > Sample Text: SPF validation error > Associated basic status code: 5 > Description: This status code is returned when evaluation > of SPF relative to an arriving message > resulted in an error." > > From RFC 7208: > > "If the message is rejected during the SMTP transaction for this reason, > the software SHOULD use an SMTP reply code of 451 and, if supported , > the 4.4.3 enhanced status code" > > "If the message is rejected during the SMTP transaction for this reason, > the software SHOULD use an SMTP reply code of 550 and, if supported, the > 5.5.2 enhanced status code" > > What should an implementation of RFC 7208 do? > Again, handled in -03. In the former case, rather than "451 4.4.3", it would use "451 4.7.23"; in the latter, rather than "550 5.5.2", it would use "550 5.7.23". RFC 7001 is about communicating the results of message authentication > efforts. Why is RFC 7001 being referenced for this enhanced status code? > It is the only document I know of that formally defines the common reverse DNS authentication check. There was a dnsop document that did so, but it was never published (as far as I know). > From Section 3.4: > > "Code: X.7.25 > Sample Text: Multiple authentication checks failed > Associated basic status code: 5" > > Please see my previous comment about basic status code. Addressed above. > There was a discussion on the mailing list about what to do when the > result is a combination of enhanced status codes. John Levine and Ned > Freed commented about this [1][2]. "a message failed more than one message > authentication check" does not convey much information to the other end as > there isn't any definition of "authentication checks". There is a note in > the description about the "specific mechanisms that failed are not > specified". I suggest providing a reference to a specification or a clear > description. > Consensus appeared (to me, at least) to settle on the idea that being able to report a multitude of failures is a "nice to have" that isn't worth the effort to specify at this time. The options left are: (1) Report a generic error (which we're trying to get away from here) using an existing code; (2) Report the first thing that failed (which isn't useful if that was expected); (3) Report a random one (ick); (4) Report that there were multiple failures. It seemed to end here: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12122.html Hope this resolves all of your questions. -MSK --001a11c229d4b1b06404fda7aa29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 7, 2014 at 3:34 PM, S Moonesamy <sm+ietf@e= landsys.com> wrote:
I apologize for the long = delay in sending the review of draft-ietf-appsawg-email-auth-codes-02.
<= /blockquote>

A late shepherd is better than no shepherd at all.=C2= =A0 :-)
=C2=A0
In Section 3:

=C2=A0 "The following new status codes are defined:"

I suggest mentioning "Enhanced" before "status codes". = =C2=A0That applies to the title of that section too.
<= br>
Done.
=C2=A0
>From Section 3.1:

=C2=A0 =C2=A0 =C2=A0"Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 X.7.20
=C2=A0 =C2=A0 =C2=A0 Sample Text: =C2=A0 =C2=A0 =C2=A0 =C2=A0No valid DKIM = signature found
=C2=A0 =C2=A0 =C2=A0 Associated basic status code: =C2=A05"

The digit "5" is not a basic status code. =C2=A0I suggest listing= the basic status codes (see RFC 5321) or using the alternatives described = in Section 2.1 of RFC 5248. =C2=A0In the above case you could use "550= " as it is a local policy decision.

Quite right.=C2=A0 I've updated this i= n each case to be "5XX" or "4XX" to be consistent with = existing entries in that registry.
=C2=A0

Section 2.6 of RFC 6374 is about "Agent or User Identifier". =C2= =A0There isn't any mention of "author DKIM signature". =C2=A0= I gather that the request for two enhanced status codes is based on the ide= ntifiers mentioned in RFC 6374.

(I assume you mean RFC 6376.)=C2=A0 Right,= DKIM itself makes no definition of an "author signature".=C2=A0 = The first place we ever saw that is ADSP (RFC5617), now Historic.=C2=A0 Rat= her than cite a Historic RFC, I decided to give a brief definition here.
To make the matching logic more specific, I suggest:

= =C2=A0=C2=A0 Code:=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=C2=A0 X.7.21
=C2=A0=C2=A0 Sample Text:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No valid author-aligned DKIM signature found=
=C2=A0=C2=A0 Associated basic status code:=C2=A0 5XX
=C2=A0=C2=A0 De= scription:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This status code is re= turned 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 did not contain a= valid DKIM signature
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 whose identifier(s) match the address(es)
=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=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 found in the From header field, con= trary to
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local= policy requirements.=C2=A0 (Note that this
=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 violates the advi= ce of Section 6.1 of RFC6376.)
=C2=A0=C2=A0 Reference:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [this document]; RFC6376
=C2=A0=C2= =A0 Submitter:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 M. Kuc= herawy
=C2=A0=C2=A0 Change controller:=C2=A0 IESG

Does= this satisfy your point?
=C2=A0

=C2=A0 =C2=A0 =C2=A0"Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 X.7.23
=C2=A0 =C2=A0 =C2=A0 Sample Text: =C2=A0 =C2=A0 =C2=A0 =C2=A0SPF validation= error
=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 evaluation
=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 of SPF relative to an arriving 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 resulted in an error."

>From RFC 7208:

=C2=A0 "If the message is rejected during the SMTP transaction for thi= s reason,
=C2=A0 =C2=A0the software SHOULD use an SMTP reply code of 451 and, if supp= orted ,
=C2=A0 =C2=A0the 4.4.3 enhanced status code"

=C2=A0 "If the message is rejected during the SMTP transaction for thi= s reason,
=C2=A0 =C2=A0the software SHOULD use an SMTP reply code of 550 and, if supp= orted, the
=C2=A0 =C2=A05.5.2 enhanced status code"

What should an implementation of RFC 7208 do?

Again, handled in -03.=C2=A0 In the former case, rather than "4= 51 4.4.3", it would use "451 4.7.23"; in the latter, rather = than "550 5.5.2", it would use "550 5.7.23".

RFC 7001 is about communicating the results of message authentication effor= ts. =C2=A0Why is RFC 7001 being referenced for this enhanced status code?

It is the only document I know of that f= ormally defines the common reverse DNS authentication check.=C2=A0 There wa= s a dnsop document that did so, but it was never published (as far as I kno= w).
=C2=A0
>From Section 3.4:

=C2=A0 =C2=A0 =C2=A0 "Code: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 X.7.25
=C2=A0 =C2=A0 =C2=A0 Sample Text: =C2=A0 =C2=A0 =C2=A0 =C2=A0Multiple authe= ntication checks failed
=C2=A0 =C2=A0 =C2=A0 Associated basic status code: =C2=A05"

Please see my previous comment about basic status code. =C2=A0
=

Addressed above.
=C2=A0
There was a discussion on the mailing list about what to do when the result= is a combination of enhanced status codes. =C2=A0John Levine and Ned Freed= commented about this [1][2]. =C2=A0"a message failed more than one me= ssage authentication check" does not convey much information to the ot= her end as there isn't any definition of "authentication checks&qu= ot;. =C2=A0There is a note in the description about the "specific mech= anisms that failed are not specified". =C2=A0I suggest providing a ref= erence to a specification or a clear description.

Consensus appeared (to me, at least) to se= ttle on the idea that being able to report a multitude of failures is a &qu= ot;nice to have" that isn't worth the effort to specify at this ti= me.=C2=A0 The options left are:

(1) Report a generic error (which we're trying to get aw= ay from here) using an existing code;

(2) Report the firs= t thing that failed (which isn't useful if that was expected);

(3) Report a random one (ick);

(4) Report that there were= multiple failures.

It seemed to end here:

http://ww= w.ietf.org/mail-archive/web/apps-discuss/current/msg12122.html

Hope this resolves all of your questions.

= -MSK
--001a11c229d4b1b06404fda7aa29-- From nobody Mon Jul 7 23:51: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 E11D11B2A7A for ; Mon, 7 Jul 2014 23:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, 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 Nd8Ng_I85S4B for ; Mon, 7 Jul 2014 23:51:00 -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 B428B1B2A78 for ; Mon, 7 Jul 2014 23:51:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s686odRv009883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 23:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404802258; x=1404888658; bh=CAcsoZA+zD8KcRvu/a37VrxPxlhZZi3Dso4+2FdHnGM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gZxiTDCQg5uw28Mbn654KI2OcngRfhcr+nkFZqeEMbS/tPxk5tkxxLGOXbsjc7Fhl FMu2QbZ9hnRNPRfU6tBb31AluiC2Abe75eIqsKsk4SM7TnVLSuUUQfHRRlrXFvz3x7 k7DJFI64dWdg1bUxKcNIJP+xtCURQqROcqqilIeY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404802258; x=1404888658; i=@elandsys.com; bh=CAcsoZA+zD8KcRvu/a37VrxPxlhZZi3Dso4+2FdHnGM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PURA5TfZxIRd3xxenhzgIJdgqM3qhn9UIfyjL0oVj2DsdAbJBGpxbnxVGHUxEfJEf ZQYSVlBFdxvC5tYeAVZDABNreiVX9T3MheM0WRfe5ciz39kxBZn2Q8AQnyoKVH2yxY t4KFDJqLXjYOE0MjKi4aNmqErTZGfmsuFTTvLpHM= Message-Id: <6.2.5.6.2.20140707223625.0d268100@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Jul 2014 23:48:09 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4TmkmAKK7k0_HBAmDEtK2hfIxdc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-03 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, 08 Jul 2014 06:51:02 -0000 Hi Murray, At 22:14 07-07-2014, Murray S. Kucherawy wrote: >A late shepherd is better than no shepherd at all.=C2 :-) :-) >As an overall comment, should there be a comment=20 >in the registry as follows: "(Non-standards-track)"? > > >For these entries? I don't see why, as we're=20 >looking for Proposed Standard status here. See comment below about my reading of the wrong=20 version of the draft. Please disregard the above question. > From Section 3.1: > > "Code: X.7.20 > Sample Text: No valid DKIM signature found > Associated basic status code: 5" > >The digit "5" is not a basic status code. I=20 >suggest listing the basic status codes (see RFC=20 >5321) or using the alternatives described in=20 >Section 2.1 of RFC 5248. In the above case you=20 >could use "550" as it is a local policy decision. > > >Quite right. I've updated this in each case to=20 >be "5XX" or "4XX" to be consistent with existing entries in that registry. I'll suggest being specific in this case (550) as it is a policy decision. >Section 2.6 of RFC 6374 is about "Agent or User=20 >Identifier". There isn't any mention of "author=20 >DKIM signature". I gather that the request for=20 >two enhanced status codes is based on the identifiers mentioned in RFC= 6374. > > >(I assume you mean RFC 6376.) Right, DKIM=20 >itself makes no definition of an "author=20 >signature". The first place we ever saw that is=20 >ADSP (RFC5617), now Historic. Rather than cite=20 >a Historic RFC, I decided to give a brief definition here. > >To make the matching logic more specific, I suggest: > > Code: X.7.21 > Sample Text: No valid author-aligned DKIM signature= found > Associated basic status code: 5XX > Description: This status code is returned when a= message > did not contain a valid DKIM signature > whose identifier(s) match the address(es) > found in the From header field, contrary= to > local policy requirements. (Note that= this > violates the=20 > advice of Section 6.1 of RFC6376.) > Reference: [this document]; RFC6376 > Submitter: M. Kucherawy > Change controller: IESG > >Does this satisfy your point? I'd say use "550" instead of 5XX as this is again=20 local policy. I took a look at RFC 6376=20 again. In my opinion the above description is=20 clear. If nobody in the working group considers=20 the sample text as a problem I'll consider the sample text as good enough. > From Section 3.2: > > "Code: X.7.22 > Sample Text: SPF validation failed > Associated basic status code: 5" > >And RFC 7208: > > "If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 and, if > supported, the 5.7.1 enhanced status code" > >I suggest using "550" as the status code instead=20 >of "5". What should an implementation of RFC 7208 do? > > >I think you're looking at -02 rather than -03;=20 >this was addressed in -03. So, rather than=20 >saying "550 5.7.1" for the SPF "fail" case, an=20 >implementation of both RFC 7208 and this=20 >document would reply with "550 5.7.22". I thought that I was reviewing the wrong version=20 of the draft. tools.ietf.org was showing -02 as=20 the latest. I got -03 when I entered that version in the draft name. The draft will have to mention why RFC 7208 is=20 being updated. You can have the text in the Abstract or the Introduction. > "Code: X.7.23 > Sample Text: SPF validation error > Associated basic status code: 5 > Description: This status code is returned when= evaluation > of SPF relative to an arriving message > resulted in an error." > > From RFC 7208: > > "If the message is rejected during the SMTP transaction for this reason, > the software SHOULD use an SMTP reply code of 451 and, if supported , > the 4.4.3 enhanced status code" > > "If the message is rejected during the SMTP transaction for this reason, > the software SHOULD use an SMTP reply code of 550 and, if supported,= the > 5.5.2 enhanced status code" > >What should an implementation of RFC 7208 do? > > >Again, handled in -03. In the former case,=20 >rather than "451 4.4.3", it would use "451=20 >4.7.23"; in the latter, rather than "550 5.5.2", it would use "550 5.7.23". Could you add the basic status code instead of "4/5"? >RFC 7001 is about communicating the results of=20 >message authentication efforts. Why is RFC 7001=20 >being referenced for this enhanced status code? > > >It is the only document I know of that formally=20 >defines the common reverse DNS authentication=20 >check. There was a dnsop document that did so,=20 >but it was never published (as far as I know). I suggest using "550" for this. The description=20 text is clear to me. I'll say okay to this. > From Section 3.4: > > "Code: X.7.25 > Sample Text: Multiple authentication checks failed > Associated basic status code: 5" > >Please see my previous comment about basic status code. > > >Addressed above. Ok. >Consensus appeared (to me, at least) to settle=20 >on the idea that being able to report a=20 >multitude of failures is a "nice to have" that=20 >isn't worth the effort to specify at this time.=C2 The options left are: > >(1) Report a generic error (which we're trying=20 >to get away from here) using an existing code; > >(2) Report the first thing that failed (which=20 >isn't useful if that was expected); > >(3) Report a random one (ick); > >(4) Report that there were multiple failures. > >It seemed to end here: > >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12122.html > >Hope this resolves all of your questions. I just noticed that the term "email=20 authentication" is used in Section 1. I'll=20 suggest replacing that with "message=20 authentication". I read Section 4 of -03. In my=20 opinion it provides a balanced view of what is=20 being proposed and what is being violated. As=20 there is also WG Consensus on this I don't see=20 any reason not to proceed with the existing text. As a note to the working group, I didn't see any=20 strong disagreement about this=20 specification. Please email me if I missed a message about that. Regards, S. Moonesamy From nobody Mon Jul 7 23:51: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 D0D6E1B2A7C; Mon, 7 Jul 2014 23:51:07 -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 atGv38H0Hdqr; Mon, 7 Jul 2014 23:51:06 -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 6E6E01B2A7E; Mon, 7 Jul 2014 23:51:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s686odRt009883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 23:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1404802253; x=1404888653; bh=7/ZVnbuiz7zN1vNza9psxgr5t6+IGhf0ojTipvPYikU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tnfeJ9mSC1BTRtj3phfzepSIBOVH+5HHAeDXbIwqaG7SHa0uBZLUhIhNde35P+3eU MXdp2YYbSXls1xO5+X8fGzw+dxtwejyZYTx+OC3WCWikpnnvLFfg7qAcHblGkz8R/o km5O0ObvoUkojmf2xThjzfslDesL0jcSYW8u/clE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1404802253; x=1404888653; i=@elandsys.com; bh=7/ZVnbuiz7zN1vNza9psxgr5t6+IGhf0ojTipvPYikU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qyvz8n/wuEhyBc8QrArh0iQ+Z8Bl2OmRVL1FHDHI6Wws9hW6giMaj/TjrwFwcsqbT h+kKkZtj6+Vf75i8BV2qTO617YGbVBbDhrz0WARrDfCdOD1xbX6hrSkk0/cXNGtFUf 3uHdJKG9ENT1a0fBo1qWaYglXt+CTc0TCq+p5Pt8= Message-Id: <6.2.5.6.2.20140707205821.0d66af00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Jul 2014 21:15:25 -0700 To: Cyrus Daboo , Pete Resnick , Barry Leiba From: S Moonesamy In-Reply-To: <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pZFSLLNpVSq6cCnAQlPmXAYRCDE Cc: iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 06:51:08 -0000 Hi Cyrus, At 09:34 07-07-2014, Cyrus Daboo wrote: >During apps-discuss discussion, it was suggested that we might want >to digitally sign the time zone data, rather than just rely on >transport layer security (TLS) to validate the data service server. >If we opt for such a thing, we may want to have the Olson data >signed in a more reliable manner than at present. RFC 6557 did >indicate that IANA would be in charge of maintaining the private key >used to sign the data, but I think right now the available signature >is created using the TZ co-ordinator's own private key. The above has never been mentioned on the TZ mailing list. I suggest discussing about that on the TZ mailing list if it is considered as a security issue. Regards, S. Moonesamy From nobody Tue Jul 8 00:21: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 4CD701B2A7B for ; Tue, 8 Jul 2014 00:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 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, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 0r7Dc50Fr2UJ for ; Tue, 8 Jul 2014 00:21:31 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695D01B2939 for ; Tue, 8 Jul 2014 00:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1404804089; bh=5iusI5Yok+8B6hY+ovXCsUOlwNLeiVaCgTA1ltJ8VPU=; l=293; h=Date:From:To:References:In-Reply-To; b=orwZZ6bDcn0+ayr+ECcKKPJxRFm/l/gAmBnqiku82Nc2N9+198ySfGPRF9iTjPpQv E1NmHyy/g1D/1VoearOauCOJM1ZRW0M9p7cKYCxwGCniVBWSe+Mgz7yjX3u7vaDwrf Czsm7lInlUXEpOR1ADp16ZI5VE5sVVmz8ab+Eg/c= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 08 Jul 2014 09:21:29 +0200 id 00000000005DC039.0000000053BB9BF9.0000074D Message-ID: <53BB9BF8.5080002@tana.it> Date: Tue, 08 Jul 2014 09:21:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fow1WoZvJL90OLcO-46Oz1FNQfE Subject: Re: [apps-discuss] Authentication-Results ptype extensions 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, 08 Jul 2014 07:21:32 -0000 On Mon 07/Jul/2014 23:35:13 +0200 Murray S. Kucherawy wrote: > > http://datatracker.ietf.org/doc/draft-kucherawy-authres-ptypes-registry/ > > Are there enough people who would be willing to review/comment/support > its handling through APPSAWG? +1, a needful amendment to 7001 Ale From nobody Tue Jul 8 00:39: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 B4D1E1B2A88 for ; Tue, 8 Jul 2014 00:39:11 -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 C5dGQgvCdCBa for ; Tue, 8 Jul 2014 00:39:09 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BB51B297F for ; Tue, 8 Jul 2014 00:39:09 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so434455wiw.4 for ; Tue, 08 Jul 2014 00:39: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=5lgnoclKgMk/rL3RauaOr+Q6q8pLASnD01h6As/0NHs=; b=NhJcn1YyVpdsyErdZ5aMtrhfsi7zx2UTA7CCGfYP6iKBPeCvv6TL5DzhVCGIHsrP/l 8Thx8vr3S92wvempSchS69wOZztsreQX8XZe2UysrcgJCoCUqWlRwkma8D10VSEnoVhM BuGVkcFFCOlOYEZhnCVWPZyF+hJJDdojFZUBDthcxC84sgQkblgUqZwuq3dmMQH/7iCH zP1DF5WOlBV610005MpsrdW4HGDlRXUwCSf8IhvTDehCJa1FZM7oVDbIcV5McxbjCNki 17mRpJw6TlBuoE2RNGYHAymzzmk9uqKZCF6xfodiuezN+X7OB0+t3e3uWlSCQ8+zfnMT ZjaQ== MIME-Version: 1.0 X-Received: by 10.180.10.168 with SMTP id j8mr1715830wib.73.1404805148096; Tue, 08 Jul 2014 00:39:08 -0700 (PDT) Received: by 10.180.19.74 with HTTP; Tue, 8 Jul 2014 00:39:08 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140707223625.0d268100@elandnews.com> References: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> <6.2.5.6.2.20140707223625.0d268100@elandnews.com> Date: Tue, 8 Jul 2014 00:39:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c25918d4bf6404fda9af7c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RQxn6CwJFWU6kFj5i7Qvwv5iN4Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-03 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, 08 Jul 2014 07:39:11 -0000 --001a11c25918d4bf6404fda9af7c Content-Type: text/plain; charset=UTF-8 On Mon, Jul 7, 2014 at 11:48 PM, S Moonesamy wrote: > > Quite right. I've updated this in each case to be "5XX" or "4XX" to be >> consistent with existing entries in that registry. >> > > I'll suggest being specific in this case (550) as it is a policy decision. > OK. > The draft will have to mention why RFC 7208 is being updated. You can > have the text in the Abstract or the Introduction. > > "Code: X.7.23 >> Sample Text: SPF validation error >> Associated basic status code: 5 >> Description: This status code is returned when >> evaluation >> of SPF relative to an arriving message >> resulted in an error." >> >> From RFC 7208: >> >> "If the message is rejected during the SMTP transaction for this reason, >> the software SHOULD use an SMTP reply code of 451 and, if supported , >> the 4.4.3 enhanced status code" >> >> "If the message is rejected during the SMTP transaction for this reason, >> the software SHOULD use an SMTP reply code of 550 and, if supported, >> the >> 5.5.2 enhanced status code" >> >> What should an implementation of RFC 7208 do? >> >> >> Again, handled in -03. In the former case, rather than "451 4.4.3", it >> would use "451 4.7.23"; in the latter, rather than "550 5.5.2", it would >> use "550 5.7.23". >> > > Could you add the basic status code instead of "4/5"? > Yes, I've added 451 and 550. > > I just noticed that the term "email authentication" is used in Section 1. > I'll suggest replacing that with "message authentication". OK. > I read Section 4 of -03. In my opinion it provides a balanced view of > what is being proposed and what is being violated. As there is also WG > Consensus on this I don't see any reason not to proceed with the existing > text. > > As a note to the working group, I didn't see any strong disagreement about > this specification. Please email me if I missed a message about that. > I'll send -04 to the tracker now with these changes, and ask Barry to approve it. Thanks! -MSK --001a11c25918d4bf6404fda9af7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 7, 2014 at 11:48 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:

Quite right. =C2=A0I've updated this in each case to be "5XX"= or "4XX" to be consistent with existing entries in that registry= .

I'll suggest being specific in this case (550) as it is a policy decisi= on.

OK.
=C2=A0
The draft will have to mention why RFC 7208 is being updated. =C2=A0You can= have the text in the Abstract or the Introduction.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Code: =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 X.7.23
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sample Text: = =C2=A0 =C2=A0SPF validation error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Associated ba= sic status code: =C2=A05
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Description: = =C2=A0 =C2=A0This status code is returned when evaluation
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0of SPF relative to an arriving= 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0resulted in an error."
>From RFC 7208:

=C2=A0 "If the message is rejected during the SMTP transaction for thi= s reason,
=C2=A0 =C2=A0the software SHOULD use an SMTP reply code of 451 and, if supp= orted ,
=C2=A0 =C2=A0the 4.4.3 enhanced status code"

=C2=A0 "If the message is rejected during the SMTP transaction for thi= s reason,
=C2=A0 =C2=A0the software SHOULD use an SMTP reply code of 550 and, if supp= orted, the
=C2=A0 =C2=A05.5.2 enhanced status code"

What should an implementation of RFC 7208 do?


Again, handled in -03. =C2=A0In the former case, rather than "451 4.4.= 3", it would use "451 4.7.23"; in the latter, rather than &q= uot;550 5.5.2", it would use "550 5.7.23".

Could you add the basic status code instead of "4/5"?

Yes, I've added 451 and 550.
=C2=A0

I just noticed that the term "email authentication" is used in Se= ction 1. =C2=A0I'll suggest replacing that with "message authentic= ation".

OK.
=C2=A0
I read Section 4 of -03. =C2=A0In my opinion it provides a balanced view o= f what is being proposed and what is being violated. =C2=A0As there is also= WG Consensus on this I don't see any reason not to proceed with the ex= isting text.

As a note to the working group, I didn't see any strong disagreement ab= out this specification. =C2=A0Please email me if I missed a message about t= hat.

I'll send -04 to the tracker n= ow with these changes, and ask Barry to approve it.

Thanks!

-MSK
--001a11c25918d4bf6404fda9af7c-- From nobody Tue Jul 8 05:59: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 BB46C1B2853; Tue, 8 Jul 2014 05:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 oAzHeehV7Clp; Tue, 8 Jul 2014 05:59:11 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6201B2828; Tue, 8 Jul 2014 05:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404824353; x=1436360353; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=udwbCHo4uqwgmB+lJnOPgzyaMf+gfrX6y0nG/scYVTk=; b=vGbRmKX8mJCthNapOQ3zDEJC2S1C98NtJeSe9edrTijjC/tgEQKBzeHk 0AhwZNI1BpZXsMIGVbgmjhr3jRZryFPZS+pbKZuGguhdQP88y8DlrF0e/ Mh4sSqJFMC10PioYC3OuCx0aq1sTIgm7G0xonh7Occ+5jWewwv1qqAoGL E=; X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="69113918" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 08 Jul 2014 05:59:12 -0700 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="763037618" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2014 05:59:10 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 05:59:09 -0700 Message-ID: <53BB374D.5000705@qti.qualcomm.com> Date: Tue, 8 Jul 2014 03:11:57 +0300 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Cyrus Daboo References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> In-Reply-To: <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LKRMfwF5ueeC97TQbonHfg-rQ1g Cc: Barry Leiba , IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 12:59:13 -0000 On 7/7/14 7:34 PM, Cyrus Daboo wrote: > During apps-discuss discussion, it was suggested that we might want to > digitally sign the time zone data, rather than just rely on transport > layer security (TLS) to validate the data service server. If we opt > for such a thing, we may want to have the Olson data signed in a more > reliable manner than at present. RFC 6557 did indicate that IANA would > be in charge of maintaining the private key used to sign the data, but > I think right now the available signature is created using the TZ > co-ordinator's own private key. Aha. Then might I suggest an edit so that we're a bit more specific and it does not appear (as SM interpreted) that we're possibly going to step on toes. (The following was written on a very long plane flight. Wordsmithing may be necessary.) OLD - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of what is distributed. Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. The following are Out of scope for the working group: - Any changes to the Time Zone Database process or infrastructure, as documented in RFC 6557, other than recommendations for possible security enhancements. NEW - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of what is distributed, including the ability to communicate that the data received from its original source, such as the Time Zone Database, has maintained integrity. Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. The following are Out of scope for the working group: - Any changes to the Time Zone Database process or infrastructure, as documented in RFC 6557. However, the WG may work with IANA in order to make integrity checking information, like public keys, readily accessible for protocol use. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jul 8 06:24: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 8861F1B283C for ; Tue, 8 Jul 2014 06:24:02 -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 k98aCsvd18zQ for ; Tue, 8 Jul 2014 06:24:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20AE1B283B for ; Tue, 8 Jul 2014 06:24:00 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.242.155.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 00D6922E255 for ; Tue, 8 Jul 2014 09:23:53 -0400 (EDT) Message-ID: <53BBF0F0.9000006@seantek.com> Date: Tue, 08 Jul 2014 06:24:00 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XqpUD-ZRMouATr9c5G07RfZx5Ic Subject: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00 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, 08 Jul 2014 13:24:02 -0000 Hello Apps-Discuss: A new Internet-Draft has been posted, proposing the text/markdown media=20 type to identify Markdown content. http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 Markdown is a family of lightweight markup languages (aka plain text=20 formatting syntaxes) designed to make it easy to read and write in plain = text, with the intention of having tools process the text into formal=20 markup languages, namely (X)HTML. This media type is specifically=20 intended to identify Markdown text, i.e., text intended for the Markdown = tool or its derivatives. References: http://en.wikipedia.org/wiki/Markdown http://daringfireball.net/projects/markdown/ This is sort of a strawman proposal. I definitely got interest off-list; = the respondents encouraged me to write up a draft-00 for this list to=20 review. I look forward to broader comments and participation from the=20 Internet community, especially users of Markdown and authors of Markdown = tools. Name: draft-seantek-text-markdown-media-type Revision: 00 Title: The text/markdown Media Type Document date: 2014-07-08 Group: Individual Submission Pages: 9 URL:=20 http://www.ietf.org/internet-drafts/drat-seantek-text-markdown-media-type= -00.txt Status:=20 https://datatracker.ietf.org/doc/draft-seantek-text-markdown-media-type/ Regards, Sean Leonard From nobody Tue Jul 8 06:32: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 EF5CD1B2837 for ; Tue, 8 Jul 2014 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 v9j2SvXa2rIg for ; Tue, 8 Jul 2014 06:32:34 -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 C8A5A1B283E for ; Tue, 8 Jul 2014 06:32:34 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D7497D0454F; Tue, 8 Jul 2014 09:32:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1404826353; bh=lQ60pcWkuElRfxh4Nf2F3U7EHXvJWNQaYtMUjQ5eYs4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eFOpRvtIWfzePg1SCkgYGLpguC88HElK5/uE9VsebfiCAksBtYmH7LIjCCglMo/+c WJwGtGBoFxpLoHSeRvEnl9j5OjlGqO/6Cw8YsOGrM54MV50mzLs62J4yQlxD9+JSUL kSDuTD+6ygFK6BWJspt6uiGmsdwrZ8UzCFHc2t3I= 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 AE2A0D041D1; Tue, 8 Jul 2014 09:32:33 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 08 Jul 2014 09:32:33 -0400 Message-ID: <2774177.Ekz3rNHmln@scott-latitude-e6320> User-Agent: KMail/4.13.2 (Linux/3.13.0-30-generic; KDE/4.13.2; x86_64; ; ) In-Reply-To: References: <6.2.5.6.2.20140707141221.0b46a0c0@elandnews.com> <6.2.5.6.2.20140707223625.0d268100@elandnews.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/SP3qxtOdg5eF_Ch7eC4X6Amu_Yk Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-email-auth-codes-03 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, 08 Jul 2014 13:32:36 -0000 On Tuesday, July 08, 2014 00:39:08 Murray S. Kucherawy wrote: > > Could you add the basic status code instead of "4/5"? > > Yes, I've added 451 and 550. I did check and 451/550 are what RFC 7208 suggests if deferring/rejecting, so that's consistent. Scott K From nobody Tue Jul 8 06: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 81EE01B27AC; Tue, 8 Jul 2014 06:55:45 -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 53QV2KN5SD9h; Tue, 8 Jul 2014 06:55:44 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010: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 EB0501B27A0; Tue, 8 Jul 2014 06:55:43 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so4038118lan.30 for ; Tue, 08 Jul 2014 06:55:42 -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=nVQjgaoxWYKRP8LQudCvVlpqRWFC0PCFRNRLvtrujWI=; b=eEX/YcD6sfQKt9hPRi0oi24K8scUSzdcT7RsmMANy0dO/gaVmWGRn5DBxD1psmBIKn 9DfuLXDJSqE0u36tEONbUKlpX7xc6iKpycAjQVuk47CdD5yZIcamxGzcv8xtr7Iwv8Mn B9ASz1WaQ2fO1FeaFFyyi2F41Kv095kfCIqgQ1AV/fMcScTA3vAUG6saAOcI1FeRAyGA 2HAu/XcGACesx4US+o61sfdk8cbhkpG5cVckOf5QCgbf8DEMZ+ZViOfV4ZidMlr5CSic 9oI6w4TcMzqcKHSDw+aSTQyGDMalBo2rUKcZnU0vNtN41jjrVqGK5Ymjv+x9buRO4hMB NNsA== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr26408342lbc.16.1404827741898; Tue, 08 Jul 2014 06:55:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 8 Jul 2014 06:55:41 -0700 (PDT) In-Reply-To: <53BB374D.5000705@qti.qualcomm.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> Date: Tue, 8 Jul 2014 09:55:41 -0400 X-Google-Sender-Auth: aHw0XiN1_Zf38JNBiNuwoVuvpCk Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Wmx6RIpv1DNKDoJF9SQtgvlvcqk Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 13:55:45 -0000 > - The time zone data distribution protocol will use current security > protocols to protect the integrity and confidentiality of what is > distributed, including the ability to communicate that the data > received from its original source, such as the Time Zone Database, > has maintained integrity. Even public time zone data can represent a > significant privacy exposure when it is associated with the user or > endpoint that is retrieving it. I don't strongly object to the change, but I don't see the benefit of it. The sentence starts by saying that it will protect integrity, and you're adding "the ability to communicate" that integrity happened. While we might or might not want to have that, it seems an odd thing to call out at the charter level, rather than leaving it for the protocol. > The following are Out of scope for the working group: > > - Any changes to the Time Zone Database process or infrastructure, > as documented in RFC 6557. However, the WG may work with IANA > in order to make integrity checking information, like public keys, > readily accessible for protocol use. This looks fine to me (modulo changing "like" to "such as", which I will do). Isn't this part sufficient to address your concern, Pete? Barry From nobody Tue Jul 8 07:04: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 509241B27A0; Tue, 8 Jul 2014 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 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_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 vcSq1ORH_7CZ; Tue, 8 Jul 2014 07:04:34 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0251A0410; Tue, 8 Jul 2014 07:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404828275; x=1436364275; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qmhJq3rFzfSBQLcQPvXm0utpJLpgFr3qh3HXoxolT/k=; b=lDNr27om7yo5A10sL63C1KPHDA8TWxlO3b++vc0hYYSbauSR+gYCCkNE NLpNRbHeRaIYZhMtU81zMYv1Mf99baXNp0wcQgzFQA+Mo/s8jdvc3wwPg lgJrVU8wxwVcjd5vwThA+mZNwHUsYyzE7ae+z1HJSKzq9TpjRwYsDkMmq U=; X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="69116363" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 08 Jul 2014 07:04:34 -0700 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="763060279" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2014 07:04:33 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 07:04:31 -0700 Message-ID: <53BBFA6E.7070107@qti.qualcomm.com> Date: Tue, 8 Jul 2014 09:04:30 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CoQCqhGUD_qweqHId4mrMvRqZLE Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 14:04:38 -0000 On 7/8/14 8:55 AM, Barry Leiba wrote: >> - The time zone data distribution protocol will use current security >> protocols to protect the integrity and confidentiality of what is >> distributed, including the ability to communicate that the data >> received from its original source, such as the Time Zone Database, >> has maintained integrity. Even public time zone data can represent a >> significant privacy exposure when it is associated with the user or >> endpoint that is retrieving it. >> > I don't strongly object to the change, but I don't see the benefit of > it. The sentence starts by saying that it will protect integrity, and > you're adding "the ability to communicate" that integrity happened. > While we might or might not want to have that, it seems an odd thing > to call out at the charter level, rather than leaving it for the > protocol. > So the point I was *trying* to make (brain damage notwithstanding) was that TLS provides integrity, but not the kind that Cyrus was talking about here. TLS provides integrity of the data between the tz dist server and client, but not between the original data (i.e., the Time Zone Database) and the client. And since we're mentioning something about it below, I thought it was worth explicitly calling out. But if you think it's covered in the original, I'm OK with that. >> The following are Out of scope for the working group: >> >> - Any changes to the Time Zone Database process or infrastructure, >> as documented in RFC 6557. However, the WG may work with IANA >> in order to make integrity checking information, like public keys, >> readily accessible for protocol use. >> > This looks fine to me (modulo changing "like" to "such as", which I > will do). Isn't this part sufficient to address your concern, Pete? > Yep. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jul 8 07:09: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 2DDFD1A0028 for ; Tue, 8 Jul 2014 07:09:50 -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 VK6LsWOTiDXh for ; Tue, 8 Jul 2014 07:09:48 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855C71B27BC for ; Tue, 8 Jul 2014 07:09:48 -0700 (PDT) Received: from 77-56-165-193.dclient.hispeed.ch ([77.56.165.193] 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 1X4W5a-00089J-8Q; Tue, 08 Jul 2014 07:09:48 -0700 Message-ID: <53BBFBA2.5090801@berkeley.edu> Date: Tue, 08 Jul 2014 16:09:38 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <53BBF0F0.9000006@seantek.com> In-Reply-To: <53BBF0F0.9000006@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/52VpeTdyEwcsBMvBxYfc2HkQVdE Subject: Re: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00 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, 08 Jul 2014 14:09:50 -0000 hello sean. On 2014-07-08, 15:24, Sean Leonard wrote: > A new Internet-Draft has been posted, proposing the text/markdown media > type to identify Markdown content. > http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 it would definitely be great to be able to identify markdown with a media type. i also like the idea of the "flavor" parameter, because afaict, there is a fair number of variations floating around. have you considered using "profile" instead of the more specific "flavor" concept? http://tools.ietf.org/html/rfc6906 defines profiles, and they are defined to be URIs. they can be identified with "profile"-typed links, and the RFC also recommends to support a "profile" parameter on the media type. http://tools.ietf.org/html/draft-wilde-atom-profile is a draft where i am trying to do this for atom. the idea was that this draft could be used as a template for any media that would like to start supporting profile as a media type parameter (the source is available at http://tools.ietf.org/html/draft-wilde-atom-profile). in addition to profiles as a lightweight mechanism that works with links, http://tools.ietf.org/html/rfc7284 establishes a registry for profiles. authors of markdown flavors could choose to register the URI that they recommend to use as a profile URI, or they could elect to not register and either make the URI self-documenting, or make people google it and find information that way. either way, profiles could be used for your flavor concept, thus avoiding the need for yet another registry. the necessary change, though, would be to use URIs as identifiers, instead of the strings that you are currently using. 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 Jul 8 07:10: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 A5CA21A0028; Tue, 8 Jul 2014 07:10:04 -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 p0MI-2nsoXwE; Tue, 8 Jul 2014 07:09:58 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35C01B2ADC; Tue, 8 Jul 2014 07:09:57 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so4054295lbv.28 for ; Tue, 08 Jul 2014 07:09: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=ZWeOisWRHo1TRQn1IZErordOS3K1wItQBFDnWTw89Kg=; b=cZuNhUk8ERLy6LDwyulsInnoMYeAttvwwl/Ak0acMKr3rjDmLmZO7v6mOhWSv9J0eB FN545JanyRZHL7lZHkUXua/8KtV7YC98kv7A+e6Rkq3V/hJYOd6dr7Ct+AqdsFGaSrdz 9sgiJKDsOsDkogBLvWILxWxp2axJFsq1zmG0ciFQX0EW1Ee1Z40hGtdtmCqpukxWVHGs UKKya7gkKegrdrJgyZteTlKYFJUYljH0IYFUY8QF+5QKX9/9qPvoLQRwlq18lrf0BH0O STJNX9KcmcHX6aiysYzl8b6m68pPT1ryYruI+jChKDd+KYNTPIm/Y8e7905NwBGbyXje QdiA== MIME-Version: 1.0 X-Received: by 10.152.204.102 with SMTP id kx6mr28812851lac.32.1404828596222; Tue, 08 Jul 2014 07:09:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 8 Jul 2014 07:09:56 -0700 (PDT) In-Reply-To: <53BBFA6E.7070107@qti.qualcomm.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> <53BBFA6E.7070107@qti.qualcomm.com> Date: Tue, 8 Jul 2014 10:09:56 -0400 X-Google-Sender-Auth: NxkWG7tuIYKRPpuV6vII5avdVBc Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nOm5AkUs6pCFftQysrFLeQ-1OU8 Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 14:10:05 -0000 > So the point I was *trying* to make (brain damage notwithstanding) was that > TLS provides integrity, but not the kind that Cyrus was talking about here. > TLS provides integrity of the data between the tz dist server and client, > but not between the original data (i.e., the Time Zone Database) and the > client. And since we're mentioning something about it below, I thought it > was worth explicitly calling out. Ah, yes. I missed that wrinkle. Then maybe this will make us both understand?: OLD NEW - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of what is distributed, including the ability to communicate that the data received from its original source, such as the Time Zone Database, has maintained integrity. Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. NEW NEW - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of the data as it is distributed, and may also address these issues with respect to retrieval of data from its original source (such as the Time Zone Database). Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. END From nobody Tue Jul 8 07:17: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 82B761B2AE1; Tue, 8 Jul 2014 07:17:47 -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 Gpe2_62zAGEL; Tue, 8 Jul 2014 07:17:44 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C681B2ADB; Tue, 8 Jul 2014 07:17:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id EBC171DA280; Tue, 8 Jul 2014 10:17:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgh_LsNVY6-T; Tue, 8 Jul 2014 10:17:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 811051DA26F; Tue, 8 Jul 2014 10:17:24 -0400 (EDT) Date: Tue, 08 Jul 2014 10:17:37 -0400 From: Cyrus Daboo To: Pete Resnick , Barry Leiba Message-ID: <97A936BAD8450D6EFDAC6CD3@caldav.corp.apple.com> In-Reply-To: <53BBFA6E.7070107@qti.qualcomm.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> <53BBFA6E.7070107@qti.qualcomm.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1244 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tRSYBvut2rtvjfhtZK2YMXGbVM0 Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 14:17:47 -0000 Hi Pete, --On July 8, 2014 at 9:04:30 AM -0500 Pete Resnick wrote: > So the point I was *trying* to make (brain damage notwithstanding) was > that TLS provides integrity, but not the kind that Cyrus was talking > about here. TLS provides integrity of the data between the tz dist server > and client, but not between the original data (i.e., the Time Zone > Database) and the client. And since we're mentioning something about it > below, I thought it was worth explicitly calling out. But if you think > it's covered in the original, I'm OK with that. So the tricky thing here - which we should delve into more in any WG - is that the Time Zone Database data has to be "processed" to extract the kind of information that zoneinfo files and iCalendar VTIMEZONE objects represent. That is done using the zic tool (for zoneinfo - provided in the "binary" TZ database package) and 3rd party tools for iCalendar. Given that, the current PGP signature on the TZ database data package file cannot be used to directly indicate the validity of the "processed" data being distributed by the TZ data distribution service. I think Barry's latest proposed text covers what we need to say right now. -- Cyrus Daboo From nobody Tue Jul 8 07:18: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 B67D31B2ADB; Tue, 8 Jul 2014 07:18: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 CTRFLg7dvv0n; Tue, 8 Jul 2014 07:17:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD061B2AF5; Tue, 8 Jul 2014 07:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404829078; x=1436365078; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oO3KDSX/bJNJ846W4JAP44EkYvtElB8y3tEjMwYZjNI=; b=LGM/T6i2ko2b1Tn+BE0sGa6FAjQBodU8GpQNZH/nLQYpc0iJNe7UP5d9 c2urj+7fyjfGnZeBOG/ivB2J39gV3wrZRAhM17Xi7qMckp+3/u+JI0WvT ChBcD0pCs0jLpdQWmiW7OW2S0Ho0FYQcS/KoAwVqSlfhhVyfwIpRIUnie U=; X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="49071649" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 08 Jul 2014 07:17:57 -0700 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="763064678" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2014 07:17:57 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 07:17:56 -0700 Message-ID: <53BBFD93.2010907@qti.qualcomm.com> Date: Tue, 8 Jul 2014 09:17:55 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> <53BBFA6E.7070107@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-PeUjR6dXfIS6BBg4m4_FyfGsfs Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 14:18:03 -0000 On 7/8/14 9:09 AM, Barry Leiba wrote: >> So the point I was *trying* to make (brain damage notwithstanding) was that >> TLS provides integrity, but not the kind that Cyrus was talking about here. >> TLS provides integrity of the data between the tz dist server and client, >> but not between the original data (i.e., the Time Zone Database) and the >> client. And since we're mentioning something about it below, I thought it >> was worth explicitly calling out. >> > Ah, yes. I missed that wrinkle. Then maybe this will make us both understand?: > > OLD NEW > - The time zone data distribution protocol will use current security > protocols to protect the integrity and confidentiality of what is > distributed, including the ability to communicate that the data > received from its original source, such as the Time Zone Database, > has maintained integrity. Even public time zone data can represent a > significant privacy exposure when it is associated with the user or > endpoint that is retrieving it. > > NEW NEW > - The time zone data distribution protocol will use current security > protocols to protect the integrity and confidentiality of the data as > it is distributed, and may also address these issues with respect > to retrieval of data from its original source (such as the Time Zone > Database). Even public time zone data can represent a > significant privacy exposure when it is associated with the user or > endpoint that is retrieving it. > > END > Opinions of security ADs would be helpful to confirm that we captured it right, but that's cool with me. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Jul 8 07:27: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 A18B21B2AE1; Tue, 8 Jul 2014 07:27:30 -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 ylJSEXw4nYoz; Tue, 8 Jul 2014 07:27:30 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7435D1B2ACF; Tue, 8 Jul 2014 07:27:29 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so4035344lbj.17 for ; Tue, 08 Jul 2014 07:27:27 -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=dhE/KJBQQFoVi27L6vYEUvb7qCH7xjuCfxa+G6CsQaI=; b=wiQutmml41SCzHqpX3aJeQ0+9qGizcaK3iw5M5l/806XI8lJqi1wX3+0gTG5uDnKcD UewEWiVTDEyGvrgdjqlaQtbyTGI6BTUrftDzaozk6TtLnV/n/vfVRGZtkPoSqSgwStxq XxqyCfEEEInjwSgBoJsM8MRfJZlqf+AD754emUvt7DKFeTa4n9p8dK9y7GMfjrvwUcda wX/7mTW5KtCRfZQpvX66OmAAetrc4k0TLw3gBG7663Ua4BqKFj0hxhEfmuC0ZsIJgrHZ LOQ2t3HpWKKf6gAVTVZ1yZ5gs8TbvFYvhsyNgJsU/swU6k9D7kIwirT6ag+dyHcXOuc/ SFSw== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr26526965lbc.16.1404829647575; Tue, 08 Jul 2014 07:27:27 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 8 Jul 2014 07:27:27 -0700 (PDT) In-Reply-To: <53BBFD93.2010907@qti.qualcomm.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> <53BBFA6E.7070107@qti.qualcomm.com> <53BBFD93.2010907@qti.qualcomm.com> Date: Tue, 8 Jul 2014 10:27:27 -0400 X-Google-Sender-Auth: Jm-z6-Af1QO1OITyE4pG6d1C2xk Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KWUR6jx7afgA5TQfjwD0OSA0faQ Cc: IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 14:27:30 -0000 > Opinions of security ADs would be helpful to confirm that we captured it > right, but that's cool with me. Both changes made in -05. The Sec ADs have not posted their positions yet, so we'll see what they have to say when they do. b From nobody Tue Jul 8 08:24: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 E812B1B2B1A for ; Tue, 8 Jul 2014 08:23:57 -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 sYn-bPPj0yp3 for ; Tue, 8 Jul 2014 08:23:56 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC51B2B18 for ; Tue, 8 Jul 2014 08:23:56 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id l6so6376477oag.26 for ; Tue, 08 Jul 2014 08:23:56 -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=co4sKKWs0rxUOG58ikl1Dd20N8TplrsE6XGVVYQgJxA=; b=VDxkOl//e6aNgdO+ezhZU7K79D8gAkOmuRisFpHPVlfFAxLEtqNTDodoREeH/hYROA ggEWqtgpa5xSaQ74/Qzz91qmtQgCc6q0oPBlNolkv3tZQbKA4T5f24vzUJuF5/FKOLqT bqOlEY4rbdBciwflWd952MJgIQqCAc/lUKMQo= 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=co4sKKWs0rxUOG58ikl1Dd20N8TplrsE6XGVVYQgJxA=; b=fJVSjyhYyJkoiRLdu/Pa+JpDCog+K8FcM2EEWsCwD6wH7E8m3ENv+5x+gPMeOtmHyD Lmk/xzpOL2lVhyoxIxqiFr//tmGFXNujmeCjJJt/xW8XUgKvivkgwoE/8+tS/CDiOBm+ QCietXlH8zN+xI6swtRcYuYlMxdKt5F5ksTyZ8PczE256uhm/YMmvYA8Ylx0FZGNlZee Zp01Pi0zbMDDionprU2lYAJkrb9wMrfC+Yr5pfGN0KOozoo+muksZZkHMpGuaI6jcOC9 JA5ow9OZEV8GMhF4nekEF+HO59zC5gIPK7YNSPBpyBkvzTxcnN8AhSZLtixGFQSZuPGq pfuw== X-Gm-Message-State: ALoCoQn0hCjZxXutFhBQCvW2GBnd3BGZNnr05/wbe/mUNtFlAD4Vy2xiNgTzLKNFJ5uknua1U6PR MIME-Version: 1.0 X-Received: by 10.60.116.166 with SMTP id jx6mr39526484oeb.6.1404833036124; Tue, 08 Jul 2014 08:23:56 -0700 (PDT) Received: by 10.60.134.145 with HTTP; Tue, 8 Jul 2014 08:23:56 -0700 (PDT) In-Reply-To: <53BBF0F0.9000006@seantek.com> References: <53BBF0F0.9000006@seantek.com> Date: Tue, 8 Jul 2014 16:23:56 +0100 Message-ID: From: Dave Cridland To: Sean Leonard Content-Type: multipart/alternative; boundary=089e0129534e1656c404fdb02e65 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YDDvIIqydNeMnM7ARxatNoXZwBw Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00 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, 08 Jul 2014 15:23:58 -0000 --089e0129534e1656c404fdb02e65 Content-Type: text/plain; charset=UTF-8 On 8 July 2014 14:24, Sean Leonard wrote: > Hello Apps-Discuss: > > A new Internet-Draft has been posted, proposing the text/markdown media > type to identify Markdown content. > > http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 > > Markdown is a family of lightweight markup languages (aka plain text > formatting syntaxes) designed to make it easy to read and write in plain > text, with the intention of having tools process the text into formal > markup languages, namely (X)HTML. This media type is specifically intended > to identify Markdown text, i.e., text intended for the Markdown tool or its > derivatives. > > This looks good. text/plain itself has a "format" parameter, which includes the simple (and default) "fixed", and a "flowed". I wonder whether a "markdown" format here would work better (or alongside) a new media subtype? (I'm honestly not sure). The advantage of using Markdown directly as a format parameter is that email clients are likely to handle it immediately; I'm pretty sure that unexpected text subtypes are probably rejected or mishandled by the deployed base of clients, counter to the specifications. The disadvantage is that we'd need to consider how that'd work with quoting styles, for example - but I'm willing to work on that, and might find some other folk to help. Dave. --089e0129534e1656c404fdb02e65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8= July 2014 14:24, Sean Leonard <dev+ietf@seantek.com> wro= te:
Hello Apps-Discuss:

A new Internet-Draft has been posted, proposing the text/markdown media typ= e to identify Markdown content.

http://tools.ietf.org/html/draft-seantek-tex= t-markdown-media-type-00

Markdown is a family of lightweight markup languages (aka plain text format= ting syntaxes) designed to make it easy to read and write in plain text, wi= th the intention of having tools process the text into formal markup langua= ges, namely (X)HTML. This media type is specifically intended to identify M= arkdown text, i.e., text intended for the Markdown tool or its derivatives.=


This looks good.

<= div>text/plain itself has a "format" parameter, which includes th= e simple (and default) "fixed", and a "flowed". I wonde= r whether a "markdown" format here would work better (or alongsid= e) a new media subtype? (I'm honestly not sure).

The advantage of using Markdown directly as a format pa= rameter is that email clients are likely to handle it immediately; I'm = pretty sure that unexpected text subtypes are probably rejected or mishandl= ed by the deployed base of clients, counter to the specifications.

The disadvantage is that we'd need to consider how = that'd work with quoting styles, for example - but I'm willing to w= ork on that, and might find some other folk to help.

Dave.
--089e0129534e1656c404fdb02e65-- From nobody Tue Jul 8 08:32: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 F31EA1B2B24; Tue, 8 Jul 2014 08:32:38 -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 xNNsrH58Leot; Tue, 8 Jul 2014 08:32:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6486C1B2B18; Tue, 8 Jul 2014 08:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=872; q=dns/txt; s=iport; t=1404833559; x=1406043159; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0smCFmwkrHZQbHEkWZ/2rNA1P7i/mgzDLEZboAynhjg=; b=eVtKZjE2QYJrts/I8YBaupJHfttrDrRfQ5+kkSvmC+Vu6xdQz2vWFzLi Xbc43QB6zYkpv+HXWgjWon/C1J065On4568AUp/OrhCdALcfep7pBjARM Xq3ZZvlr0oOmEehCyTOkCTc1IYEdHdMnhnvHri+7F7/ZBb/4Ar60ot9MX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEANQNvFOtJssW/2dsb2JhbABZhynDWAGBK3WEAwEBAQQjVhALGAICBSECAg8CRgYBDAEHAQGIPrAQmTwXgSyOFgeCd4FMAQSWXIQahw+ET4guggGBRDs X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="102558710" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Jul 2014 15:32:37 +0000 Received: from [10.61.204.167] ([10.61.204.167]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s68FWZU6003209; Tue, 8 Jul 2014 15:32:35 GMT Message-ID: <53BC0F12.40706@cisco.com> Date: Tue, 08 Jul 2014 17:32:34 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , Pete Resnick References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FPNml2NsSTti4Hmj_TcnwzayTmI Cc: Paul Eggert , IESG , Apps Discuss Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 15:32:39 -0000 Hi everyone, On 7/8/14, 3:55 PM, Barry Leiba wrote: > >> The following are Out of scope for the working group: >> >> - Any changes to the Time Zone Database process or infrastructure, >> as documented in RFC 6557. However, the WG may work with IANA >> in order to make integrity checking information, like public keys, >> readily accessible for protocol use. > This looks fine to me (modulo changing "like" to "such as", which I > will do). Isn't this part sufficient to address your concern, Pete? > > As mentioned earlier in this thread, RFC 6557 *already* asks the IANA to take responsibility for signing the database (as mentioned earlier in this thread). Before the WG takes on any changes here, we should find out what, if any, bottleneck exists, and what the views and experiences of the TZ Coordinator & IANA are. Eliot From nobody Tue Jul 8 08:50: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 0E6081B2B39; Tue, 8 Jul 2014 08:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 VQo5FVaHaXC4; Tue, 8 Jul 2014 08:50:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479731B2B2B; Tue, 8 Jul 2014 08:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404834627; x=1436370627; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jrbstFxorGmVua/gatzriRuPGKPCby/BEy6xnNzLNR0=; b=PimhMU7M72ahV6PIlnf9O/X2+d7q8ueRMzLJBFlgcURbd4U4THPH29dt pQ2AgpitxwxY2ZbbFLg2FEE0djONL4fQW8hYWEn/KwnMzH9gXfBgY/LGt RuUC3ZPKcs206JEqe0S2Gtz7KPiqJ/dTqN1Y7Amzhmd8I/xEIjcNruNrL c=; X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="140389782" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 08 Jul 2014 08:50:26 -0700 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208,217";a="695422398" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2014 08:50:27 -0700 Received: from NASANEXD02D.na.qualcomm.com ([169.254.4.193]) by NASANEXHC01.na.qualcomm.com ([10.46.57.53]) with mapi id 14.03.0181.006; Tue, 8 Jul 2014 08:50:26 -0700 From: "Resnick, Pete" To: Eliot Lear Thread-Topic: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) Thread-Index: AQHPlwlHOBxcgdhONk+zHBysrIVTw5uQWvuAgAOxAYCAAT3QgIAAf/CAgADmJoCAABsRAP//j6VV Date: Tue, 8 Jul 2014 15:50:25 +0000 Message-ID: <3wq6mse4c6gle11ic64197q4.1404834616269@email.android.com> References: <6.2.5.6.2.20140703133637.0b2a7820@resistor.net> <53B9C161.4050502@qti.qualcomm.com> <911121B3EB62AABFDDBFF8BB@caldav.corp.apple.com> <53BB374D.5000705@qti.qualcomm.com> , <53BC0F12.40706@cisco.com> In-Reply-To: <53BC0F12.40706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3wq6mse4c6gle11ic64197q41404834616269emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eCfMNAU85V2ctyPfE0_tAQ1IsSs Cc: Barry Leiba , IESG , Apps Discuss , Paul Eggert Subject: Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist) 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, 08 Jul 2014 15:50:33 -0000 --_000_3wq6mse4c6gle11ic64197q41404834616269emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eliot, The edit we just made to the charter text makes it absolutely clear that th= e WG shall make *no changes*; taking on changes is specifically out of scop= e. The only thing they are chartered to do in this regard is to consult wit= h IANA in order to figure out how to get the signed data if it's not obviou= s. Do you think that is not clear? pr -- Sent from my Droid. Pardon my brevity. Eliot Lear wrote: Hi everyone, On 7/8/14, 3:55 PM, Barry Leiba wrote: > >> The following are Out of scope for the working group: >> >> - Any changes to the Time Zone Database process or infrastructure, >> as documented in RFC 6557. However, the WG may work with IANA >> in order to make integrity checking information, like public keys, >> readily accessible for protocol use. > This looks fine to me (modulo changing "like" to "such as", which I > will do). Isn't this part sufficient to address your concern, Pete? > > As mentioned earlier in this thread, RFC 6557 *already* asks the IANA to take responsibility for signing the database (as mentioned earlier in this thread). Before the WG takes on any changes here, we should find out what, if any, bottleneck exists, and what the views and experiences of the TZ Coordinator & IANA are. Eliot --_000_3wq6mse4c6gle11ic64197q41404834616269emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Eliot,

The edit we just made to the charter text makes it absolutely clear th= at the WG shall make *no changes*; taking on changes is specifically out of= scope. The only thing they are chartered to do in this regard is to consul= t with IANA in order to figure out how to get the signed data if it's not obvious. Do you think that is not c= lear?

pr

--
Sent from my Droid. Pardon my brevity= .


Eliot Lear <lear@cisco.com> wrote:

Hi everyone,


On 7/8/14, 3:55 PM, Barry Leiba wrote:
>
>>    The following are Out of scope for the working g= roup:
>>
>>    - Any changes to the Time Zone Database process = or infrastructure,
>>    as documented in RFC 6557. However, the WG may w= ork with IANA
>>    in order to make integrity checking information,= like public keys,
>>    readily accessible for protocol use.
> This looks fine to me (modulo changing "like" to "such = as", which I
> will do).  Isn't this part sufficient to address your concern, Pe= te?
>
>

As mentioned earlier in this thread, RFC 6557 *already* asks the IANA to take responsibility for signing the database (as mentioned earlier in
this thread).  Before the WG takes on any changes here, we should find=
out what, if any, bottleneck exists, and what the views and experiences
of the TZ Coordinator & IANA are.

Eliot

 --_000_3wq6mse4c6gle11ic64197q41404834616269emailandroidcom_-- From nobody Tue Jul 8 08:53: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 4468F1B2B48 for ; Tue, 8 Jul 2014 08:53:00 -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 pxFo9CmE4OpQ for ; Tue, 8 Jul 2014 08:52:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194371B2B3B for ; Tue, 8 Jul 2014 08:52:58 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.242.155.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B8C122E1F3; Tue, 8 Jul 2014 11:52:56 -0400 (EDT) Message-ID: <53BC13DE.6080000@seantek.com> Date: Tue, 08 Jul 2014 08:53:02 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Cridland References: <53BBF0F0.9000006@seantek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/clFCxSPu60de2KyCLMLPnKKF4lw Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New I-D: text/markdown Media Type - draft-seantek-text-markdown-media-type-00 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, 08 Jul 2014 15:53:00 -0000 Glad to see that we're getting some traction already! On 7/8/2014 8:23 AM, Dave Cridland wrote: > On 8 July 2014 14:24, Sean Leonard > wrote: > > Hello Apps-Discuss: > > A new Internet-Draft has been posted, proposing the text/markdown > media type to identify Markdown content. > > http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-0= 0 > > Markdown is a family of lightweight markup languages (aka plain > text formatting syntaxes) designed to make it easy to read and > write in plain text, with the intention of having tools process > the text into formal markup languages, namely (X)HTML. This media > type is specifically intended to identify Markdown text, i.e., > text intended for the Markdown tool or its derivatives. > > > This looks good. > > text/plain itself has a "format" parameter, which includes the simple=20 > (and default) "fixed", and a "flowed". I wonder whether a "markdown"=20 > format here would work better (or alongside) a new media subtype? (I'm = > honestly not sure). > > The advantage of using Markdown directly as a format parameter is that = > email clients are likely to handle it immediately; I'm pretty sure=20 > that unexpected text subtypes are probably rejected or mishandled by=20 > the deployed base of clients, counter to the specifications. > > The disadvantage is that we'd need to consider how that'd work with=20 > quoting styles, for example - but I'm willing to work on that, and=20 > might find some other folk to help. I gave it some thought, and reviewed RFC 3676. I can see format=3Dmarkdown potentially working; however, there are some = drawbacks. Most notably, there are security drawbacks. Markdown allows for islands of HTML (or other markup); thus a valid=20 Markdown document could be 99% HTML, full of