From nobody Thu Aug 3 15:21:56 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA57131CB5; Thu, 3 Aug 2017 15:21:47 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 zeAJiP3YYakD; Thu, 3 Aug 2017 15:21:45 -0700 (PDT) Received: from mail1.g15.pair.com (mail1.g15.pair.com [66.39.65.234]) (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 A1B6812711E; Thu, 3 Aug 2017 15:21:45 -0700 (PDT) Received: from mail1.g15.pair.com (localhost [127.0.0.1]) by mail1.g15.pair.com (Postfix) with ESMTP id 9A7DDBDD59; Thu, 3 Aug 2017 18:21:44 -0400 (EDT) Received: from [192.168.90.152] (209-6-217-99.s353.c3-0.smr-ubr1.sbo-smr.ma.cable.rcncustomer.com [209.6.217.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail1.g15.pair.com (Postfix) with ESMTPSA id 6A73CBDD98; Thu, 3 Aug 2017 18:21:44 -0400 (EDT) To: Noah Mendelsohn Cc: "dispatch@ietf.org" , "art@ietf.org" , "uri-review@ietf.org" References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> From: David Booth Message-ID: Date: Thu, 3 Aug 2017 18:21:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 22:21:47 -0000 On 07/31/2017 12:17 AM, Noah Mendelsohn wrote: [ . . . ] > A little history on the drafts at: > > https://www.w3.org/2001/tag/doc/SchemeProtocols.html > > There were two of these drafts, [ . . . ] It sounds to me like the history that you just explained in email would be a perfect addition to those draft documents, as an editor note, so that people who find them can more easily understand their context. Thanks, David Booth From nobody Thu Aug 10 07:39:01 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98CE1321F6 for ; Thu, 10 Aug 2017 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8E8OLI40mDfY for ; Thu, 10 Aug 2017 07:38:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAD31321EB for ; Thu, 10 Aug 2017 07:38:58 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 10 Aug 2017 07:38:55 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 10 Aug 2017 07:38:55 -0700 From: Paul Hoffman To: "dispatch@ietf.org" Thread-Topic: Working Group Proposal: DNS Over HTTPS Thread-Index: AQHTEeZkGTb9b3hkGE2HrknbWStBHQ== Date: Thu, 10 Aug 2017 14:38:55 +0000 Message-ID: <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B9F03036D7B9B4E921122527A645414@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 14:39:00 -0000 Greetings. Alexey asked Patrick and I to send this to DISPATCH to get discu= ssion going. --Paul Hoffman and Patrick McManus Working Group: DNS Over HTTPS (DOH) DNS queries sometimes experience problems with end-to-end connectivity at t= imes and places where HTTPS flows freely. The use of HTTPS provides integri= ty and confidentiality, and it also allows the transport to interoperate wi= th common HTTP infrastructure and policy. The WG will standardize how HTTP clients can encode DNS queries and interpr= et DNS responses. The WG will use best-practice HTTP semantics. Specification of how the DNS data may used for new use cases, and the disco= very of the DOH servers, are out of scope for the WG. The WG will begin its work based on draft-hoffman-dispatch-dns-over-https. The WG will deliver a document describing how to obtain and interpret DNS i= nformation using the HTTP protocol, with an IETF Last Call expected in Dece= mber 2017. From nobody Thu Aug 10 09:01:01 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073631323A1 for ; Thu, 10 Aug 2017 09:01:00 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 txEbaD4HJGfL for ; Thu, 10 Aug 2017 09:00:58 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B565313239E for ; Thu, 10 Aug 2017 09:00:58 -0700 (PDT) Received: (qmail 50029 invoked from network); 10 Aug 2017 16:00:57 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Aug 2017 16:00:57 -0000 Date: 10 Aug 2017 16:00:35 -0000 Message-ID: <20170810160035.9804.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org Cc: paul.hoffman@icann.org In-Reply-To: <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:01:00 -0000 In article <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> you write: >Working Group: DNS Over HTTPS (DOH) > >DNS queries sometimes experience problems with end-to-end connectivity at times and places where HTTPS flows freely. The use of HTTPS >provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTP infrastructure and policy. > >The WG will standardize how HTTP clients can encode DNS queries and interpret DNS responses. > >The WG will use best-practice HTTP semantics. > >Specification of how the DNS data may used for new use cases, and the discovery of the DOH servers, are out of scope for the WG. > >The WG will begin its work based on draft-hoffman-dispatch-dns-over-https. > >The WG will deliver a document describing how to obtain and interpret DNS information using the HTTP protocol, with an IETF Last Call expected in December 2017. In the discussions to date, the proposal has been to send wire format queries encapsuated as an appropriate MIME type and get wire format responses back, to be parsed by the https client. The design is very simple. The main use case I see is that javascript running in browsers can currently only do implicit A and AAAA queries by looking up URLs. If you want to do a SRV or NAPTR or URI lookup, you can't. So with this hack, the js application can now do those lookups. There's also more exotic scenarios where you're trapped behind a hostile firewall or maybe a captive portal or you want to do queries that are harder to snoop, but I think that SRV/NAPTR/URI in js is enough of a use case. Someone asked what if the https server lies? DNS caches have always lied, that's nothing new. If you don't trust it, you have DNSSEC. Another suggestion was to turn the queries and responses into easier to handle json, but that increases the complexity by orders of magnitude, and would requires an update for every new rrtype or edns flag. (If someone wants to build a json proxy on top of this as an experiment, sure, go ahead.) As you might gather, I think this is a good idea, and should be straightforward for us to handle. R's, John From nobody Thu Aug 10 09:22:52 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD53132331 for ; Thu, 10 Aug 2017 09:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6TmNr0pyzn0 for ; Thu, 10 Aug 2017 09:22:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3347113239E for ; Thu, 10 Aug 2017 09:22:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B47ACBE2F; Thu, 10 Aug 2017 17:22:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHfd5D9MsAh1; Thu, 10 Aug 2017 17:22:45 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 792FDBE24; Thu, 10 Aug 2017 17:22:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1502382165; bh=ZZj0qRop/RhcDNN7MNj+8Nduwgww8NtMrdlePA0cRTU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HkIbhxJbDh1SrAZ+Ie5mRSvBMUmcWaVpvk2JCgG/okptTRcqqNQVPjCtat3fC+jbN WeTAmPTVZAzVDFjqPFXlPK6+vArLkU6+w4lIPR4KE1V5TGkLQi825GR/WQOQtxWyT/ iGYIY1CVlUGpmQU+Vvy8w27pQVXcvx6t0BjFC0VQ= To: John Levine , dispatch@ietf.org Cc: paul.hoffman@icann.org References: <20170810160035.9804.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> Date: Thu, 10 Aug 2017 17:22:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810160035.9804.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xPaWBEVf7cVBShx6KpuaAV9pCR2sPxrDN" Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:22:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xPaWBEVf7cVBShx6KpuaAV9pCR2sPxrDN Content-Type: multipart/mixed; boundary="Xh2iABSoidABfpdHnKguOXxIeKNic8Gj2"; protected-headers="v1" From: Stephen Farrell To: John Levine , dispatch@ietf.org Cc: paul.hoffman@icann.org Message-ID: <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS References: <20170810160035.9804.qmail@ary.lan> In-Reply-To: <20170810160035.9804.qmail@ary.lan> --Xh2iABSoidABfpdHnKguOXxIeKNic8Gj2 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I'm not against this, pretty much for it in fact, but... On 10/08/17 17:00, John Levine wrote: >=20 > Someone asked what if the https server lies? DNS caches have always > lied, that's nothing new. If you don't trust it, you have DNSSEC. Changing the liar can be significant. If this is used with some dedicated https server that only does dns and nothing else, and the URL for that is configured into a dns/https client, that's probably no big change vs. speaking the dns protocol with a resolver. If however, a random web site were to be able to get a http client like a browser to believe lies about dns then that'd be much worse than today, if those lies affect more than the web pages that the fibbing web site can control anyway. That's ack'd in the last para of the security considerations but I suspect more will be needed there, first to analyse possible bad behaviours and then to figure out what to say about those. (I'd be surprised if that were doable by the end of the year, but since ietf milestone date fiction deserves it's own aisle in a bookstore, that's ok:-) As an aside, I'm puzzled a bit by how CORS comes into this. S. --Xh2iABSoidABfpdHnKguOXxIeKNic8Gj2-- --xPaWBEVf7cVBShx6KpuaAV9pCR2sPxrDN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZjIhUAAoJEC88hzaAX42iEgMIALcVko3m57tSiiYsvxHag6Su iCJ/E6EYIG/gN1ilCGMsh2fBOozzTkg0e+BefDQeppBIRS6wj2nOYuQfimZwzb+W lpvlOWKzgLiOXjZbWx9TiJu7Nl/OKy1237WVYrnLmtaDayCOlgqpSpoPIADWwAxe HTuMyiBEkaJggjxZvwleDSW+TlmBYCxDwB/0/BT0oow2rrIJFab6IioglYjAc0K3 MyjqpVUn1+1Nlm07QQv+tHCLlidgb4fjDfiQ4kmhENlBvG3Lv/pXgdpehdYXmgo4 nvJ7n4cKiy9Z4QSfJ1iVsHalqLi89eQuKjrSvRXVJBeh3tgwL0NRICKJXZiv8Ro= =6G8g -----END PGP SIGNATURE----- --xPaWBEVf7cVBShx6KpuaAV9pCR2sPxrDN-- From nobody Thu Aug 10 09:28:02 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E51323AF for ; Thu, 10 Aug 2017 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jd5654zF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EMUoStaf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVEXnnXGYLhM for ; Thu, 10 Aug 2017 09:27:59 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CDE1323A7 for ; Thu, 10 Aug 2017 09:27:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4257520FC9; Thu, 10 Aug 2017 12:27:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 10 Aug 2017 12:27:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=A/6ZKDSHlWQj9bRl19 ZRjqA7acrFxufhhqRXgUnCeVs=; b=jd5654zFE1cjC4Nmi5S9Dmpz4SFbdyw8d0 5BH/gRL14oac6uvgfxVCcmFIrVbuyEeH00n/YONo5K+w6BwACIpQLS1cvF2c21gc fT7Ciw4ctnqVHYxA0WLXT6jV8PZmVrTiyU8VpNh7IwtW6EZNm0gB8mWm4PS5DSYh 0u+g1xzE7sIiSuncQC8MTr+aRvSSLsJMAElZ/7Ib29wiedgT95Btpcwx9ovridIf mwaevGqaAoy9HV+/pqHHfsNfwqM41ndeuh4KD59DRyxpUbl1qjF/i7QXARy3SheH m/K3B7ckxQM/W4FIGfxrmCqLbTTFrSACmdJuB+2tSEQkJaVZ1Mog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=A/6ZKDSHlWQj9bRl19ZRjqA7acrFxufhhqRXgUnCeVs=; b=EMUoStaf 4MIlZvrUaZIHX7NaByRNzCa5+SF19WDdUr5aC5hDzNG7ULL/dbWtSvJSb/Tu6dXC vk9SnB8qICpIt1pSrFVetnRiHUHBkzWFwM2aIbbfpXGFObFk43tn0AVem1YLbu36 b36sedQIFwcMtKVNIXBNNATlT3jAp+IkmIk6r/8j0/ms+o3OGHSmrBhbXE3e87nw s6IIDDDYiT+FPXc/IGsnIvUayoOYwgMvmEoEmDiW4OFGmv2c+gCpNjFofwYGgBLq BJeh8SBSAuFtxfBKM09MaSjyt1FUacBgUoZfUl9+4/4Q9IIb+ERAOX6WdwUVulgx kpsooM9mncZz/Q== X-ME-Sender: X-Sasl-enc: CYqjJt+4oeRxvlk4PloKGa4T3faCH3pZWbAOBMtH4ThC 1502382479 Received: from [10.0.25.9] (108-60-118-130.static.wiline.com [108.60.118.130]) by mail.messagingengine.com (Postfix) with ESMTPA id C7C8F248A0; Thu, 10 Aug 2017 12:27:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <20170810160035.9804.qmail@ary.lan> Date: Thu, 10 Aug 2017 09:27:56 -0700 Cc: dispatch@ietf.org, paul.hoffman@icann.org Content-Transfer-Encoding: 7bit Message-Id: <24DB3782-A622-47A4-9068-956F383BEDA7@mnot.net> References: <20170810160035.9804.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:28:02 -0000 > On 10 Aug 2017, at 9:00 am, John Levine wrote: > > As you might gather, I think this is a good idea, and should be > straightforward for us to handle. Well said; +1 from me. -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 10 10:58:45 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F156D1323BC for ; Thu, 10 Aug 2017 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 fnrmPkdsnSiK for ; Thu, 10 Aug 2017 10:58:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F1F131D1A for ; Thu, 10 Aug 2017 10:58:42 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7AHwGaW013477 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Aug 2017 12:58:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Stephen Farrell , John Levine , dispatch@ietf.org Cc: paul.hoffman@icann.org References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> From: Adam Roach Message-ID: Date: Thu, 10 Aug 2017 12:58:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:58:44 -0000 On 8/10/17 11:22 AM, Stephen Farrell wrote: > As an aside, I'm puzzled a bit by how CORS comes into this. I would presume that a website offering this endpoint would need to make a policy decision regarding which script origins it wants to let use it (at least, in the context of a web browser that honors CORS). I *expect* that, operationally, most servers offering this service will set up CORS to allow anyone to ask (as, if this were simply a matter of providing information to their own scripts, it could be done in a much simpler and way without the need for standardization). I believe this deserves a brief treatment in the Security Considerations section, but doesn't have an impact on the charter. /a From nobody Thu Aug 10 11:30:04 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A96132406 for ; Thu, 10 Aug 2017 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=klujwMSK; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=Bt8E/+fX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQs7z5JlfLi0 for ; Thu, 10 Aug 2017 11:30:01 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B4B1323B1 for ; Thu, 10 Aug 2017 11:30:00 -0700 (PDT) Received: (qmail 61630 invoked from network); 10 Aug 2017 18:29:59 -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=f0bc.598ca627.k1707; bh=LhedcKbpmnYNSee15nVcNTmfF6kBtY7+G1be+LdFtTY=; b=klujwMSK/3XO+Ea/L+ZckPlKgtgXi5iuPIrcA5tmMKqx6i4U/JG1LdZR7L+YXden485Dc3yamUp/hlfpZkoSu/JXSO0SkKAIGPOTPDJFJyHo13id55u4vWpHJIf+kdvWbz/J1xLck9t1LM5U+Ju7u7nzlBaj4XblIQypN6niJQbzzuB4/ZTxouP265VL4hhiZbcwKDZmzLZFpvxF0r8ylVsCAo/4b3FQtkmadv/mgSWQ88bh/JTofAwzKvbM7gI5 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=f0bc.598ca627.k1707; bh=LhedcKbpmnYNSee15nVcNTmfF6kBtY7+G1be+LdFtTY=; b=Bt8E/+fXHkItqJs0pb/4YkjyjhBnFRAeCfvhbB05R/lkizv3+CBZLVkctNwQBjfqf6I8AQlPF6t7+ElRE+QS+lByrl6fVoIPM1SYYPlhV3iX6h6rjxQJlNe4lLSx3SPExnFrl0VhA+bwbEqDy767j7bf5St/GFOniLvwfSDScOe2qrT5z1pONJtbUWs1LAlMOZ1rmNwYNx/gBEsfBUkwvO3SVOQ6ARNXGXx99rG3onAMWWR3idA339m1oBQbbqgN 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.2/X.509/AEAD) via TCP6; 10 Aug 2017 18:29:59 -0000 Date: 10 Aug 2017 14:29:59 -0400 Message-ID: From: "John R Levine" To: "Stephen Farrell" Cc: "Dispatch WG" In-Reply-To: <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:30:03 -0000 On Thu, 10 Aug 2017, Stephen Farrell wrote: > If however, a random web site were to be able to get a http > client like a browser to believe lies about dns then that'd > be much worse than today, if those lies affect more than the > web pages that the fibbing web site can control anyway. I don't see what the problem is. This is just a way to encapsulate DNS queries in http, typically from a javascript routine running in a browser. Unless browsers work very differently from the way I think they do, this is not a way to patch a browser's DNS lookup code. > As an aside, I'm puzzled a bit by how CORS comes into this. CORS? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 10 12:40:57 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E982132433 for ; Thu, 10 Aug 2017 12:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5bblUYnBfL6 for ; Thu, 10 Aug 2017 12:40:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06B5132429 for ; Thu, 10 Aug 2017 12:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F817BE2F; Thu, 10 Aug 2017 20:40:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou9QuChoIuG9; Thu, 10 Aug 2017 20:40:46 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8BB9CBE2E; Thu, 10 Aug 2017 20:40:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1502394046; bh=CBgOv2pvyIZlnCghalQN9NnN3XsPt8xShMQ26cdC5D0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Rwzoqz5qHd8OWnAIZ3lCrh785lB7ZK+WpBKSHUbL+unQ+ZS4OIS6Ze/MBD5pa4uY+ SkfwTt1TFLn876r4fRY9xIVLkN+RoZJY6561hQ57x1NoDL4VlL1wLAJ5qA4NtdZpSZ Ipsj5C4sQ4Rh9mv0s5fn8NVeB9G6ZQdGYvNgPT7Q= To: John R Levine Cc: Dispatch WG References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> Date: Thu, 10 Aug 2017 20:40:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GdqTxSDnjN5i6dtV6E2vRCQUQrTqPJAv6" Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:40:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GdqTxSDnjN5i6dtV6E2vRCQUQrTqPJAv6 Content-Type: multipart/mixed; boundary="RdFD0FlXOtgA4JexLIsAxILxUae9Hq5tK"; protected-headers="v1" From: Stephen Farrell To: John R Levine Cc: Dispatch WG Message-ID: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> In-Reply-To: --RdFD0FlXOtgA4JexLIsAxILxUae9Hq5tK Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 10/08/17 19:29, John R Levine wrote: > On Thu, 10 Aug 2017, Stephen Farrell wrote: >> If however, a random web site were to be able to get a http >> client like a browser to believe lies about dns then that'd >> be much worse than today, if those lies affect more than the >> web pages that the fibbing web site can control anyway. >=20 > I don't see what the problem is. This is just a way to encapsulate DNS= > queries in http, typically from a javascript routine running in a > browser. Unless browsers work very differently from the way I think the= y > do, this is not a way to patch a browser's DNS lookup code. I don't know what you mean by that last tbh. The problem I'm trying to describe is touched on in the last para of the draft's security considerations. >=20 >> As an aside, I'm puzzled a bit by how CORS comes into this. >=20 > CORS? Yes. The mention of that in the draft we're discussing is a bit of a puzzle to me. Hopefully you didn't read some other draft:-) S. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.= ly >=20 --RdFD0FlXOtgA4JexLIsAxILxUae9Hq5tK-- --GdqTxSDnjN5i6dtV6E2vRCQUQrTqPJAv6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZjLa9AAoJEC88hzaAX42inLAH/jqTIcNNvuprzcWJ+U2B7JBe Nm/V4lu3v7JC0/vQiqnl7HG5T5pOc7X2AYCbQvtXz6H0RH6oqY0dz/iSWAnPnOui yMp/TOzbsebu91gS104NZ9ZTztJCm/ui58j4Srzb0x+3cC3OfqrwQZ0ifBap8p/N T27cTpdQw5dqagUq6ubTIACrWAqWUjak7OUTmqxvp0R+484PxxU7SYFSsIH0EYh5 EAN6GZeWMl3PzNBqxyfP14Y6mzTUOaP/qdOZ0KNQf3AnG3MC5iSl5cyQkfjZrdNN XB48Xk6LIGIUYabpoFsobDEaoRSOmVp6LbiG/DLhcY7jM+vwVew1tQ2I+f03mTA= =jlC2 -----END PGP SIGNATURE----- --GdqTxSDnjN5i6dtV6E2vRCQUQrTqPJAv6-- From nobody Thu Aug 10 12:48:54 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B92132430 for ; Thu, 10 Aug 2017 12:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=Mwi1nWXo; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=vOHzUXox Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlKMyquh7Iuu for ; Thu, 10 Aug 2017 12:48:52 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA7B132359 for ; Thu, 10 Aug 2017 12:48:51 -0700 (PDT) Received: (qmail 67105 invoked from network); 10 Aug 2017 19:48: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=1061f.598cb8a3.k1707; bh=NUhp/Jyq+dqDYhnDdCjMf/Z9YRaT1sraPG65iiqLL4Q=; b=Mwi1nWXoNfOAj0N1YEg3Sik6RAnPtqJovW6QcsPjfsY9wWEYA3iuzTQKCyJCfUMO1Jwr2L2tZF9qUJ1WdhPSPgU+DKYalL+cVl+JnKfyPqqM+imS3hQt9t6ub04/MCNfAA+K3ttoI7Td5ox/vlfwbuZzbdkPUqaSL4JJvrOLQOKZTr14npKIVa0A0A3d2PSTlAZn7oeSMXHX2g2AEmY9jFI5nPzJfnwDXTUz0YhYVbsY5ERaq070/qULq4LEqb/u 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=1061f.598cb8a3.k1707; bh=NUhp/Jyq+dqDYhnDdCjMf/Z9YRaT1sraPG65iiqLL4Q=; b=vOHzUXoxXpjO1f5gDVhcWW0DctMaOcClxGRiERmgbLbEY70qcYB/bmJhv/RNBB6L6GOZWgjFOhpDLgzikoOur3tWx4Ek8XHHJbEf9qyOXcUq8SP3EGP9rqFkL5rODvSqQCm3ofJ/Jm5s9rUnGqy1cOL1LHQHwlSdf0nd7LJpOIQubYGdo6BjKvW7QWWkZLP1DAAX+30or8Y7tApt+5iTz1pjb7Dq1u/X8uOiXaLX2/E8LTyrp40V0HvAP3YKnBrx 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.2/X.509/AEAD) via TCP6; 10 Aug 2017 19:48:50 -0000 Date: 10 Aug 2017 15:48:50 -0400 Message-ID: From: "John R Levine" To: "Stephen Farrell" Cc: "Dispatch WG" In-Reply-To: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:48:53 -0000 On Thu, 10 Aug 2017, Stephen Farrell wrote: >> do, this is not a way to patch a browser's DNS lookup code. > > I don't know what you mean by that last tbh. Browsers do their own DNS lookups in the usual way. This proposal does not change that in the least. > The problem I'm trying to describe is touched on in the > last para of the draft's security considerations. Oh, that. The client is the javascript application, not the browser inside which it's running. Re CORS, a normal javascript app can only call back to servers in the same domain, so any evil due to DNS over http will be coming from the equally evil server that provided the javascript code in the first place. I suppose CORS lets it talk to other differently evil places, but this doesn't impress me as an interestingly new problem. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 10 12:53:17 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7F132359 for ; Thu, 10 Aug 2017 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6pDb9cplBax for ; Thu, 10 Aug 2017 12:53:13 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF64A132420 for ; Thu, 10 Aug 2017 12:53:12 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j189so6722827vka.0 for ; Thu, 10 Aug 2017 12:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/fUTZfpAS6v7B5tyGQJs144IVoGlF8T85o5beTmZOA=; b=q/S9iHuhbPROeUfrITp24ySzaOML0BX+o3Fv800bzXRiOkhaxC3TjAbylIFBv9KU8c 4BsosYtG5tdKyqDowIPE8BYIWM8NDw3T3Xd/yfz8ePrTsyVb1UWCh2KIdp4O8kiNSjya 4r9tTxAdnxBpRu2+JCjalRj9+BBpLX5qihIbVjQcW5FMqmwWzfpeV0sTGByahOx8HZox EOvdQfivjviHH9Yh7Il6fYjnJoa2kIZ2YtIVA9S8+yJOuI/BN/cIbH1qM3vLzDu5/ubN ZBF3ryOzwqjUbnLkfZ+5Psy/ZdhuB+v59B/4XcdzM+gLJtMLPqBHafrFBvEc6ujSzLlx sjaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F/fUTZfpAS6v7B5tyGQJs144IVoGlF8T85o5beTmZOA=; b=m5vConNIWodSPSE4CWdDDjOuKMtcR/vXV/SaxlXmA9Wk7izeBjNyvYuKDqL5/4j5fW GnrR+BHymyXaticpQCA4QE9DLgLg9kPV5hxHLaOCsrZEA/ZTrKOG3irHFRIqmjjVQqH6 gKR5x7jSlTHH62DiwJvgpIkUy1wpjCg5bzsRa9BpS7qys1jnc8CB4iIUef0OCVwm64D4 xVN46ljOGMyvDG6gN7Q6CKiNV8a7aZv9BS/bX6YxoZr43R/kMkM3BYLO9SnQmMXJHSuS Gk3MiVYfT1343lsz8QEu7HekgTw1jCigB8bZcqgLsuUwHumRV06GNXRuAdkItQO7eD8/ f62g== X-Gm-Message-State: AHYfb5j4jGqBDqnSr3OWjB/Gx9T0BeChH33Xp/5K1+urYD7BRtQPsyJ+ 6tkEWcpncziNHuZu0MjiqCm4K89bRKDRXZc= X-Received: by 10.31.193.141 with SMTP id r135mr8410511vkf.113.1502394791400; Thu, 10 Aug 2017 12:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.50.204 with HTTP; Thu, 10 Aug 2017 12:53:09 -0700 (PDT) In-Reply-To: <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> References: <20170810160035.9804.qmail@ary.lan> <305d8c08-ce2d-8e4e-5293-c5c3abb5256b@cs.tcd.ie> <3d53edbf-2d56-5972-5ce7-bc82f6d82960@cs.tcd.ie> From: Ben Schwartz Date: Thu, 10 Aug 2017 15:53:09 -0400 Message-ID: To: Stephen Farrell Cc: John R Levine , Dispatch WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114dba4ee4d2b505566b8bf2" Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:53:15 -0000 --001a114dba4ee4d2b505566b8bf2 Content-Type: multipart/alternative; boundary="001a114dba4edb184205566b8b8b" --001a114dba4edb184205566b8b8b Content-Type: text/plain; charset="UTF-8" On Thu, Aug 10, 2017 at 3:40 PM, Stephen Farrell wrote: > > > On 10/08/17 19:29, John R Levine wrote: > > On Thu, 10 Aug 2017, Stephen Farrell wrote: > >> If however, a random web site were to be able to get a http > >> client like a browser to believe lies about dns then that'd > >> be much worse than today, if those lies affect more than the > >> web pages that the fibbing web site can control anyway. > > > > I don't see what the problem is. This is just a way to encapsulate DNS > > queries in http, typically from a javascript routine running in a > > browser. Unless browsers work very differently from the way I think they > > do, this is not a way to patch a browser's DNS lookup code. > > I don't know what you mean by that last tbh. > > The problem I'm trying to describe is touched on in the > last para of the draft's security considerations. > I agree that paragraph is a bit out of place in this draft, but I think the text is just trying to agree with you. It's implicitly describing a hypothetical scenario (browsers flinging DNS queries to any web server they bump into) in order to say DON'T DO THAT. I think we can clarify the wording there, and also possibly write a charter that explicitly excludes any change to how DNS clients choose recursive resolvers. > > > >> As an aside, I'm puzzled a bit by how CORS comes into this. > > > > CORS? > > Yes. The mention of that in the draft we're discussing is > a bit of a puzzle to me. Hopefully you didn't read some > other draft:-) > > S. > > > > > Regards, > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. > https://jl.ly > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a114dba4edb184205566b8b8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 10, 2017 at 3:40 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:


On 10/08/17 19:29, John R Levine wrote:
> On Thu, 10 Aug 2017, Stephen Farrell wrote:
>> If however, a random web site were to be able to get a http
>> client like a browser to believe lies about dns then that'd >> be much worse than today, if those lies affect more than the
>> web pages that the fibbing web site can control anyway.
>
> I don't see what the problem is.=C2=A0 This is just a way to encap= sulate DNS
> queries in http, typically from a javascript routine running in a
> browser. Unless browsers work very differently from the way I think th= ey
> do, this is not a way to patch a browser's DNS lookup code.

I don't know what you mean by that last tbh.

The problem I'm trying to describe is touched on in the
last para of the draft's security considerations.
=
I agree that paragraph is a bit out of place in this draft, = but I think the text is just trying to agree with you.=C2=A0 It's impli= citly describing a hypothetical scenario (browsers flinging DNS queries to = any web server they bump into) in order to say DON'T DO THAT.

I think we can clarify the wording there, and also possibly= write a charter that explicitly excludes any change to how DNS clients cho= ose recursive resolvers.
=C2=A0
>
>> As an aside, I'm puzzled a bit by how CORS comes into this. >
> CORS?

Yes. The mention of that in the draft we're discussing is
a bit of a puzzle to me. Hopefully you didn't read some
other draft:-)

S.

>
> Regards,
> John Levine, johnl@taugh.com, T= aughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--001a114dba4edb184205566b8b8b-- --001a114dba4ee4d2b505566b8bf2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDzYEV0w7iDYzElh5hIs+o6 Rg7oedNdYMGMYubfnWK5tDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MTAxOTUzMTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAC+gfOawpKzU5mawpantLn36m0J/xh6wVTzpgM8Bo GRdG+dq0L0p2ISthP2St6ZBRC1BSy5WtqseFVvMBGKEhFwmLfGHxvK9tWmlJQVkHsECLobzKJTah hKpdRlDXGkwCKrAlksgHHz4f4OinucbuRku5r3dmAUlqwOHm50sdLadZJ52maQoQgBxldQgpqR4/ KvgoJN0fblwSN8K/vXVYXHZ+1O2p6ugKzu67GkkXB7R4XKzq2WbzM5qjM5GktN2qNo4l+70zQlMM ivEC+FilDCXf4TflLviYeLOibY/zZw3uyfXTa2UUH5b71Eo29EtAp3hhxGE2INH7LI7NCNPuYg== --001a114dba4ee4d2b505566b8bf2-- From nobody Thu Aug 10 13:28:53 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02963132356; Thu, 10 Aug 2017 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4syLYpQ_pkII; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5701D128A32; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d136so10732435qkg.3; Thu, 10 Aug 2017 13:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iEvqkGJQmQO0Ju5AZ2ID60rcGbGMXBB566PowjCPYlY=; b=lhNK8b9bVhtiS68zYfyUu+byEwUobXUG3Gf1uW2TnU1lybwF2TkttSpF/Bg0ZQM4lG yUir9s+9l7m3Perb5XaiG5mKD9r6wz4LHke4EhZJp78GZHu+lqpGEPaYRvA4zPLzyHqq Sv9xqFXqLRaqPh/SFdIIbNFJp/ftB6QCX9HbF5f7vhlL6+NuyZ0kDPMnONkwDS+PXu5Q 87nJAXqPEzQoYuWxjD0BEpy4nVQa72+84e95F7AY3c2wWw6ObwFMEVTllEwf5Fe9hWqW 1NNUxO9/nH+x64LOPG86z9X/zz38CoDqHYJtWeac6+il0ifqUXcmmr9OJ8npRTUiJtVr cNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iEvqkGJQmQO0Ju5AZ2ID60rcGbGMXBB566PowjCPYlY=; b=eviGGxiV9EqtyPWxVtOyn0st+Y0OYpY6HAPAjjT1VKz0hTqa2e3XqpROWnBsVckdEL WIiCTqt7W5u0GVjK2QPkmJU3AOvkg9bTS55OsL9KYEMq/A9scf7QpymrWdSdqtGNR+1h iC/vBuqP7f3yRCPr6Z65w2hsVky0ckI6q4SIbih/KAkvvLCviQyvBwdMt0t/yjlB9gVR 9f8qHGADIp/H3zW2P8hfETbgktBBsmatNW2/v9a1Gv7TDNc8nc7OcPMUNa2M1bw3zCzr 89ug1wPpybE70yKFqdjt1xAl8f9cEMhWWDtcntXQ2VM/ejPbtuyn2oC3+tJMrzl3/J+B Nexw== X-Gm-Message-State: AHYfb5iOlsQFHRFT7OL20eoeHXnN9OGtH1ShlKTk3f0TDzeTO5eKHJrV 4CCo0+986SdtxrXAr66O1Q8ZUm9MudG+ X-Received: by 10.55.15.164 with SMTP id 36mr16126543qkp.242.1502396920920; Thu, 10 Aug 2017 13:28:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.10 with HTTP; Thu, 10 Aug 2017 13:28:39 -0700 (PDT) In-Reply-To: References: <598a1d5e.0157810a.baf63.13acSMTPIN_ADDED_BROKEN@mx.google.com> From: Mary Barnes Date: Thu, 10 Aug 2017 15:28:39 -0500 Message-ID: To: SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary="001a11474d86c87d4b05566c0a7e" Archived-At: Subject: [dispatch] Fwd: [SIPForum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:28:46 -0000 --001a11474d86c87d4b05566c0a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Apologies to those who might have already seen this on SIP Forum mailing lists, but I think this conference is directly relevant to folks doing work in SIP. This will be the 6th year for the conference. The conference has been well attended by service providers in the past. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Tue, Aug 8, 2017 at 3:21 PM Subject: [SIPForum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017 To: fullmembers@sipforum.org *The SIP Forum Opens Call for Presentations and Early-Bird Registration for SIPNOC 2017, November 28 =E2=80=93 30, 2017**Proposals now accepted for wor= kshops, panels, speaker presentations and "Birds of a Feather" sessions addressing the deployment of SIP in service provider environments; Wireshark Training Workshop included; Registration officially opens* The SIP Forum announced today that it has opened registration and the official Call for Presentations for the seventh annual SIP Network Operators Conference (SIPNOC 2017), being held at the Hilton Washington Dulles Hotel in Herndon, VA, November 28 -30, 2017. A three-day educational conference focusing on the challenges and opportunities related to the deployment of SIP-based carrier services globally, SIPNOC 2017 is a unique, network operator-centric event. Organizers invite companies, executives and industry insiders to propose presentations highlighting the use of session initiation protocol (SIP) in service provider environments. Operators are encouraged to present SIP-related success stories, deployment issues and concerns in their networks, while equipment vendors and other industry stakeholders are invited to work with operators to present real-world deployment experiences= . The* SIPNOC *conferences attractleading technical and operations personnel from the global carrier community and have earned high praise from attendees for their educational, non-commercial and technical content that focuses on the real-world challenges operators face when deploying SIP services in global IP networks. *SIPNOC 2017 *attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. The SIP Forum will once again offer specialized training at SIPNOC 2017 presented by the expert trainers of ECG, this year focused on learning the numerous tips and tricks of Wireshark =E2=80=93 *available to all SIPNOC 20= 17 =E2=80=9CAll-Access=E2=80=9D and =E2=80=9CFull Member=E2=80=9D attendees at= no additional cost! * This intensive =E2=80=9CWireshark for VoIP Ninjas=E2=80=9D workshop will eq= uip you with the core and advanced skills you need to diagnose and solve the thorniest problems using the popular, open-source tool Wireshark. The course prepares to you to install and configure Wireshark to maximize your effectiveness for VoIP, creating captures, locating calls and associated media, analyzing QoS for audio and video problems, and using Wireshark=E2=80=99s analytics t= ools to find trouble spots in a busy SIP/IMS VoIP network. *Early-Bird Registration for attending SIPNOC 2017 is now open, and participants registering before September 15, 2017 save $200. Click here to register or visit https://www.regonline.com/sipnoc2017 .* *SIPNOC 2017 Call for Presentations *proposals can be submitted by visiting the SIP Forum Call for Presentations webpage . Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. *SIPNOC 2017* offers several different types of speaking opportunities including: - *General Session Talks*: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - *General Session Panels*: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - *Special Workshops*: The *SIPNOC 2017* program has been expanded to include special workshops that run for 1-2 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - *Research Topics*: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, network performance, statistical measurement and analysis and protocol development and implementation. Studies presented may be works in progre= ss. Researchers from academia, government, and industry are encouraged to present. - *BOFs*: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. *SIPNOC 2017 Call for Presentation Key Dates* - Presentation Abstracts Due September 1, 2017 - Draft Presentations Due September 14, 2017 - Acceptance Decision and Notifications September 20, 2017 - Draft Program Published September 20, 2017 - Final Presentations Due October 20, 2017 - Final Agenda Published October 23, 2017 - Conference Begins November 28, 2017 *SIPNOC 2017 Call for Presentations General Info* To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit https://www.sipforum.org/news- events/sipnoc-2017-overview/sipnoc-2017-call-for-presentations/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2017. *SIPNOC 2017 Early Bird Registration Info: Deadline September 15, 2017* - *Save $200 *if you register for SIPNOC 2017 by September 15, 2017. - *Register *at https://www.regonline.com/sipnoc2017 *SIPNOC 2017 General Event Information* - For more information about *SIPNOC 2017*, please visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. *SIPNOC 2017 Sponsorship Information* - For information about corporate sponsorship opportunities at *SIPNOC 2017*, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 <(203)%20829-6307> or marc.robins =E2=80=9Cat= =E2=80=9D sipforum.org. *About the SIP Forum* The SIP Forum is an IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as the development of industry recommendations, the SIPit interoperability testing events, special workshops, educational seminars, and general promotion of SIP in the industry. The SIP Forum is also the producer of the annual SIPNOC conferences (for SIP Network Operators Conference), focused on the technical requirements of the service provider community. One of the Forum's notable technical activities is the development of the SIPconnect Technical Recommendation =E2=80=93 a standards-based SIP trunking recommend= ation for direct IP peering and interoperability between IP PBXs and SIP-based service provider networks, and the SIPconnect Certification Testing Program, a unique certification testing program that includes a new certification test suite and test platform, as well as an associated =E2=80=9CSIPconnect Certified=E2=80=9D logo program that provides an offici= al =E2=80=9Cseal of certification=E2=80=9D for companies products and services that have succes= sfully passed the certification test and officially achieved conformance with the SIPconnect specification. Other important Forum initiatives include work in NNI, VRS, and SIP and IPv6. For more information, please visit: https://www.sipforum.org. For more information, please visit: *www.sipnoc.org or email sipnocinfo@sipforum.org * _______________________________________________ fullmembers mailing list fullmembers@sipforum.org http://mail.sipforum.org/mailman/listinfo/fullmembers --001a11474d86c87d4b05566c0a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies to those who might ha= ve already seen this on SIP Forum mailing lists, but I think this conferenc= e is directly relevant to folks doing work in SIP.=C2=A0 This will be the 6= th year for the conference. =C2=A0=C2=A0Th= e conference has been well attended by service providers in the past.

Regards,
Mary.



=
---------- Forwarded message ----------
From:= Marc Robins <marc.robins@sipforu= m.org>
Date: Tue, Aug 8, 2017 at 3:21 PM
Subject: [SIPF= orum-fullmembers] The SIP Forum Opens Call for Presentations and Early-Bird= Registration for SIPNOC 2017
To: fullmembers@sipforum.org


= =C2=A0

=C2=A0

=C2=A0<= u>

The SIP Forum Opens Call for Presentations and= Early-Bird Registration for SIPNOC 2017, November 28 =E2=80=93 30, 2017<= h1 style=3D"margin-bottom:14.5pt;line-height:18pt">Pro= posals now accepted for workshops, panels, speaker presentations and "= Birds of a Feather" sessions addressing the deployment of SIP in servi= ce provider environments; Wireshark Training Workshop included; Registratio= n officially opens

The SIP Forum<= /a> announced today that it has opened registration and the official Call for Presentations for t= he seventh annual SIP = Network Operators Conference (SIPNOC 2017), being held at the Hilton Wa= shington Dulles Hotel in Herndon, VA, November 28 -30, 2017.

A thre= e-day educational conference focusing on the challenges and opportunities r= elated to the deployment of SIP-based carrier services globally, SIPNOC 201= 7 is a unique, network operator-centric event. Organizers invite companies,= executives and industry insiders to propose presentations highlighting the= use of session initiation protocol (SIP) in service provider environments.= Operators are encouraged to present SIP-related success stories, deploymen= t issues and concerns in their networks, while equipment vendors and other = industry stakeholders are invited to work with operators to present real-wo= rld deployment experiences.

The SIPNOC conferences attractleading techni= cal and operations personnel from the global carrier community and have ear= ned high praise from attendees for their educational, non-commercial and te= chnical content that focuses on the real-world challenges operators face wh= en deploying SIP services in global IP networks. SIPNOC 2017 attendees will inc= lude telecommunications providers, major backbone operators, interconnect a= nd wholesale solution providers, ISPs, cable operators, wireless network op= erators as well as large enterprises deploying major SIP initiatives.
The SIP Forum will once again offer specialized training at SIPNOC 2017 p= resented by the expert trainers of ECG, this year focused on learning the n= umerous tips and tricks of Wireshark =E2=80=93 available to all SIPNOC 2017 =E2=80=9CAll-Access= =E2=80=9D and =E2=80=9CFull Member=E2=80=9D attendees at no additional cost= !

This intensive =E2=80=9CWireshark for VoIP Ninjas= =E2=80=9D workshop will equip you with the core and advanced skills you nee= d to diagnose and solve the thorniest problems using the popular, open-sour= ce tool Wireshark. The course prepares to you to install and configure Wire= shark to maximize your effectiveness for VoIP, creating captures, locating = calls and associated media, analyzing QoS for audio and video problems, and= using Wireshark=E2=80=99s analytics tools to find trouble spots in a busy = SIP/IMS VoIP network.

Early-Bird Registration for attending SIPNOC 2017 is= now open, and participants registering before September 15, 2017 save $200= . Click = here to register or visit https://www.regonline.com/sipnoc2017.=

SIP= NOC 2017 Call for Presentations proposals can be submitted = by visiting the SIP Forum = Call for Presentations webpage. Possible topics can include SIP peering= , SIP trunking, Emergency Services, Congestion Control, Scaling and Capacit= y Issues, SIP-based applications, Routing, Security, SIP-Network Operations= Center Best Practices, IPv6 deployment challenges, User-agent Configuratio= n, Standardization Issues and Progress, HD voice deployments, Video Interop= erability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues fa= cing SIP network operations.

SIPNOC 2017 offers several different types= of speaking opportunities including:

    <= li class=3D"MsoNormal" style=3D"line-height:17.25pt">General Session Talks: A General Session presentation = should be on a topic of interest to the general SIPNOC audience, and may be= up to 30 minutes long (including time for Q&A). <= /li>
  • General Sessio= n Panels: Pa= nels are sessions with a moderator and a team of panelists. The panel moder= ator should submit an abstract on the panel topic, a list of panelists, and= how the panel will be organized. Panel selection is based on the importanc= e, originality, focus and timeliness of the topic, expertise of proposed pa= nelists, as well as the potential for informative and controversial discuss= ion.
  • Special Workshops: The SIPNOC 2017 program has been expanded to include specia= l workshops that run for 1-2 hours, providing time to focus in-depth on a v= ariety of issues important to the SIPNOC community. Topics can include a re= view of SIP RFCs and standards development, the regulatory environment, etc= .
  • Research Topics: Researchers are invited to present short summaries of their = work for operator feedback. Topics may include call routing, network perfor= mance, statistical measurement and analysis and protocol development and im= plementation. Studies presented may be works in progress. Researchers from = academia, government, and industry are encouraged to present.=
  • BOFs: BOFs (Birds = of a Feather sessions) are informal sessions on topics which are of interes= t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o= ut areas or in an unscheduled room. Requests for scheduled BOFs can be made= at any time, including on site at the conference.

= =C2=A0

<= /tr>

SIP= NOC 2017 Call for Presentation Key Dates =

=C2=A0

=C2=A0

  • Presentation Abstracts D= ue

September 1, 2017

  • Draft Presentations Due <= u>

September 14, 2017

  • Acceptance Decision and No= tifications

September 20, 2017 <= /u>

  • Draft Program P= ublished

September 20, 2017 =

  • Final Presentation= s Due

October 20, 2017

<= /td>
  • Final Agenda Published =

October 23, 2017

  • = Conference Begins<= /u>

November 28, 2017

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

SIPNOC 2= 017 Call for Presentations General Info To view the officia= l call for presentations, which includes instructions on submitting materia= l and specific SIPNOC policies, please visit https://www.sipforum.org/news-events/sipnoc-2017-ov= erview/sipnoc-2017-call-for-presentations/. To submit, visit = https://www.easychair.org/conferences/?conf=3Dsipnoc2017.

SIPNOC 2017 Early Bird Registration Info: Deadline Septem= ber 15, 2017

SIPNOC 2017 General Even= t Information

SIPNOC 2017 Sponsorship = Information

  • For information about corporate sponsorship opportunities at = SIPNOC 2017, please contact Marc Robins, SIP Forum President and Managing Direc= tor, at 203-829-6307 or marc.robins =E2=80=9Cat=E2=80=9D sipforum.org.

=C2=A0


About the SIP= Forum

The SIP Forum is an IP communications industry association t= hat engages in numerous activities that promote and advance SIP-based techn= ology, such as the development of industry recommendations, the SIPit inter= operability testing events, special workshops, educational seminars, and ge= neral promotion of SIP in the industry. The SIP Forum is also the producer = of the annual SIPNOC conferences (for SIP Network Operators Conference), fo= cused on the technical requirements of the service provider community. One = of the Forum's notable technical activities is the development of the S= IPconnect Technical Recommendation =E2=80=93 a standards-based SIP trunking= recommendation for direct IP peering and interoperability between IP PBXs = and SIP-based service provider networks, and the SIPconnect Certification T= esting Program, a unique certification testing program that includes a new = certification test suite and test platform, as well as an associated =E2=80= =9CSIPconnect Certified=E2=80=9D logo program that provides an official =E2= =80=9Cseal of certification=E2=80=9D for companies products and services th= at have successfully passed the certification test and officially achieved = conformance with the SIPconnect specification. Other important Forum initia= tives include work in NNI, VRS, and SIP and IPv6. For more information, ple= ase visit: https://= www.sipforum.org.


For more information, please visit:
www.sipnoc.org or email sipnocinfo@sipforum.o= rg

<= /td>


_____________= __________________________________
fullmembers mailing list
fullmembers@s= ipforum.org
http://mail.sipforum.org/mailman/listinfo/= fullmembers



--001a11474d86c87d4b05566c0a7e-- From nobody Thu Aug 10 15:27:05 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3B13247D for ; Thu, 10 Aug 2017 15:27:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYX49jv7jzc7 for ; Thu, 10 Aug 2017 15:27:01 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E62132191 for ; Thu, 10 Aug 2017 15:27:01 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id g189so7861329vke.5 for ; Thu, 10 Aug 2017 15:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GZmVNfsKRYQdMEcSjxxLsHrwolHFgcXhLlT7JImDi/0=; b=Oc/QP5LCJeAiUzoxXFzO//nOzVpC8WFn+v1W+vhgF9OIiSmd+eqJ8D+WLrCsGFkJFL YknA1oDyMyBA0dfol2UWtuQTYJpZpSayfXWgVBIm7RXiPSfAtgImgUQ6QQHxWPDRaQHY LG10TIR500Ggt8s3cLUheilzF4np+IxJEzPsglqzT5i+gxZ2pn2b66hy2DM9RQS34yeR BOKuwpUM+WkKRE1ZMGCC7J9mRqmTh9Jfzvbs+T/OqsKL+c4nemfIk28d6bCP9HcQirV5 asTyMOqvYDFyFiLw7igFzyup3G4VOrKE+Qht0LL1xvWPUaGzC5hzBzOEf5lItwf9FgWD ezJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GZmVNfsKRYQdMEcSjxxLsHrwolHFgcXhLlT7JImDi/0=; b=adZLl5I8GnjycB7PnL66S8yirFMPDzFuiMiGTnAhDnF3SmDIGslDwuOBRfTWF8JloH kGSCEPiSz4bvTMJGNfXWTrwv6aZbrwLJU87Se+qLKUIevUzb5qWY898rCS0EHx2vf3hD jkrxB7xQ2OweWSwsMsozQUQBJshIOShxLMlNrW/bRvnO8iPSgTKzKunlzkiY50LTmceE m+wkoW+2/XKjA4r2uZPc48GJvfh4Id2oJhUh7rkksFF6xN4knSh7WKpM6bZavJ7nmjB8 jUZQ39DqRdZOhyF3Gvj+vFceHkGvG+SZISJJt4ZHFYV207pm2cLlO/ZRzfr4ncomlxuv xoTg== X-Gm-Message-State: AHYfb5gE4q+UiH+ORpqx+xACeVTyYFhxJJPTR8cKY6OPv2W03egdaEK7 xSRNdPLgXtEJ6AFECzVIMQcFy/BeV/hBgj0= X-Received: by 10.31.92.133 with SMTP id q127mr1491114vkb.212.1502404020344; Thu, 10 Aug 2017 15:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.146.194 with HTTP; Thu, 10 Aug 2017 15:27:00 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:9127:a02:f07:8914] From: George Michaelson Date: Fri, 11 Aug 2017 08:27:00 +1000 Message-ID: To: dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 22:27:03 -0000 Support. I admit to being torn on one aspect of this, the encoding. Expediency, simplicity, one-shot-and-its-done says mime encode wire format and use it as a simple transport. Leverage all the benefits of HTTP(S) and CDN, distribute, get underlying protocol benefits because we can now understand payload says 'work harder, do JSON' But I think irrespective a small charter, focussed WG to get something out is good. -G From nobody Fri Aug 11 08:56:20 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2E132655 for ; Fri, 11 Aug 2017 08:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZZefcjX1UUu for ; Fri, 11 Aug 2017 08:56:17 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0119.outbound.protection.outlook.com [104.47.92.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7882B13265A for ; Fri, 11 Aug 2017 08:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l2K4eqsHF8rqIVMx2zjrtf1CAGGn2BUMHfcYhAzsjHs=; b=LJOzPznqcun0OoWPvcsHMR/fPx9ATQZ1N4cLNWJP2ATSqRnaERMwsOdjrqkI7AqSlwoFNdYDEMj5hQWe0g01xY26gxvHtSCu5M8+JKFF5TsBGuo+LTKT7SJxTh2iHFgjxlSZ88fShhAEWv7WIrDuvs2K/SFJSoStLCuqf0QENno= Received: from [10.147.243.74] (194.230.155.149) by TY1PR01MB0254.jpnprd01.prod.outlook.com (10.161.135.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Fri, 11 Aug 2017 15:56:13 +0000 To: Paul Hoffman , "dispatch@ietf.org" References: <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56675174-6fcf-64ba-8e49-a46a822e177d@it.aoyama.ac.jp> Date: Fri, 11 Aug 2017 15:12:13 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9099E13A-8EA1-4905-9E87-6FA383C55FE7@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [194.230.155.149] X-ClientProxiedBy: HE1PR0902CA0060.eurprd09.prod.outlook.com (10.170.250.177) To TY1PR01MB0254.jpnprd01.prod.outlook.com (10.161.135.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3aea3bd6-e9c2-4a93-7fd2-08d4e0d17eff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:TY1PR01MB0254; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 3:pAyi5siR2VIlmQe87DFitkfzoHZM96fJcexyiZphTT9urL0RsJYA9F6j+fw3F6dHADmGZ77/ydSW/AcunjVJIDCqgn8Hk7hW8ESWTSm61is/EqV4OZYiSIMjZxZPLIsz3SWxknYRIEgOwPs2aDijjv6RG9Ml2qriseyCcL3U5GaMIOdL48rydsx2uG0EZYTYzltrg/sILMbm6KlY5DUtOMGM5g/30K8yOCehywuDb0aNr3tAV3HVfP0x9MGtdpDW; 25:/Ir/A9875LzqlKXtEHC5MDi4aVqUuzfo9+uR8GgQ0L/y544xwENQrPtIUjkRnEoN+M+YBzBLoqOIeS81Vaxo2UvbDrwxVDt9MB+wCsABionYFxxDJCuO5hfGToFq+fvIPMqkCE0pcYtqF06Gl3kDOi02xxTLZ+on2S/gwpRfEEynrAWyVCFxYDAENqirgpO5s/LV36BCbE+CHJyLLdkJdFiwQMw02e/9MIlKjhzKQm6r1TQ6nVgrCZU3EOtgv+z1kVIXTc+MQ4FPMzqmlo3BgRWvY0FK4Hm7+ZATbfJdegqBNiSlPov2dRpF1y4aw/+Nu2h9wX40kSCvN+1+Xw1A5Q==; 31:4e7+dYHhgT4XBeMC/xM57BrHO7hPLlQb0w9FutlBaa/W179csKycQkm2CrFvuDePozGKbXhR83EOqQbaMLpQO4ecDJQmMxvOPM9iiQKYjyoLgEXPiNnzpCAG2uux0lHt0APc7V2+D3TSpOaCjmTtE3lUj5y4umfdFeWj8/1A+X4amWgW0CYnXlXc6Xzt6rQEuRPeLglW8wWAvSeIi2vsBtOfJV6hDynI3IU3aONUZVk= X-MS-TrafficTypeDiagnostic: TY1PR01MB0254: X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(2016111802025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:TY1PR01MB0254; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:TY1PR01MB0254; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 4:4Qo6bxh1KbHazg80VyUn+4PcY6GjSvbOhiqkAlFlJM9Ei0tqeAbJIwXAy+dXWOKJPcElEvBaphGq04FbR3GHoQE2R7tWDGlVYWtqK/Q9+hcZmIr64z9v2WFg/zM6UpK1Xx4s5aLhUUTS7Z8hZMSsMqFdgxQ25t4ET1xsFCg9J+IC23AQ2cYmrI4PtfuRMp1HXWkKoWozBTvKYJDDNtBxTVZTTCYr6ToXjKwddpeAX0gKdzmjhLSy65oYZ+I7MVwo X-Forefront-PRVS: 03965EFC76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39830400002)(199003)(189002)(24454002)(31696002)(68736007)(189998001)(33646002)(86362001)(230700001)(101416001)(31686004)(7350300001)(77096006)(6486002)(6246003)(53546010)(53936002)(90366009)(74482002)(97736004)(42882006)(2950100002)(561944003)(8676002)(81166006)(81156014)(229853002)(478600001)(4001350100001)(47776003)(42186005)(83506001)(65806001)(64126003)(25786009)(65956001)(50466002)(23676002)(66066001)(305945005)(7736002)(65826007)(106356001)(2906002)(105586002)(5660300001)(76176999)(50986999)(54356999)(6116002)(2501003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0254; H:[10.147.243.74]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMjU0OzIzOmRScDlPS3RqSlZjQ1lyZldUZURMeXU5TFJP?= =?utf-8?B?SXJOTDJlRGh4ZzhUQlFJN3JscGRlMVByWFdBblo0TFZxeWxEcFFSQ0xmU0dp?= =?utf-8?B?eXlLdXY0VkJodmtlS1c4aXUwNWNpK0JRVDFwWmhwOUl6VjIvYkIvM3VYbURy?= =?utf-8?B?K2hlSWVsNk9Uakt3endWODMyVDRmaDNSMWRBNEFsb1o2T1BsYzRDb0FLTWti?= =?utf-8?B?QjY0b3JkU1JmQjNaak5PdHJTYmpBeWFzUFJadWxIaVRoK3FBSzR1NlN5M3cv?= =?utf-8?B?SzNxT2J0K2dvd2M2TjJUbm5iV0xQK2swSjJIeThwcCsrYXFrNlV6MzJtNHVU?= =?utf-8?B?LzZ1OHFYNmR3L0o0MFFabmZ3aGdVVGxoVzBZbWllY0JxRldPaDJwdVovRmZl?= =?utf-8?B?NXU3V1lsZUNSZGttSVBvNTM4T3FTb3J6eWtqVEZORVFYYUFJaGx4VkdONGJS?= =?utf-8?B?Q09xY1JaZGc2TnY2cS9TWjQyZElXdWFpUWlQL3JkNXZteUpDZktWMUpZRHlo?= =?utf-8?B?K205d2o5OUlHS3MybHJZOExXME1QVUtTZjdrWitvVUsyQWFqUXlOOGtVYVRF?= =?utf-8?B?dFo2Y3kwL3czMkJCcDNLcTBNZGwrYjlEbmxtcCt2WHBKV1NYcjc2cWJIZWla?= =?utf-8?B?SHlZWDZ6ZzdDNXVKblpEcUJsU3A2dGkyT1pzTmNhaTlBOXdiUzRkdjFsZ0Yw?= =?utf-8?B?ZzFqWEJ0OVl6ZzJ6Y2JsYjlUNEpZVVZueE1uTU93TmErTkVaRG80cU91bDVt?= =?utf-8?B?bEllY05KRGFINGRhbzJUUWdtUW1ScmtVWklHTDIrdng0ZythbVcrZmF4Sjl4?= =?utf-8?B?QTVnbENsNloyS0ZrbklmQVBPZXE3K0d1Z3M4N25DYnBKcGZ4di9VenlyYzJw?= =?utf-8?B?VE5DWm0vWU1WL0ZveTlVeWMxRjZFUlNKNmtIenJBTWw3RStqS2krektKZ1dW?= =?utf-8?B?MkJVWjQ5ZUhhN01yYnlPUTNBdFVYWW0yR1ByWDRBRU4rY0dWV0JmbEVtQnlK?= =?utf-8?B?dmR5S20zYUJpL1NIVlZtNkZ3VG9qbnQybXBKeUxpS0JSTzR0T2x0ZTBXcXNo?= =?utf-8?B?bGFFRUtpQzUrSzMvS2ZFeEpVR3h5ZnpyekV4aTRobzJtcVZIYmEvd0ZNMFJw?= =?utf-8?B?Qk9RNFp5dGFzOS8yc1ZydmtFYzN0WWorcnlwQS9kZXNUZmNPem5qRTB1djY3?= =?utf-8?B?SVp2M1JZbng2MmRzclQ1ajBIYkpuMTNyeU1vcjRiVTNzeFc2dzJOb3hGUGNz?= =?utf-8?B?MmFTTitYQnZqQnhEL1BoclY1cDdPT1JoVWN1dFFQK0s4WHNrS1NLbm5nUXBl?= =?utf-8?B?M2QzMXB4TlluY1dUdzFKMVpSTlNlSHoyRXRoSUw2a0MyM2VNbWFDeTAzZ2FB?= =?utf-8?B?Y1V0R1MxWkN6R0lyQ1p0YTkzdmlhZXFSMHVqZDNhRXVKN0kwZ2NNL3E4aXow?= =?utf-8?B?bkxwSWVpeG5mUnNvMHBrTGNnbjFaRG5CYldueFBRT29XSnh3cm5KRDMwRG9M?= =?utf-8?B?U2JwVEJuTnFBTlh2Q1hndlhzNXIyakVpdHRGTzNYcHhZci9mY01wR1MrMTgr?= =?utf-8?B?Z05LNW5NODlrQ2VOanBhdE5qU09hQWVhSzY2Sk9JTnVDNXQ4MmZkbHNkNWNV?= =?utf-8?B?aWJpWTQ3bkRPVXdFempTM2kvRlhDWitFOXpNWUhEYVgwakFaYmV0QjdUZ1dK?= =?utf-8?B?T2g4WWpIZUVQZi9OT2ZjTUo4cThMY2pEbnRSU2pJWEx2ZTc3M2k5MEZnSTFW?= =?utf-8?B?Tit5eTFjUlhRbk9DZUNkenM0ZHYzajBxdjBNL2J4cnJ0Sk1BckU0am9oSTli?= =?utf-8?B?eWxQUElZbFdNTzJxczdGNnh3R2hXeVBhbGRndXZFQzVEZDVpM3N2b05RYmUz?= =?utf-8?Q?pianhid7noE=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0254; 6:9CVOSb+vevblbnrxO8a4+bLS18iPBp0Dr3XCcrrrg1wwuW06eGNfTAYu55UIjLLYwY5OO2bn5cDG0MwtJCwJovGYm8EYuKLC25WKmA9z7u3aq0k15CxgaMtmw6u57If9Q/8IRMYkW+0osF4Dm+8UFq30dUNvcmWBj8ulH0vIgmBQHHcBDrvQuaoLJnovmuYsxzbmKG9RvRu69mnzi1o7rhO6us+ko2l9j8HCA7nHPuUyWAT2GuTOnkm3Cq13UDuSGDuHdJPJTBdLsVCE0uC5N+B6kUdXnPhG+yeyUnaRXfFKZXLTMlpEvkqXj8g/M6FBThgWK8rT54ojk1syOEn6UQ==; 5:YKKSFjpDsg8UYLy5il4esPD06OIwa8l2h7KWMRKFywdaT5+V29PB8edZgwok+7aTxnsQKGB749l7qMdgpJfUl5RuPJv+jp7kcSs5gwwOVTksYRz/NR4eRR1328UGh9fYjbXWfSFJGeQ9dDA6pqfeDg==; 24:vp66kMMuR0w5j97QENZ8aiHJE8Hytc5Un9isw9mvX78BqFnI2ve8T+Ht27mX14NlnlHASNDkxkeOODkd3CRdWgyPSUyr0oRlnLmQWJqynwE=; 7:2U3sYSxfdTMz33F6vcEInnp4MWfOG/qwLC4w3hyTcWHTHxO/afC7F0LoBEpIdpW2nLwJKjW+xRLJKXU/XESbnOPFMNHtvCjlANLVKz1FETsYkEg5+F9vNbjBgsUmb0xUJhF+RG35Ld4Dg4HZEuFa1SPzV4rwXLi9tmT3ylGgMv0zar3P825naj1Z8aE7CFkn8wO9521PFh7H0+CmG6e7+ebcfeRrhEDJUa3OQrW0TkU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2017 15:56:13.0167 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0254 Archived-At: Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 15:56:20 -0000 Just some minor wording tweak; otherwise, I think this proposal is fine. On 2017/08/10 23:38, Paul Hoffman wrote: > Greetings. Alexey asked Patrick and I to send this to DISPATCH to get discussion going. > > --Paul Hoffman and Patrick McManus > > > Working Group: DNS Over HTTPS (DOH) > > DNS queries sometimes experience problems with end-to-end connectivity at times and places where HTTPS flows freely. The use of HTTPS provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTP infrastructure and policy. > > The WG will standardize how HTTP clients can encode DNS queries and interpret DNS responses. > > The WG will use best-practice HTTP semantics. > > Specification of how the DNS data may used for new use cases, and the discovery of the DOH servers, are out of scope for the WG. "may used" -> "may be used" > The WG will begin its work based on draft-hoffman-dispatch-dns-over-https. > > The WG will deliver a document describing how to obtain and interpret DNS information using the HTTP protocol, with an IETF Last Call expected in December 2017. From nobody Wed Aug 16 21:03:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5AE1323B3 for ; Wed, 16 Aug 2017 21:03:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGyIMIEf45yE for ; Wed, 16 Aug 2017 21:03:27 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238C91241F5 for ; Wed, 16 Aug 2017 21:03:27 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g35so19462247ioi.3 for ; Wed, 16 Aug 2017 21:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:cc:to:from:subject:message-id:date:user-agent:mime-version; bh=3Mv6zxxFEAhjbv9jbYIdt5lKvXNfCJ4kpgwg/KLzzg4=; b=c+iDYvwW8Hqfme0kFoBE1rhsH7UaeYmThRHB0e9twDBpLiqGRSf7I16k4oMk2STPkV arqf5C4ezn7Xm4bPzzI16kZwJPQ2+d7kI9HKK/5Y2imtsHYfS1i9RnN8cKSzp0aL+Cwy NEVUzNF1dlQU9PituMtHCXHdb352IRu0rLFZ2M0i89s2rlcg9OSWOR3ItfGjnscKdfpP DUymzjmiCIfw6Cz2mbdio68CUkPMOiALyRRp5kFr6qlSOEQ5V4bTIfVMv+EogpwysIPY Xyl88TJ2APo2gk7BlRejqoTEbemW07Lmjo/XLXUR2ygDVFOh3Y01FefSHIpMcXmutMcI isEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:cc:to:from:subject:message-id:date :user-agent:mime-version; bh=3Mv6zxxFEAhjbv9jbYIdt5lKvXNfCJ4kpgwg/KLzzg4=; b=iAg1kBDaT8gSW8Yqs4sjBqGeDZj8DsVDI8A72xi5nD4z7OsNa+uLEcnJ0eAk0Zsr8S lq/jCuQn7kMu/jNMabXxL6gIJVvgB/2YNINL1HMz57m0rkfETI0rSg07sfsuKcCw3qbD p3W/YXS2PCGji7zur1mxXT9V6b7KIpDXzU1JPCkJqfMOfkZLfMjKMdwvLloa0Yf0PKR8 FokM/NYVAxlUeMa3VLeoU75a2ZV3OTe2A9Y4QO55COtfjB+gm3jP6eFDpZ6dR4WnOwbX /6VVhfAIjvKGfqx2jBzBa8Z6in12Cl2ta+DF0UZRMiihrV2GXH2q5mXDjOCErEa6Q/2n 2wRw== X-Gm-Message-State: AHYfb5hwiUB5c8HHRB9mmigV9BROAQNoxy3K/1W3Ql0HFxwtnl/8BW7f cP/Lr/PnukyaM6ES X-Received: by 10.107.191.195 with SMTP id p186mr3455343iof.104.1502942606464; Wed, 16 Aug 2017 21:03:26 -0700 (PDT) Received: from [192.168.29.239] (c-73-217-32-196.hsd1.co.comcast.net. [73.217.32.196]) by smtp.gmail.com with ESMTPSA id d96sm1088640ioj.75.2017.08.16.21.03.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 21:03:25 -0700 (PDT) Sender: Matthew Miller Cc: Bradley Meck To: dispatch@ietf.org From: "Matthew A. Miller" Message-ID: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> Date: Wed, 16 Aug 2017 22:03:25 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OoCPicR91O7VmcfcnEE26ONMksdTbfmQJ" Archived-At: Subject: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:03:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OoCPicR91O7VmcfcnEE26ONMksdTbfmQJ Content-Type: multipart/mixed; boundary="NaJqhAEWci1M0MP3qButjMbrAo9EbHege"; protected-headers="v1" From: "Matthew A. Miller" To: dispatch@ietf.org Cc: Bradley Meck Message-ID: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> Subject: Dispatching Work on ECMAScript Media Types Updates --NaJqhAEWci1M0MP3qButjMbrAo9EbHege Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello DISPATCH, The ECMAScript/JavaScript media types are in need of some updates. We've started an informational document[1] to address that. There hasn't been much mailing list discussion yet, but we are asking now where to direct the work. In consultation with the ART Directors, we ask this document be adopted by DISPATCH as one of its simple administrative documents. The document is < https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >. Issues can be filed on the GitHub repository at < https://github.com/bmeck/I-D/issues >. Thank you, --=20 - m&m Matthew A. Miller --NaJqhAEWci1M0MP3qButjMbrAo9EbHege-- --OoCPicR91O7VmcfcnEE26ONMksdTbfmQJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZlRWNAAoJEOz0ck4QngW7dwMH/iKb6CLswOTUoJYkzDNfnJgr /m2tclx/CzgxxpNWa3vTmT9LDGY/M4wi1FuHEqTLv+uMPb4Llg8fs6PiZoZ4Cyza kbWzvkXx1Svn4BL4tdo+j/XF8yO6alUFph9fL2XhWuArSkx/J+6lhiU0pMa2q0Es iP57jukL9DX0uo6pUzkMZfiatSRnErXeEqFQmBBJka6TP+qQcRzEG4C736wcbBmt OzQE7JEElJMipsZcuuuVQ4fOnJ7rSDp+Y98daLGUpi9oelUAQnGBO9TRBiLqMLXV SwQ5myCJFcsfsubvaTabSEzcr6ehAfO5i5kFt7d3iw+xjrfuGGfriCq2sDMRQJs= =bQc3 -----END PGP SIGNATURE----- --OoCPicR91O7VmcfcnEE26ONMksdTbfmQJ-- From nobody Wed Aug 16 22:14:29 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350F7124E15 for ; Wed, 16 Aug 2017 22:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DDnFR_XjFCG for ; Wed, 16 Aug 2017 22:14:26 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8821201F8 for ; Wed, 16 Aug 2017 22:14:26 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c74so19763522iod.4 for ; Wed, 16 Aug 2017 22:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5dsq0fPSXwY/xLY+g6n1rH78alWAxUAKwX2ziLhlvP0=; b=tSCrBAz32J8D0LL3DTRhW7nKfoqbpjc6qnweoPXJlQZ+xXSd0nceWN1ZwMxiURA89u Jf8Y9TYz5NXsTaDC9OdAZtM9lnrqqMBCsJPYMx/hW76Zye1Gh9qFM6w+zN9snfl4ABla G3AVCn4Bh0ZyFfjdomFfjWHABK9Xn5u7gzLvEtzJV8QRbeZm468nwJuKroqYWikUfFL2 u4gbe+2zbVVZrNG/bQJEaxMEFCW1y+5dUZiC5dSZi73Lqsfj30Q2gXFXOxqkA+tPScMg P4OHv6U7oTJRjfMD9et3FQyFDenYHs6pXFaeZrTHzTHY3JgFIA4lTJ0zULDi6N5rkbEm DU5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5dsq0fPSXwY/xLY+g6n1rH78alWAxUAKwX2ziLhlvP0=; b=VY0eLtTAvLPvWYUeNWnyf/xf+DpYemEgwds+dInPUJoCGs/D0zGZmxQo6f91DDRP21 aJnGdN2UCn+2qwJWZJ23r88JE92Wc5P0PZijgIECWDge4U0LF08914grXbAspGcld8Gj uqxH5CAEtajwjZ/k4sCUsHbBIEDgSleZKVaOOuadUrGmzz1WVFFYud1fRhZ+uLqFW2OQ gjs0Wps0VVx1gTsKogWCfQAF8kv21jy3I6Uamvt0nKWfaog2QmH964aCrqXOYkT2giZy DrH9MPQ9+BZOIACxzIj6YwZnDyN+0/HR9giTwR+TJ/bHE11+WGm/0QTIvCo9GVS4ew5R KwLw== X-Gm-Message-State: AHYfb5ic5Yk70niaQYZ2lAtgcMpq01Ck4cbaDos5kwIoO4pDYjely/vo bhjxDhU/DXhWRNCQXTMS+d3Cy/l4iw== X-Received: by 10.107.201.65 with SMTP id z62mr4049984iof.74.1502946865499; Wed, 16 Aug 2017 22:14:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 22:14:24 -0700 (PDT) In-Reply-To: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> From: Martin Thomson Date: Thu, 17 Aug 2017 15:14:24 +1000 Message-ID: To: "Matthew A. Miller" Cc: DISPATCH , Bradley Meck Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:14:28 -0000 Hi Matt, First, this seems fine, almost trivial. This statement implies a problem of greater scope than what you are solving: It is not possible to fully determine if a Source Text of ECMAScript is meant to be parsed in the Module or Script grammar goals based upon content alone. My initial reaction to this statement was: so why aren't we seeing a request for a new media type? You neglect to mention that uses of the module on the web do not depend on additional distinguishing marks because they have the type="module" attribute on script tags. Nit: There Are So Many Proper Nouns In This Document. Is that really necessary? On 17 August 2017 at 14:03, Matthew A. Miller wrote: > Hello DISPATCH, > > The ECMAScript/JavaScript media types are in need of some updates. > We've started an informational document[1] to address that. There > hasn't been much mailing list discussion yet, but we are asking now > where to direct the work. > > In consultation with the ART Directors, we ask this document be adopted > by DISPATCH as one of its simple administrative documents. > > The document is < > https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >. > > Issues can be filed on the GitHub repository at < > https://github.com/bmeck/I-D/issues >. > > > Thank you, > > -- > - m&m > > Matthew A. Miller > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Aug 17 03:03:30 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47D113239C for ; Thu, 17 Aug 2017 03:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOHdF_ZerCiO for ; Thu, 17 Aug 2017 03:03:26 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBD41321A8 for ; Thu, 17 Aug 2017 03:03:26 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id j32so21445960iod.0 for ; Thu, 17 Aug 2017 03:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JAgrIbMC+rGvx+8yuaHveYj/XmmR3jmLXSFLNxJBUt8=; b=qWrx0FYImEkNpLbbKR3/kzezSYJbu5XTEfxui0Xh9KBpqVK3suLO9J8e4L93vZXifp wrOj+K/47Kht2O3QE+7cUf115/XN1GQwMM545ifHaF+VMrU2WLEUcwPkU/fx+RChg8p1 GFs4nu+jPMqkvk0f2OeIQGmuK9vGsdKvUNx7XRelQyCQy1AICD/VseEhChD+QcPgWQlf Xj/CNG9v9w0pd6ltTJqH9uu4YyHwLt4mTFS7fRPNqDJ8Ai7uKGybaksKTSLkH5cfIkNc 8VXHfTMqQyYn7eQx9LydAPbF1n+u0Wo3IxTuYDrYilKRbXN+yfV4uzdToQA6XkEiW+Gj YC6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JAgrIbMC+rGvx+8yuaHveYj/XmmR3jmLXSFLNxJBUt8=; b=ZuuhXsS/bZY6gv8zjuhQV0DnUgNe1f5k5S55dAyxjuGqrjTNN7iBvjEGnykguGAloI 70G6HnSzCF+0KMbkhwb5fg+n2Rj8In6Yc3xtuiM4a8yQMPLdrkLJKOBoLf87LUZ83e29 orFBmAYIXDPyBe/0XeyNH/dvSgOUyS5hAFmkuzkuTBIkzYnfMRcseWkL/py/EZmJKJH5 q9pBT1t6wptYWnoeGEK5Xe0UyU9GAKmvYo5dxvM97uUeEM5YzA+qlLMuYLG3xNBEwPgu DXs8AiaYdjkbiqMQ4O9WN+CKj1JVYrAtGYAndQWX+9BRfbeOeoMFWluTYglRVV0fE0pe 1yrw== X-Gm-Message-State: AHYfb5iPKch+6BpQysXLk+2yJLwpqkU9FZb6ZxwvdwyLuhWriNdi75Cq P3tA8MHQRjmFTE9fx8SrgXzM5voOsA== X-Received: by 10.107.172.199 with SMTP id v190mr4147960ioe.159.1502964205749; Thu, 17 Aug 2017 03:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.143.80 with HTTP; Thu, 17 Aug 2017 03:03:05 -0700 (PDT) In-Reply-To: References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> From: Bradley Meck Date: Thu, 17 Aug 2017 05:03:05 -0500 Message-ID: To: Martin Thomson Cc: "Matthew A. Miller" , DISPATCH Content-Type: multipart/alternative; boundary="001a1148d734980c1b0556f01f29" Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:03:29 -0000 --001a1148d734980c1b0556f01f29 Content-Type: text/plain; charset="UTF-8" Hiya! > My initial reaction to this statement was: so why aren't we seeing a request for a new media type? This was discussed in a few different places, ultimately culminating in no body wanting to take that route. You can read some info on that in the link to the informative TC39 issue https://github.com/tc39/ecma262/issues/322. It appears you might be more interested in the HTML side of things, which would be that a new media type would not load with the specification they have already started deploying ( there was an issue about this on HTML side in https://github.com/whatwg/html/issues/558 ). Some discussion about a `mode` parameter instead of media type is in an issue on this proposal https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That might be the better route since it will work in web browsers. > You neglect to mention that uses of the module on the web do not depend on additional distinguishing marks because they have the type="module" attribute on script tags. This is out of band information not based upon content. I did not think it necessary. Should it be mentioned if it is not based upon message content nor information in the media type fields? I think that this statement also applies to some tools such as module bundlers as well that are using fields in package.json files. > Nit: There Are So Many Proper Nouns In This Document. Is that really necessary? I think this is in part a stylistic thing of my writing. I tend to avoid pronouns and am capitalizing grammar productions in the same manner as the ECMAScript specification. We could make stylistic changes though! -Brad On Thu, Aug 17, 2017 at 12:14 AM, Martin Thomson wrote: > Hi Matt, > > First, this seems fine, almost trivial. > > This statement implies a problem of greater scope than what you are > solving: > > It is not possible to fully determine if a Source Text of ECMAScript > is meant to be parsed in the Module or Script grammar goals based > upon content alone. > > My initial reaction to this statement was: so why aren't we seeing a > request for a new media type? > > You neglect to mention that uses of the module on the web do not > depend on additional distinguishing marks because they have the > type="module" attribute on script tags. > > Nit: There Are So Many Proper Nouns In This Document. Is that really > necessary? > > On 17 August 2017 at 14:03, Matthew A. Miller > wrote: > > Hello DISPATCH, > > > > The ECMAScript/JavaScript media types are in need of some updates. > > We've started an informational document[1] to address that. There > > hasn't been much mailing list discussion yet, but we are asking now > > where to direct the work. > > > > In consultation with the ART Directors, we ask this document be adopted > > by DISPATCH as one of its simple administrative documents. > > > > The document is < > > https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >. > > > > Issues can be filed on the GitHub repository at < > > https://github.com/bmeck/I-D/issues >. > > > > > > Thank you, > > > > -- > > - m&m > > > > Matthew A. Miller > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > --001a1148d734980c1b0556f01f29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hiya!

>=C2=A0My initial reaction to this statement was: so why aren't we s= eeing a
request for a new medi= a type?

<= span style=3D"font-size:12.8px">This was discussed in a few different place= s, ultimately culminating in no body wanting to take that route. You can re= ad some info on that in the link to the informative TC39 issue=C2=A0https://github.com/tc39/ecm= a262/issues/322. It appears you might be more interested in the HTML si= de of things, which would be that a new media type would not load with the = specification they have already started deploying ( there was an issue abou= t this on HTML side in=C2=A0https://github.com/whatwg/html/issues/558=C2=A0). Some discussio= n about a `mode` parameter instead of media type is in an issue on this pro= posal=C2=A0https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 .= That might be the better route since it will work in web browsers.<= /div>

>=C2=A0Yo= u neglect to mention that uses of the module on the web do not
= depend on additional distinguishing marks = because they have the
type=3D"module" attribute on script tags.=

This is out of band information not based upon content. I= did not think it necessary. Should it be mentioned if it is not based upon= message content nor information in the media type fields? I think that thi= s statement also applies to some tools such as module bundlers as well that= are using fields in package.json files.

>= =C2=A0Nit: There Are So Many Proper= Nouns In This Document.=C2=A0 Is that really necessary?
<= span style=3D"font-size:12.8px">
I think this is in part a stylistic thing of my writing. I tend= to avoid pronouns and am capitalizing grammar productions in the same mann= er as the ECMAScript specification. We could make stylistic changes though!=

-Brad

On Thu, Aug 17, 2017 at 12:14 AM, Mar= tin Thomson <martin.thomson@gmail.com> wrote:
Hi Matt,

First, this seems fine, almost trivial.

This statement implies a problem of greater scope than what you are solving= :

=C2=A0 =C2=A0It is not possible to fully determine if a Source Text of ECMA= Script
=C2=A0 =C2=A0is meant to be parsed in the Module or Script grammar goals ba= sed
=C2=A0 =C2=A0upon content alone.

My initial reaction to this statement was: so why aren't we seeing a request for a new media type?

You neglect to mention that uses of the module on the web do not
depend on additional distinguishing marks because they have the
type=3D"module" attribute on script tags.

Nit: There Are So Many Proper Nouns In This Document.=C2=A0 Is that really = necessary?

On 17 August 2017 at 14:03, Matthew A. Miller
<linuxwolf+ietf@outer-planes.net> wrote:
> Hello DISPATCH,
>
> The ECMAScript/JavaScript media types are in need of some updates.
> We've started an informational document[1] to address that.=C2=A0 = There
> hasn't been much mailing list discussion yet, but we are asking no= w
> where to direct the work.
>
> In consultation with the ART Directors, we ask this document be adopte= d
> by DISPATCH as one of its simple administrative documents.
>
> The document is <
> https://datatracker.ietf.org/= doc/draft-bfarias-javascript-mjs >.
>
> Issues can be filed on the GitHub repository at <
> https://github.com/bmeck/I-D/issues >.
>
>
> Thank you,
>
> --
> - m&m
>
> Matthew A. Miller
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispat= ch
>

--001a1148d734980c1b0556f01f29-- From nobody Thu Aug 17 04:38:42 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D087132113 for ; Thu, 17 Aug 2017 04:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUiCx6TvglnU for ; Thu, 17 Aug 2017 04:38:38 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA85126DD9 for ; Thu, 17 Aug 2017 04:38:38 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 76so29603718ith.0 for ; Thu, 17 Aug 2017 04:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qlz5nbM6mlMtuquEgrxOOB4c3KeqAbszDah3H4ZWVpA=; b=aGZTzrn3XR2yaIXgguH5sC/cd7oekLonKSPDGhSU6uSo77sM3JH+UXDkGIjV4koMCf 7sedcq/chqeOsWXOYjCAsfskoUNsQGPT8ngAzBnN2D0dWfwwytWWhousoZBd2igFDVTt hiG/C7xne+okOQthCax/zevCPKljkyPNVPgZfm5qLl8tpmWkz0ZXvSQof7VjO3II18j/ SnfMxFz2mUwq5Ejbx4wDBUClaI7t0Fju9BQIImJ9QBjfpl+ummwhFeaxnhHqA5Q4thO8 ch5a+OHDZF/iBStdcF3+52DeNGVKYDVfMh3Iv6XN5OHI/wZwzniPgus2+8VMc90Uk/O8 dHSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qlz5nbM6mlMtuquEgrxOOB4c3KeqAbszDah3H4ZWVpA=; b=mBO/s/3x94iYth1l2X1yNHzr3DPMln1XC5T0Bolu0qdLBd3lVn7Z6gt467YH3jDdyY 6mJMqmIRPzylwS5wtUX+fKm0roH+nh6DCPtKKuaSWyIL7Asmi7ftuepBE54AK6eRhEah zrBFyiNm2hCYGDwCf5BuIl6fV6M3Oq2cTdzY5iyz60cUmtZuMzNal5nEzHcUmcowRe+8 HbonfPbpUhBoUeESynEWroGx9HDNn7S4di04wqDNfPE9roYu8LIESqYHEGiLXjX+j76F CxYDJJ1YEOJLZTpe2A2GMirYXKA/EN20GnpXjr6o5VCCh4bbxds/A/eqAoylN1osCFHd GKrw== X-Gm-Message-State: AHYfb5g/0ixIYNZ58ChhUbHlAxMeETNKoDx47pwJJPDURiTaUtq4+Czt z2ZFFpOrkc8nbS1JP7JL3w9do+Z1AQ== X-Received: by 10.36.181.85 with SMTP id j21mr1348399iti.165.1502969917755; Thu, 17 Aug 2017 04:38:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 17 Aug 2017 04:38:36 -0700 (PDT) In-Reply-To: References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> From: Martin Thomson Date: Thu, 17 Aug 2017 21:38:36 +1000 Message-ID: To: Bradley Meck Cc: "Matthew A. Miller" , DISPATCH Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 11:38:40 -0000 On 17 August 2017 at 20:03, Bradley Meck wrote: >> My initial reaction to this statement was: so why aren't we seeing a > request for a new media type? > > This was discussed in a few different places, ultimately culminating in no > body wanting to take that route. You can read some info on that in the link > to the informative TC39 issue https://github.com/tc39/ecma262/issues/322. It > appears you might be more interested in the HTML side of things, which would > be that a new media type would not load with the specification they have > already started deploying ( there was an issue about this on HTML side in > https://github.com/whatwg/html/issues/558 ). Some discussion about a `mode` > parameter instead of media type is in an issue on this proposal > https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That might be > the better route since it will work in web browsers. I'm not questioning the decision (though I appreciate the pointers, thanks), just pointing out that there is an obvious question arising from your introductory text. You don't need to defend the decision, but you should answer that question by mentioning that link metadata (type=module) ensures that no one else asks the question. The discussion (and outcome if I'm reading correctly) on #1 leading to mode= certainly seems sensible. Please pick a default of mode=script and save us all headaches. Question, mainly for my gratification: if I include a module in a , how do I signal that it's a module? You can't use a type= attribute there, because that key is taken for something else (media type). I know that browsers like doing things like pre-parsing in addition to preloading. I have to assume that you just use native es6 modules keywords rather than importScript in workers, so you don't need explicit identification there. >> Nit: There Are So Many Proper Nouns In This Document. Is that really >> necessary? > > I think this is in part a stylistic thing of my writing. I tend to avoid > pronouns and am capitalizing grammar productions in the same manner as the > ECMAScript specification. We could make stylistic changes though! Consistency good >> Too Many Capitals Are Bad (In other words, don't change on my account.) From nobody Thu Aug 17 06:24:01 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8437C132510 for ; Thu, 17 Aug 2017 06:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou005vT78dTE for ; Thu, 17 Aug 2017 06:23:51 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAADF12700F for ; Thu, 17 Aug 2017 06:23:51 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g35so22890698ioi.3 for ; Thu, 17 Aug 2017 06:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u621bOGBxuBaLWigGJqVNaxCFJXOzzu5IGLrvYhJ3ck=; b=Ui8FqIjO9VtApKyWO74ZaHdP1aD4njihAd06AJQ+709z1rF2Yh+VtlYGX1DMgRb2Pf vdfX5PN7YFerd+AS/qGnSFH20H1hixA9140TQhttNsDFR4C6l0XmuIcec5Qm6OqRCvSx BJJbp9fNpeFVDWze/1zQc+R14OVtzRPjh2SQSoXY4qbMyD0nHZOHruklZEgXLENS2MEZ i+2ROPcbCRgss54dTUiohqYEMD7EfbduKHlbYMYmyhFFZqaDJrGaeTOuV4jRkmSFoDNC HCtbcTXI6s54L86BZ29jRjX4wjp9i0yKNb19K5IosvSQGAECoWsUr5plQtNu3F+dk+Uf 4s5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u621bOGBxuBaLWigGJqVNaxCFJXOzzu5IGLrvYhJ3ck=; b=Lht0ylvN+3D4Y7xzBD95YNyDJ8swNc234dc0xDedGeKQ9IalFHsuA2S9S4+4oErHD2 5AESu6jtXvNlh10lfQX66pMIONOPOUNm/2iRvfYe2wD13KUlBKrqichcsf6lZ9zE7Ro3 BJ8Ec6+OfT7WBms6wajKwH0+dSDHZ/weoNTJSUpxVioWNLdWj22q9ejtWXaLkrkwVvSL OAhCHRNr7IG5LySvTYJ7GDYfHyw6lheEFIVj2xg/P1dmLedDgmLOh413mAlwZ0GdPUuu TzjoOWwjZxHo9qoraSPMkCDFve+k9brRJnNTRwu5Am2oJ3RrKxk3IyHt0HEPxNzgzC+j u+oQ== X-Gm-Message-State: AHYfb5hi0i1qNJtRxb5zsrMxtqPV5Jk6YME5VVt/+coMJnLnybaFTuya YDxQFfQD1spN3WvduQI7XA2RJwsG6zbuUMg= X-Received: by 10.107.30.76 with SMTP id e73mr4713394ioe.158.1502976230933; Thu, 17 Aug 2017 06:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.143.80 with HTTP; Thu, 17 Aug 2017 06:23:30 -0700 (PDT) In-Reply-To: References: <13d52298-f357-df5e-1bce-6a83894845c5@outer-planes.net> From: Bradley Meck Date: Thu, 17 Aug 2017 08:23:30 -0500 Message-ID: To: Martin Thomson Cc: "Matthew A. Miller" , DISPATCH Content-Type: multipart/alternative; boundary="001a1141ac2e59ccc00556f2ec5f" Archived-At: Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:24:00 -0000 --001a1141ac2e59ccc00556f2ec5f Content-Type: text/plain; charset="UTF-8" Replies inline. On Thu, Aug 17, 2017 at 6:38 AM, Martin Thomson wrote: > On 17 August 2017 at 20:03, Bradley Meck wrote: > >> My initial reaction to this statement was: so why aren't we seeing a > > request for a new media type? > > > > This was discussed in a few different places, ultimately culminating in > no > > body wanting to take that route. You can read some info on that in the > link > > to the informative TC39 issue https://github.com/tc39/ecma262/issues/322. > It > > appears you might be more interested in the HTML side of things, which > would > > be that a new media type would not load with the specification they have > > already started deploying ( there was an issue about this on HTML side in > > https://github.com/whatwg/html/issues/558 ). Some discussion about a > `mode` > > parameter instead of media type is in an issue on this proposal > > https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That > might be > > the better route since it will work in web browsers. > > I'm not questioning the decision (though I appreciate the pointers, > thanks), just pointing out that there is an obvious question arising > from your introductory text. You don't need to defend the decision, > but you should answer that question by mentioning that link metadata > (type=module) ensures that no one else asks the question. > Certainly, I can do that in the next version. > > The discussion (and outcome if I'm reading correctly) on #1 leading to > mode= certainly seems sensible. Please pick a default of mode=script > and save us all headaches. > If and when we agree on this parameter, I think a default of mode=script without usage restriction for .js is a good idea. A similar usage restriction and default of mode=module on .mjs also seems reasonable. > Question, mainly for my gratification: if I include a module in a > , how do I signal that it's a module? You can't use > a type= attribute there, because that key is taken for something else > (media type). I know that browsers like doing things like pre-parsing > in addition to preloading. > Interestingly code can be loaded as both Script and Module due to the ambiguities in place in the grammars and HTML reusing the same MIME type. This makes it difficult to know ahead of time which grammar is being used. Pre-parsing work on top level parsing for non-ambiguous sources has been talked about a few times, but I don't know if they are implemented. A good example of this ambiguity is having a file only containing: ``` // example console.log(this) // window in Script, undefined in Module ``` You can see this in practice by loading it in both grammars with 2 different script tags: ``` ``` I have to assume that you just use native es6 modules keywords rather > than importScript in workers, so you don't need explicit > identification there. There are 2 mechanisms for dealing with Modules that can be used here. 1. The `import(...)` meta function of ECMAScript ( https://github.com/tc39/proposal-dynamic-import ) will be available in both grammars. Browsers intend to treat any javascript using import mechanisms as a Module. This meta function is not currently landed in the specification, but is in the process of doing so pending implementation and deployment. Once it becomes available a worker can use `importScripts()` to load something like the following: ``` // this file is to be loaded via importScripts, it is using the Script grammar // the following both are loaded as modules, and are loaded in parallel import('./taskA'); import('./taskB'); ``` 2. You can declare the type of a Worker using a configuration option. See https://html.spec.whatwg.org/multipage/workers.html#workertype for more details. > >> Nit: There Are So Many Proper Nouns In This Document. Is that really > >> necessary? > > > > I think this is in part a stylistic thing of my writing. I tend to avoid > > pronouns and am capitalizing grammar productions in the same manner as > the > > ECMAScript specification. We could make stylistic changes though! > > Consistency good >> Too Many Capitals Are Bad > > (In other words, don't change on my account.) > --001a1141ac2e59ccc00556f2ec5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Repl= ies inline.

On Thu, Aug 17, 2017 at 6:38 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
On 17 August 2017 at 20:03, Bradley Mec= k <bradley.meck@gmail.com&= gt; wrote:
>> My initial reaction to this statement was: so why aren't we se= eing a
> request for a new media type?
>
> This was discussed in a few different places, ultimately culminating i= n no
> body wanting to take that route. You can read some info on that in the= link
> to the informative TC39 issue https://github.com/tc39= /ecma262/issues/322. It
> appears you might be more interested in the HTML side of things, which= would
> be that a new media type would not load with the specification they ha= ve
> already started deploying ( there was an issue about this on HTML side= in
> https://github.com/whatwg/html/issues/558 ). = Some discussion about a `mode`
> parameter instead of media type is in an issue on this proposal
> https://github.com/bmeck/I-D/i= ssues/1#issuecomment-322545837 . That might be
> the better route since it will work in web browsers.

I'm not questioning the decision (though I appreciate the pointe= rs,
thanks), just pointing out that there is an obvious question arising
from your introductory text.=C2=A0 You don't need to defend the decisio= n,
but you should answer that question by mentioning that link metadata
(type=3Dmodule) ensures that no one else asks the question.

Certainly, I can do that in the next version.
=C2=A0

The discussion (and outcome if I'm reading correctly) on #1 leading to<= br> mode=3D certainly seems sensible.=C2=A0 Please pick a default of mode=3Dscr= ipt
and save us all headaches.

If and when = we agree on this parameter, I think a default of mode=3Dscript without usag= e restriction for .js is a good idea. A similar usage restriction and defau= lt of mode=3Dmodule on .mjs also seems reasonable.
=C2=A0
Question, mainly for my gratification: if I include a module in a
<link rel=3Dpreload>, how do I signal that it's a module?=C2=A0 Y= ou can't use
a type=3D attribute there, because that key is taken for something else
(media type).=C2=A0 I know that browsers like doing things like pre-parsing=
in addition to preloading.

Interestingl= y code can be loaded as both Script and Module due to the ambiguities in pl= ace in the grammars and HTML reusing the same MIME type. This makes it diff= icult to know ahead of time which grammar is being used. Pre-parsing work o= n top level parsing for non-ambiguous sources has been talked about a few t= imes, but I don't know if they are implemented.

A good example of this ambiguity is having a file only containing:
<= div>
```
// example
console.log(this) // = window in Script, undefined in Module
```

You can see this in practice by loading it in both grammars with 2 differ= ent script tags:

```
<script type=3D"= module" src=3D"./example"></script>
<script src=3D"./example"><= ;/script>
```

I have to assume that you just use native es6 modules keywords rather
than importScript in workers, so you don't need explicit
identification there.

There are 2 mechanism= s for dealing with Modules that can be used here.

= 1. The `import(...)` meta function of ECMAScript ( https://github.com/tc39/proposal-dynami= c-import ) will be available in both grammars. Browsers intend to treat= any javascript using import mechanisms as a Module. This meta function is = not currently landed in the specification, but is in the process of doing s= o pending implementation and deployment. Once it becomes available a worker= can use `importScripts()` to load something like the following:
=
```
// this file is to be loaded via importScripts= , it is using the Script grammar

// the following = both are loaded as modules, and are loaded in parallel
import(= 9;./taskA');
import('./taskB');
```

2. You can declare the type of a Worker using a configura= tion option. See https://html.spec.whatwg.org/multipage/workers.html#worker= type for more details.


>> Nit: There Are So Many Proper Nouns In This Document.=C2=A0 Is tha= t really
>> necessary?
>
> I think this is in part a stylistic thing of my writing. I tend to avo= id
> pronouns and am capitalizing grammar productions in the same manner as= the
> ECMAScript specification. We could make stylistic changes though!

Consistency good >> Too Many Capitals Are Bad

(In other words, don't change on my account.)

--001a1141ac2e59ccc00556f2ec5f-- From nobody Mon Aug 21 02:33:40 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915FB13236D; Mon, 21 Aug 2017 02:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5nRdFm6Szmf; Mon, 21 Aug 2017 02:33:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E70713219B; Mon, 21 Aug 2017 02:33:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 84CF220D11; Mon, 21 Aug 2017 05:33:30 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Mon, 21 Aug 2017 05:33:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ex35w4dMveCVbn8PSe9MH/H/P45oM t/ekit2eY3RVWI=; b=nvNYfnpfV8DqblcIC5R0HmckWg6hSbRh/0/7OxHXl4XDJ 8ouJjoZuDCJQ04sInRqG+LkKHfZ5ZypWLuYX1RPbVsb42mzB0i6dtlIWAE5IYv9k XoOp4Hjz4l59QU9Vhdw2CTxfTLH72qU3Jl+Tf5C63c8pifwhKojYVDL2AYW56iJ4 V97/TESe8isPd0w9bYyBWALZdE8VoU2wkRGwvK8ovIL8gMSizKtgprJtF7v0UEzh xkCAoiPBcrE1LteuEpp03Tulj8/8zvfWBnJ7YCUsv6dBWChu1dwMw9Yddg3SqwZu b+RA4wyTEWsivx7TjxwdPZi9t2jeLxlReiHAGtmjg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6B539956F6; Mon, 21 Aug 2017 05:33:30 -0400 (EDT) Message-Id: <1503308010.2063518.1079799216.5578F6F7@webmail.messagingengine.com> From: Robert Stepanek To: dispatch@ietf.org, calsify@ietf.org Cc: Bron Gondwana , Neil Jenkins MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Mon, 21 Aug 2017 11:33:30 +0200 Archived-At: Subject: [dispatch] RFC draft for JSCalendar, an alternative to iCalendar X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 09:33:32 -0000 Hi, A couple of days ago we uploaded a draft for a new JSON-based representation of calendar data: https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/ The draft is the result of extensive discussions within the CalConnect calendaring consortium, and we already know of at least two implementations of the current spec (one at FastMail). My IETF contact Alexey Melnikov advised me to ask for your review and feedback on the spec and where to dispatch it for future discussion. I'll be happy to answer any questions around the spec. Thanks in advance, Cheers, Robert From nobody Mon Aug 21 11:21:59 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7774132A82 for ; Mon, 21 Aug 2017 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CE4X6xELcIZE for ; Mon, 21 Aug 2017 11:21:56 -0700 (PDT) Received: from smtp80.ord1c.emailsrvr.com (smtp80.ord1c.emailsrvr.com [108.166.43.80]) (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 25AFE1323C9 for ; Mon, 21 Aug 2017 11:21:56 -0700 (PDT) Received: from smtp27.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 766D6401EF for ; Mon, 21 Aug 2017 14:21:53 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp27.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9B08B401AE for ; Mon, 21 Aug 2017 14:21:52 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.85.165.253] ([UNAVAILABLE]. [173.38.117.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 21 Aug 2017 14:21:53 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_2C9C8835-1387-46A7-AF01-8FDD2B04D2C0" Message-Id: <4DC6097A-155C-4EC4-81F4-96333DCC7AB7@iii.ca> Date: Mon, 21 Aug 2017 11:21:47 -0700 To: DISPATCH Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] Adoption of Work on ECMAScript Media Types Updates? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:21:58 -0000 --Apple-Mail=_2C9C8835-1387-46A7-AF01-8FDD2B04D2C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If anyone has significant objections to the WG adopting=20 https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs = as a working document, please let us know by end of the day Sept 4.=20 After that we will work with ADs to determine next steps.=20 Thanks,=20 Cullen --Apple-Mail=_2C9C8835-1387-46A7-AF01-8FDD2B04D2C0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

If anyone has significant objections to the WG adopting 


as a working document, please let us know by end of the day Sept 4. 

After that we will work with ADs to determine next steps. 

Thanks, 

Cullen <co-chair>


--Apple-Mail=_2C9C8835-1387-46A7-AF01-8FDD2B04D2C0-- From nobody Sun Aug 27 09:20:11 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5631132328; Sun, 27 Aug 2017 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcanedomain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qxFBHp-ancB; Sun, 27 Aug 2017 09:19:55 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0E6132937; Sun, 27 Aug 2017 09:19:55 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 7F39D5BE066; Sun, 27 Aug 2017 09:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=pBQ8KrWc2ojEU5PxHVVS3crnsf8=; b=IFCtJvRN5S3 ifFM6+dhnuDm1BYwhGQFbx1YhQtaB2F9F4OkgotFcH6Oc0Bqb7G0uwFTM6WEhcFM 1gGxMdveEfT1a+PAa6CIM361QTwZoXAlBlQ7cRJSXOLfDoXCLz1nNCujCnsHUnsC ZyhMX+TWV6MeT2SyNUleIMKpwtt7rtKk= Received: from [192.168.1.101] (216-15-112-214.s4564.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com [216.15.112.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 046995BE064; Sun, 27 Aug 2017 09:19:53 -0700 (PDT) To: David Booth Cc: "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> From: Noah Mendelsohn Message-ID: <700104d3-4be3-56d9-31c4-8252315a2c2e@arcanedomain.com> Date: Sun, 27 Aug 2017 12:19:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] [art] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 16:19:57 -0000 On 8/3/2017 6:21 PM, David Booth wrote: > It sounds to me like the history that you just explained in email would be > a perfect addition to those draft documents, as an editor note, so that > people who find them can more easily understand their context. Maybe. What I wrote in the email is just my recollection of what happened more than ten years ago; I'm not 100% sure other TAG members would have seen it the same way at the time or would recall it the same way now. Perhaps it would be better to record a briefer note that there was some history of difficulty in reaching consensus on the connection between URI schemes and protocols, perhaps with a link to my email as background reading? In any case, I have no strong feelings about what should be done now. Noah