Subject: [Doh] URI Template

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Aug 2018 08:28:22 +0200 (CEST)

Hey,

I've written three separate client-side DoH implementations by now and I'm 
mentoring a 4th. I don't get the use of URI Template in the spec.

A template is meant to be used to describe how the URI can be made up and the 
DoH spec mandates the name 'dns' to be used for the DNS packet parameter when 
GET is used. There's no other URL parameters.

Can a service then offer any other template than with a trailing '{?dns}' ? 
Like 'https://example.org/path{?dns}'.

If it can provide other parts in the {} section, what is a generic client 
supposed to do with those?

I'm probably just stupid.

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Aug 2018 22:58:36 +1000

A template can have many slots with different variables.  An
application might know how to fill only some of them.  An application
that doesn't know how to fill a given slot leaves it empty.  Now, that
might mean that the request ends up going nowhere useful, but that's
just how it goes.

For instance, DoH only defines what "dns" means, so you would take
"https://example.org{?dns}{?x}" and just do
"https://example.org?dns=<blah>".  Of course, an extension to DoH
might define "x", and those clients that understand that extension
could use that template with the extension.
On Fri, Aug 31, 2018 at 4:28 PM Daniel Stenberg <[email-masked]> wrote:
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Aug 2018 15:23:07 +0200 (CEST)

> could use that template with the extension.

Ok I understand. If we in the future also adds 'x' as a variable that can be 
used in DoH, a future template could look like "https://example.org{?dns}{?x}" 
so if we want the current template parser to be future-proof it needs to 
accept them all...

Thanks!

-- 

  / daniel.haxx.se

---

From: Star Brilliant <[email-masked]>
Date: Fri, 31 Aug 2018 19:10:16 +0000

> so if we want the current template parser to be future-proof it needs to

Hi,

By the way, I remember we once had a "ct" parameter to specify the Content-Type, in case we will define another one in the future.

But I can not find any information about "ct" in the latest draft. Is it removed?
What should we do if we want another Content-Type in the future? (e.g. text-based, JSON-based, or session-based XFR)

Best regards,
StarBrilliant

---

From: Patrick McManus <[email-masked]>
Date: Fri, 31 Aug 2018 15:16:23 -0400

4.1:

  Future specifications for new media types for DoH MUST define the
   variables used for URI Template processing with this protocol.

On Fri, Aug 31, 2018 at 3:10 PM, Star Brilliant <[email-masked]> wrote:

> By the way, I remember we once had a "ct" parameter to specify the
> Content-Type, in case we will define another one in the future.
>
> What should we do if we want another Content-Type in the future? (e.g.
> text-based, JSON-based, or session-based XFR)
>
>
> Best regards,
> StarBrilliant