Re: [Doh] [Ext] Proposal to close off these threads

Paul Hoffman <paul.hoffman@icann.org> Sun, 10 June 2018 23:53 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE13130F29 for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:53:18 -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 Hlv02hPd04cg for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:53:17 -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 4E06D130DCC for <doh@ietf.org>; Sun, 10 Jun 2018 16:53:17 -0700 (PDT)
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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 10 Jun 2018 16:53:15 -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.1367.000; Sun, 10 Jun 2018 16:53:15 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Patrick McManus <pmcmanus@mozilla.com>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [Ext] [Doh] Proposal to close off these threads
Thread-Index: AQHUARYytWA6Pi1qTE+ZJhzr/XL78A==
Date: Sun, 10 Jun 2018 23:53:15 +0000
Message-ID: <FB8DBC78-4584-4133-AF1F-E0483C28224D@icann.org>
References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> <CAOdDvNrXpyGTFmMHcF6Vnegku0Zmiw_LFb1VKm1O2mFgB3aHEw@mail.gmail.com>
In-Reply-To: <CAOdDvNrXpyGTFmMHcF6Vnegku0Zmiw_LFb1VKm1O2mFgB3aHEw@mail.gmail.com>
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: <4ECB212E740C05468861E6B215F917EA@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/sMY6MPpIsGZaBHqmEFU3a1BYlpw>
Subject: Re: [Doh] [Ext] Proposal to close off these threads
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2018 23:53:19 -0000

On Jun 10, 2018, at 4:31 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> I think we can make progress here. I'm pleased to see the text restricted to the media type. I don't think it should explicitly restrict axfr, but rather be about size.
> 
> This both makes the reasoning clearer and hits the target more accurately in edge cases (doesn't apply to small axfr and does apply to a huge rr set of key types and txt records or something). I'm happy if we also mention many [ai]xfr require more than one traditional wireformat message and so won't fit in this media type.

I would rather not mention stuff we can't back up. If a developer wants to do ?XFR over this transport and have others interoperate with them, it will probably take much less time for them to write the (hopefully very short) Internet Draft than it will for them to eventually have to debug and patch their code when someone else makes different assumptions.

> Its good to note, non-normatively, that a server that cannot satisfy a request because of this media type's size restriction can use 413 to signal that.

"can use"? "SHOULD use" except in situation X? "MUST use"?

--Paul Hoffman

(PS: The above proves that the document authors are not carefully coordinating their responses off-list...)