Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)

[[e-mail]]

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. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Hoffman [mailto:[e-mail]]
> Envoyé : lundi 30 mars 2020 19:24
> À : [e-mail]
> 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 <[e-mail]>
> 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