Subject: [weirds] What templates and well-known would look like

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Nov 2013 18:26:54 -0800

We talked today about using well-known URI space, and optionally templates
as well.  Here's my understanding of what they'd look like:

For well-known, we would apply the procedure found in RFC5785 and register
"rdap" with IANA.  This means we effectively claim
http://<server>/.well-known/rdap
as our own URI space, and would be free to define URI structure under
there.  This would basically add an IANA action to our query draft, and our
URIs would now always contain ".well-known" followed by the name we
register before the structure we define.

For templates, we would do the above, and then declare that what's found at
or under http://<server>/.well-known/rdap is a URI template (RFC6570).  A
template would take one or more key values, primarily the question to be
asked, and then construct a URI based on the template.  This means the
service is free to define any query syntax it wants to establish for its
service.  For example, you might get a template that says:

http://{service}/rdap/q={query}

We would need to define all the key values are expected to appear in a
template so that the query can be expanded.  For example, we would say a
client has to have "service" and "query" available for substitution into
the template.  The result is this process, assuming you want to ask a
service called rdap.example about example.com:

1) Request http://rdap.example/.well-known/rdap, and get back a template.
(This can be cached.)  Suppose the returned template is as above.

2) Build the template using the available values, resulting in
http://rdap.example/rdap/q=example.com.

3) Issue that query.

There's an obvious added cost of doing the second round trip in the
templates method, but it can be far more flexible in terms of query syntax,
and the template itself can be cached.

An example of this second method that recently passed IESG Review and is
awaiting publication is
http://tools.ietf.org/html/draft-ietf-repute-query-http-11.  It has more
detail than I've given above.  There is at least one actual implementations
of this, so libraries and text are both available.  We could have gone the
basic ".well-known/repute" route, but I found the ".well-known" part
unsightly, which this group may or may not agree with.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 8 Nov 2013 02:34:38 +0000

The well-known URI space approach would be a simple change from what's currently in the query draft. It seems like an easier path forward.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, November 07, 2013 9:27 PM
To: [email-masked]
Subject: [weirds] What templates and well-known would look like

We talked today about using well-known URI space, and optionally templates as well.  Here's my understanding of what they'd look like:
For well-known, we would apply the procedure found in RFC5785 and register "rdap" with IANA.  This means we effectively claim http://<server>/.well-known/rdap<http://%3cserver%3e/.well-known/rdap> as our own URI space, and would be free to define URI structure under there.  This would basically add an IANA action to our query draft, and our URIs would now always contain ".well-known" followed by the name we register before the structure we define.
For templates, we would do the above, and then declare that what's found at or under http://<server>/.well-known/rdap<http://%3cserver%3e/.well-known/rdap> is a URI template (RFC6570).  A template would take one or more key values, primarily the question to be asked, and then construct a URI based on the template.  This means the service is free to define any query syntax it wants to establish for its service.  For example, you might get a template that says:
http://{service}/rdap/q={query}<http://%7bservice%7d/rdap/q=%7bquery%7d>
We would need to define all the key values are expected to appear in a template so that the query can be expanded.  For example, we would say a client has to have "service" and "query" available for substitution into the template.  The result is this process, assuming you want to ask a service called rdap.example about example.com<http://example.com>:
1) Request http://rdap.example/.well-known/rdap, and get back a template.  (This can be cached.)  Suppose the returned template is as above.
2) Build the template using the available values, resulting in http://rdap.example/rdap/q=example.com.
3) Issue that query.
There's an obvious added cost of doing the second round trip in the templates method, but it can be far more flexible in terms of query syntax, and the template itself can be cached.
An example of this second method that recently passed IESG Review and is awaiting publication is http://tools.ietf.org/html/draft-ietf-repute-query-http-11.  It has more detail than I've given above.  There is at least one actual implementations of this, so libraries and text are both available.  We could have gone the basic ".well-known/repute" route, but I found the ".well-known" part unsightly, which this group may or may not agree with.
-MSK

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 08 Nov 2013 00:39:20 -0200

+1

