We did not use get because get does not have a request payload.
On March 1, 2016 6:44:16 PM PST, Davey Song <songlinj...@gmail.com> wrote:
>On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman <paul.hoff...@vpnc.org>
>wrote:
>
>> This document is a good idea, but it has some faults that need to be
>fixed
>> before it goes forwards.
>>
>> - In the Introduction, it says in essence that this is just using
>HTTP to
>> tunnel DNS and is not of use to web browsers. This is wrong, I
>believe.
>> JavaScript in browsers cannot create port 53 queries, but they can
>create
>> arbitrary HTTP/HTTPS queries. This protocol would allow JavaScript
>apps to
>> get DNS responses as long as they could cobble together the request
>bytes
>> and interpret the response. It would be ugly, yes, but so is a lot of
>stuff
>> I see in JavaScript these days.
>>
>> If it is feasible (or there is an technical requirement) that
>JavaScript
>can handle wire-format DNS massage over HTTP, it is no reason to
>exclude
>it. So the simple way to edit this is to get rid of such saying of
>denying
>web browser user.
>
>
>> - Using POST for queries goes against the design of HTTP. POST is for
>> requests that change state on the server, and DNS queries are not
>that.
>> This protocol should use GET.
>>
>Fair enough.
>
>>
>> - The lack of a common URI template will completely prevent
>> interoperability. You should instead use .well-known prefix for
>getting the
>> syntax as described in RFC 5785.
>>
>I agree we should end up with a fixed URI template which can be
>recognized
>by both client and server. Particularly in Proxy mode, the server proxy
>will leverage the 80/443 port with existing Web server, we should avoid
>conflicts with existing web service URIs.
>
>- Section 3.3 is completely unclear. Either prohibit the two-byte
>length
>> added for TCP queries, or require them all the time. Making them
>optional
>> will make interoperability difficult or impossible.
>>
>
>What we say in Section 3.3 is not including the two-byte field in the
>message sent to the server. Is the text not clear ? I will try to make
>it
>more clear
>
>>
>> - Having no security considerations for a protocol that has optional
>HTTPS
>> seems like a big oversight.
>>
>Yes. I admit it is a big oversight here. I will discuss with
>co-authors.
>Any suggestions ?
>
>>
>> Hope this helps!
>>
>> Thank you ! The original idea is to document how we implement the
>software and try to share the communication pattern with other
>developers.
>Now we should follow IETF way to formalized the document : )
>
>Davey
>
>> --Paul Hoffman
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
