[Doh] Proposal to close off these threads

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

Return-Path: <paul.hoffman@icann.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8D130DDB for <doh@ietfa.amsl.com>; Sat, 9 Jun 2018 17:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JVfUhKs7YV7V for <doh@ietfa.amsl.com>; Sat, 9 Jun 2018 17:29:24 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47529130DD2 for <doh@ietf.org>; Sat, 9 Jun 2018 17:29:24 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-1.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 9 Jun 2018 17:29:22 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Sat, 9 Jun 2018 17:29:22 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: DoH WG <doh@ietf.org>
Thread-Topic: Proposal to close off these threads
Thread-Index: AQHUAFITEsaYwCV0QEGG1e9nonKrxw==
Date: Sun, 10 Jun 2018 00:29:20 +0000
Message-ID: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <143A53130066014693DE7B19AB41AF42@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/L9CdEkCacNsmbqZ_HK8OFf5JglU>
Subject: [Doh] 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 00:29:26 -0000

Greetings. Yeah, this one is difficult. Well-intentioned folks with decades of experience disagree, and yet we need to move forward. It would be good to do so using definitive language that does not presuppose particular understanding of the DNS protocols. The best way to do this is to make changes to the specific media type defined in this document, not to the entire protocol. (We were sometimes sloppy in the draft about differentiating the protocol from this specific media type.)


7.  Definition of the application/dns-message media type

   The data payload in this media type is the DNS on-the-wire format defined
   in [RFC1035]. The format is for DNS over UDP.  Although [RFC1035] says
   "Messages carried by UDP are restricted to 512 bytes", that was later
   updated by [RFC6891]. This media type restricts the size of the DNS
   message to 65535 bytes. Note that the wire format used in this media type
   is different than the wire format used in [RFC7858].

   DNS API clients using this media type MAY have one or more EDNS options
   [RFC6891] in the request. DNS API servers using this media type MUST ignore
   the value given for the EDNS UDP payload size in DNS requests.

   The use of the AXFR and IXFR QTYPEs with this media type is not yet

   When using the GET method, the data payload for this media type MUST be
   encoded with base64url [RFC4648] and then provided as a variable named
   "dns" to the URI Template expansion. Padding characters for base64url MUST
   NOT be included.

   When using the POST method, the data payload for this media type MUST NOT
   be encoded and is used directly as the HTTP message body.

People can later define new media types, such as to handle larger DNS messages, to handle new QTYPEs or Meta-TYPEs, and so on. People can also later update this media type to define how to use AXFR and/or IXFR in a predictable and interoperable fashion.

--Paul Hoffman