On 11/8/13, 12:34 AM, Hollenbeck, Scott wrote:
> The well-known URI space approach would be a simple change from what’s
> currently in the query draft. It seems like an easier path forward.
> 
>  
> 
> Scott
> 
>  
> 
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Murray S. Kucherawy
> *Sent:* Thursday, November 07, 2013 9:27 PM
> *To:* [email-masked]
> *Subject:* [weirds] What templates and well-known would look like
> 
>  
> 
> We talked today about using well-known URI space, and optionally
> templates as well.  Here's my understanding of what they'd look like:
> 
> For well-known, we would apply the procedure found in RFC5785 and
> register "rdap" with IANA.  This means we effectively claim
> http://<server>/.well-known/rdap <http://%3cserver%3e/.well-known/rdap>
> there.  This would basically add an IANA action to our query draft, and
> our URIs would now always contain ".well-known" followed by the name we
> For templates, we would do the above, and then declare that what's found
> at or under http://<server>/.well-known/rdap
> <http://%3cserver%3e/.well-known/rdap> is a URI template (RFC6570).  A
> http://{service}/rdap/q={query} <http://%7bservice%7d/rdap/q=%7bquery%7d>
> 
> service called rdap.example about example.com <http://example.com>:
> 
> 1) Request http://rdap.example/.well-known/rdap, and get back a
> template.  (This can be cached.)  Suppose the returned template is as above.
> 
> templates method, but it can be far more flexible in terms of query
> syntax, and the template itself can be cached.
> 
> detail than I've given above.  There is at least one actual
> implementations of this, so libraries and text are both available.  We
> could have gone the basic ".well-known/repute" route, but I found the
> ".well-known" part unsightly, which this group may or may not agree with.
> 
> -MSK
> 
> 
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 11 Nov 2013 15:22:57 -0500

The main intent of RFC 5785 and 
draft-ietf-appsawg-uri-get-off-my-lawn-00 seems to be registration of 
HTTP path prefixes "to avoid collisions and minimise impingement upon 
sites URI space."

I don't see how this applies to the current definition in rdap-query-07, 
which clearly says, "uniform patterns start with a base URL [RFC3986] 
specified by each registry or any other service provider". The rest of 
the paths defined, such as domain/<domain name>, follow the base path.

This may change, if we decide to support a bootstrap based on DNS. Since 
DNS as proposed will only provide an IP address, a base path will be 
needed. In that case RFC 5785 would apply.

However, if an IANA based bootstrap is decided, then part of the IANA 
record would be the base URL, as defined by the service provider. In my 
view this is preferable as it gives more control to the owner of the 
service. So this is an advantage of an IANA bootstrap over DNS.

In any case, it seems like the bootstrap decision should be made before 
putting effort into defining ".well-known".

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 11 Nov 2013 15:29:01 -0500

Le 2013-11-11 à 15:22, Ernie Dainow <[email-masked]> a écrit :

> The main intent of RFC 5785 and draft-ietf-appsawg-uri-get-off-my-lawn-00 seems to be registration of HTTP path prefixes "to avoid collisions and minimise impingement upon sites URI space."
> 
> I don't see how this applies to the current definition in rdap-query-07, which clearly says, "uniform patterns start with a base URL [RFC3986] specified by each registry or any other service provider". The rest of the paths defined, such as domain/<domain name>, follow the base path.
> 
> This may change, if we decide to support a bootstrap based on DNS. Since DNS as proposed will only provide an IP address, a base path will be needed. In that case RFC 5785 would apply.

right, unless the RR used is NAPTR, which then works for any url for any registry.  But NAPTR is a complex RR and much less implemented, especially in client side.

> 
> However, if an IANA based bootstrap is decided, then part of the IANA record would be the base URL, as defined by the service provider. In my view this is preferable as it gives more control to the owner of the service. So this is an advantage of an IANA bootstrap over DNS.
> 
> In any case, it seems like the bootstrap decision should be made before putting effort into defining ".well-known".

I agree. We shall think about the overall solution and all pieces of puzzle are interconnected.

Marc.

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2013 21:54:59 -0000

>putting effort into defining ".well-known".

For once, I completely agree with Ernie.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Nov 2013 19:32:35 +0000

The audio of the Vancouver meeting can be found here:
https://www.ietf.org/audio/ietf88/ietf88-plazac-20131107-1300-pm3.mp3
Around 2:20 is where the discussion on .well-known takes place.

