Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033) Tue, 31 March 2020 09:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 806E53A1E4D for <>; Tue, 31 Mar 2020 02:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EbfnfvKnGw7M for <>; Tue, 31 Mar 2020 02:03:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0180C3A1099 for <>; Tue, 31 Mar 2020 02:03:23 -0700 (PDT)
Received: from (unknown [xx.xx.xx.7]) by (ESMTP service) with ESMTP id 48s3Jp23NSz2yfj; Tue, 31 Mar 2020 11:03:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1585645402; bh=7ulSg+V16pGGRMMrrjUlQraujsco+WT/22noTb0Ze2I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gyR4jHep/8l5kas8/pcu/Qyi69qMB9FUia+wro9M3qkLsNKjJhwxYwNxm+plJlJJC BbrqJVOmLQf+4y6uPzZjGPUBfjD37oL4JaR1B0rA2gCIvNnZtmX4roLcOcuAzbFfdM YI4v3hY7s34oyQSGMYGeK9gTAsRG97xd7+4kW3TGPkvO01qgJPHmWIMgRhy2nB49w/ Ey7Y524quVmhoe01h7sahr6tbgsFv+cTSAmFK9nhQ3REmLIkYAvhEUHend+SKHIdGI JyML/TzR0bexjhEr93NSFOUBvlRNhRHHws2t/fsKjCJ2XXTTdQitURM7K3SU7NKgKO dm5XN+fE8RQZA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by (ESMTP service) with ESMTP id 48s3Jp0BDVz2xCp; Tue, 31 Mar 2020 11:03:22 +0200 (CEST)
From: <>
To: Paul Hoffman <>, "" <>
CC: Barry Leiba <>, Patrick McManus <>, "Murray S. Kucherawy" <>, "Ben Schwartz" <>, David Lawrence <>, RFC Editor <>
Thread-Topic: [Ext] [Technical Errata Reported] RFC8484 (6033)
Thread-Index: AQHWBrHijv0n0q7vHE2JDapm+5eGMahhQSmAgAEiAiA=
Date: Tue, 31 Mar 2020 09:03:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031489622@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 09:03:26 -0000

Hi Paul,

Thank you for sharing your thoughts. 

I'm now more puzzled about the intent of the document with regards to redirection:

(a) The document says explicitly the following: 

   The described approach is more than a tunnel over HTTP.  It
   establishes default media formatting types for requests and responses
   but uses normal HTTP content negotiation mechanisms for selecting
   alternatives that endpoints may prefer in anticipation of serving new
   use cases.  In addition to this media type negotiation, it aligns
   itself with HTTP features such as caching, redirection, proxying,
   authentication, and compression.

Which I interpret as redirection is part of the design goals.

(b) But what I'm hearing from you is that redirection may be implicitly disallowed for some "reason". This seems like an internal inconsistency of the document that is worth to be fixed. 

Can you please clarify the following:

* Is redirection allowed or not?  
* How a different URI can be discovered using server push? 

   A DoH client MUST NOT use a different URI simply because it was
   discovered outside of the client's configuration (such as through
   HTTP/2 server push)

Thank you. 


> -----Message d'origine-----
> De : Paul Hoffman []
> Envoyé : lundi 30 mars 2020 19:24
> À :
> Cc : Barry Leiba; BOUCADAIR Mohamed TGI/OLN; Patrick McManus; Murray
> S. Kucherawy; Ben Schwartz; David Lawrence; RFC Editor
> Objet : Re: [Ext] [Technical Errata Reported] RFC8484 (6033)
> On Mon, Mar 30, 2020 at 12:32 PM Barry Leiba <>
> wrote:
> >
> > The proposed change substantively changes the text and cannot be
> > approved through an errata report.
> I agree with Barry, even though I believe that what Mohamed is asking
> for could have been what the WG or the IETF wanted, had they seen this
> proposed change while the document was being developed. For example,
> when I read the proposed change, I thought "of course he's right about
> HTTP redirection"; however, I don't know if other people who are more
> literate about HTTP would agree.
> > My inclination is "Rejected", as I
> > do believe the text says what it's intended to say (so it's not an
> > erratum), but I could be convinced that "held for document update"
> is
> > better if the document editors weigh in.
> "held for document update" normally indicates that the erratum is
> believed to be valid. We don't know that without going through WG Last
> Call and IETF Last Call again. Given how heavily this document was
> discussed before publication, I do not think it is appropriate to
> change it with an erratum.
> I have not heard of any developer misunderstanding the current words
> in a way that would be fixed by this rewording. Further, the bit about
> HTTP redirection is a technical change (possibly an oversight, or
> possibly it was left out on purpose by those who understand it
> better).
> --Paul Hoffman