Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

Patrick McManus <pmcmanus@mozilla.com> Wed, 21 September 2016 18:41 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DB612BCAE for <dnsoverhttp@ietfa.amsl.com>; Wed, 21 Sep 2016 11:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.735
X-Spam-Level:
X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 rzuKWNHokfR8 for <dnsoverhttp@ietfa.amsl.com>; Wed, 21 Sep 2016 11:41:55 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id DEDA812BCE4 for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 11:41:54 -0700 (PDT)
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3F0FF3A01B for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 14:41:44 -0400 (EDT)
Received: by mail-it0-f51.google.com with SMTP id o3so136118884ita.1 for <dnsoverhttp@ietf.org>; Wed, 21 Sep 2016 11:41:44 -0700 (PDT)
X-Gm-Message-State: AE9vXwM+TJQO2QQA8t9RJgU3knLDh4oRrL6aoz/VnRa/Dwc1ALWsln2i3sQk4D7B0NGyAqh1iKdMzO10Re/LpQ==
X-Received: by 10.36.238.134 with SMTP id b128mr6263156iti.72.1474483303792; Wed, 21 Sep 2016 11:41:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.148.50 with HTTP; Wed, 21 Sep 2016 11:41:43 -0700 (PDT)
In-Reply-To: <A7C77948-ACEA-49F1-83CC-72E12B6EFA2B@icann.org>
References: <147438228195.28999.4355943522486567954.idtracker@ietfa.amsl.com> <D1E3CC44-FE5A-4ACE-90A1-EF9B5EE975D7@icann.org> <CAOdDvNpWdN=w0R7pOkghbwg0-SwHnD9=AqvpnAM7tQfmRpVGEw@mail.gmail.com> <A7C77948-ACEA-49F1-83CC-72E12B6EFA2B@icann.org>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 21 Sep 2016 20:41:43 +0200
X-Gmail-Original-Message-ID: <CAOdDvNrhA6K0exsJhqXf29X-xWE0dibOgj=2bcDfeGzxZdUahQ@mail.gmail.com>
Message-ID: <CAOdDvNrhA6K0exsJhqXf29X-xWE0dibOgj=2bcDfeGzxZdUahQ@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Content-Type: multipart/alternative; boundary="f403045c0e568cccb7053d08e55b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/KMqTB5F8z1CM4SZ9qt6sxgMHo8g>
Cc: "dnsoverhttp@ietf.org" <dnsoverhttp@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 18:41:57 -0000

On Wed, Sep 21, 2016 at 5:24 PM, Paul Hoffman <paul.hoffman@icann.org>
wrote:

>
> > * the discussion of content negotiation (aka Accept:) doesn't really add
> anything to the existing http definition - i.e. using it might help you get
> a content type you know how to decode. Perhaps having a MTI type (json?)
> gives this more pertinence and helps deployability. Might as well get the
> hard stuff on the table early :)
>
> In the DNSOP WG, there isn't agreement that JSON should even be on
> standards track; the same is true for the wireformat draft. Personally, I
> don't see a strong reason for a mandatory-to-implement response format. For
> example, when the JSON format has settled, I intend to spin a really
> similar experimental document for CBOR in case the IoT folks want one.
>
>
imo its important to remember that http content negotiation is only
advisory.. if you send Accept: foo it certainly increases your chances of
receiving foo in the response but it doesn't obligate the response to be in
foo format.. an http dns client could find the whole thing much more useful
to implement if it had knew there was a mti lcd available it could rely on
if foo wasn't available - which still means the specification can be
neutral about allowing any number of formats in addition to the mti one.
I've heard json tossed around, but I didn't mean to limit discussion to it
- I just think having an mti format is really really helpful for interop.

but maybe others don't. just thought it was worth a second try :)