One thing I'll note is that during that discussion Barry and MarK were
told that bootstrapping would reveal a hostname. That's really only true
of CNAME and SRV bootstrapping, not for the IANA registries or NAPTR (or
URI RR) methods. In these other methods, a URL could be returned and I
believe that might be acceptable based on the conversation.

Also, I can think of a perfectly reasonable scenario where .well-known
breaks. Let's say I want to run an authentication server my federation of
registries in addition to my own registry. To run them on the same host
would require two different .well-known sub-divisions and would require
the client to know the difference between the two types of servers and
thus breaks simple HTTP redirection.

If I understand the desire for .well-known, it is similar to TCP port
numbers where to get a "well-known" path prefix you have to go through
standards action. However, we aren't asking for a well-known path prefix
with the current verbiage of the rdap-query draft.

-andy

On 11/11/13 3:22 PM, "Ernie Dainow" <[email-masked]> wrote:

>>> The well-known URI space approach would be a simple change from what¹s
>>><http://%7bservice%7d/rdap/q=%7bquery%7d>
>>>

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Nov 2013 19:36:00 +0000

On 11/11/13 3:29 PM, "Marc Blanchet" <[email-masked]> wrote:

>right, unless the RR used is NAPTR, which then works for any url for any
>registry.  But NAPTR is a complex RR and much less implemented,
>especially in client side.

Or use the URI RR.
http://www.iana.org/assignments/dns-parameters/URI/uri-completed-template

See http://tools.ietf.org/html/draft-faltstrom-uri-05
Note one of the co-authors. :)

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Nov 2013 14:40:58 -0500

>> especially in client side.

which is even less implemented and still an internet draft.

Marc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Nov 2013 14:45:18 -0500

> which is even less implemented and still an internet draft.

Yes, and one of the authors has repudiated it as a bad idea, so he
won't take the draft to publication.  That's why it's expired.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Nov 2013 20:24:55 +0000

>> which is even less implemented and still an internet draft.

My understanding of the issues behind NAPTR isn't that you can't find name
servers that implement them but that a) many DNS proxies refuse to
accommodate them, and b) many people screw them up and don't understand
them.

>won't take the draft to publication.  That's why it's expired.

How is it a bad idea? It's a simpler version of RFC 4848.

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Nov 2013 15:36:30 -0500

> accommodate them, and b) many people screw them up and don't understand

right. that is what I summarized in the initial email: "But NAPTR is a complex RR and much less implemented"

Marc.

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 16 Nov 2013 17:43:56 -0300

> right, unless the RR used is NAPTR, which then works for any url for any registry.  But NAPTR is a complex RR and much less implemented, especially in client side.

For this use case we specified: http://tools.ietf.org/html/draft-faltstrom-uri-08 (RR type has been allocated)

As far as implementation of NAPTR and URI, the main issue is provisioning at the server side. The parent side can always deal with RFC 3597 (Unknown RR types, 2003). Or is it the case that most clients do not support Unknown RRs?

—Olaf (0.02€  and no hats)

---

From: Olaf Kolkman <[email-masked]>
Date: Sat, 16 Nov 2013 17:45:29 -0300

> Note one of the co-authors. :)

dooh… reading sequentially….

---

From: "John Levine" <[email-masked]>
Date: 17 Nov 2013 01:07:54 -0000

> As far as implementation of NAPTR and URI, the main issue is
> provisioning at the server side. The parent side can always deal with
> RFC 3597 (Unknown RR types, 2003). Or is it the case that most clients
> do not support Unknown RRs?

The specific problem is that a lot of RDAP clients are written in
Javascript, and there's no way in Javascript to make any DNS queries
other than an implicit A/AAAA for the host name in a URL.

The band-aid in a browser is to call back to whatever host provided
the Javascript and ask it to do the SRV or NAPTR or whatever.  If
you're using shell scripts and wget or curl, you're in a similar
situation, arguably worse since there's nowhere to call back to.

We discussed this at length earlier this year.  It shouldn't be hard
to find in the mail logs.

R's,
John

---

From: Olaf Kolkman <[email-masked]>
Date: Sun, 17 Nov 2013 00:30:23 -0300

> to find in the mail logs.

Thanks for remembering me of that specific argument.

It is kind of a bummer that the DNS is seen as an name to address instead of a name to resource mapping system, but it isn’t our place to solve that here.

—Olaf

(still, no hats)