Subject: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Feb 2014 18:03:35 +1100

I've been in an on-again, off-again discussion with some of the WEIRDS folks about their work and its relationship to <http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn>.

That seemed to precipitate <http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-00>, which describes a way to "bootstrap" a WEIRDS interaction, and I've been asked for feedback.

Reading through it, I have some issues, but I since uri-get-off-my-lawn is a product of this WG, not just my draft, I'd rather get a sense of what the WG thinks overall, rather than just giving my own feedback.

AIUI, the bootstrap draft uses a number of IANA registries to contain a mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to URLs for their RDAP services. 

Those URLs are then used as base URIs for further interactions; for example, if example.com had a registry value of "http://example.com/lookup", you'd look up "foo.example.com" as "http://example.com/lookup/domain/foo.example.com".

To me, this seems better than the previous solution (where you assumed that example.com had something available at a certain path), but it still "bakes" URLs into the spec, relative to that base URI. I.e., the "/domain/whatever" bit above is locked into the spec and unchangeable, AIUI.

So, while they avoid collisions (probably), they still risk the other problems that the "get off my lawn" draft cautions against, AFAICT.

If I were doing this protocol and I still wanted to use a registry (questionable IMHO), I'd allow each entry to contain a set of URL templates, identified by link relations, that allows a one-step lookup without baking in any URLs. 

E.g., 

domain: example.com
    rel: domainlookup    href-template: http://example.com/lookup/{domain}

I'm very curious to hear what other APPS folks think about this -- especially those of a Web bent. We're trying to line up some conversations about this in London, and I'd like to inform them with the WG's perspective, rather than just my own.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Mon, 10 Feb 2014 23:28:04 -0800

If I reviewed it I’d identify that as a major issue and scream loudly. It
would be helpful if we had an RFC to lean on saying “don’t do that”.  So,
if my site requirements mean that my service needs to be at “
https://example.com?service=weirds that /lookup/whatever is not going to
sit happily on the end of it.

On Mon, Feb 10, 2014 at 11:03 PM, Mark Nottingham <[email-masked]> wrote:

> I've been in an on-again, off-again discussion with some of the WEIRDS
> folks about their work and its relationship to <
> http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn>.
>
> That seemed to precipitate <
> http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-00>, which
> describes a way to "bootstrap" a WEIRDS interaction, and I've been asked
> for feedback.
>
> Reading through it, I have some issues, but I since uri-get-off-my-lawn is
> a product of this WG, not just my draft, I'd rather get a sense of what the
> WG thinks overall, rather than just giving my own feedback.
>
> AIUI, the bootstrap draft uses a number of IANA registries to contain a
> mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to URLs
> for their RDAP services.
>
> Those URLs are then used as base URIs for further interactions; for
> example, if example.com had a registry value of "http://example.com/lookup",
> you'd look up "foo.example.com" as "
> http://example.com/lookup/domain/foo.example.com".
>
> To me, this seems better than the previous solution (where you assumed
> that example.com had something available at a certain path), but it still
> "bakes" URLs into the spec, relative to that base URI. I.e., the
> "/domain/whatever" bit above is locked into the spec and unchangeable, AIUI.
>
> So, while they avoid collisions (probably), they still risk the other
> problems that the "get off my lawn" draft cautions against, AFAICT.
>
> If I were doing this protocol and I still wanted to use a registry
> (questionable IMHO), I'd allow each entry to contain a set of URL
> templates, identified by link relations, that allows a one-step lookup
> without baking in any URLs.
>
> E.g.,
>
> domain: example.com
> I'm very curious to hear what other APPS folks think about this --
> especially those of a Web bent. We're trying to line up some conversations
> about this in London, and I'd like to inform them with the WG's
> perspective, rather than just my own.
>
> Cheers,
>
> --
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Erik Wilde <[email-masked]>
Date: Tue, 11 Feb 2014 14:39:10 +0100

hello mark.

> I'm very curious to hear what other APPS folks think about this -- especially those of a Web bent. We're trying to line up some conversations about this in London, and I'd like to inform them with…

i certainly like the idea of URI templates; they usually help to 
decrease coupling and make things clearer. but i think there still is 
some hesitation to use that particular spec. i think in part that's 
because it's not very easy to absorb when you just want to do simple 
things such as the one you're proposing. in part i think it's because 
there's an adoption problem: everybody is waiting for somebody else to 
be early adopters.

i am wondering how/where the variable {domain} would end up being 
"declared". your link hints draft and my link descriptions draft try to 
establish some way how this could be done, but afaict, currently that 
would be informal and maybe in the definition of the link relation?

[[ side note for a possible revision of RFC5988: currently, URI template 
is not even mentioned in "Web Linking", which makes sense, because it 
predates URI template. maybe a revision should change that. ]]

i only brief skimmed the draft-ietf-weirds-bootstrap draft, but it 
seemed to me that the spec really needing URI template help is 
http://tools.ietf.org/html/draft-ietf-weirds-rdap-query; section 3 has 
quite a bit of baked URI structure. so maybe getting the URI segments 
out of that draft would be the thing to look at?

------- feel free to skip, just a side note after skimming the draft:

on an unrelated angle, i am wondering about this part of the draft (the 
one you linked to):

"IANA should make sure that the service of those registries is able to 
cope with a larger demand and should take appropriate measures such as 
caching and load balancing."

afaict, most IANA registries are not really intended for runtime access. 
as is well-known (such as with W3C's HTML DTD URIs), even when a spec 
says that clients shouldn't blindly re-fetch every single time, there 
may be enough doing it anyway to have serious consequences. anyway, 
that's not the question you were asking, but was a rather curious part 
of that particular draft.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 11 Feb 2014 08:58:37 -0500

Le 2014-02-11 à 08:39, Erik Wilde <[email-masked]> a écrit :

> on an unrelated angle, i am wondering about this part of the draft (the one you linked to):
> 
> "IANA should make sure that the service of those registries is able to cope with a larger demand and should take appropriate measures such as caching and load balancing."
> 
> afaict, most IANA registries are not really intended for runtime access. as is well-known (such as with W3C's HTML DTD URIs), even when a spec says that clients shouldn't blindly re-fetch every single time, there may be enough doing it anyway to have serious consequences. anyway, that's not the question you were asking, but was a rather curious part of that particular draft.

- This has been discussed with IANA and they already have this capability: they just need to initiate it for that registry. However, it is not appropriate to discuss the details in this document, therefore the wording is <voluntarily> vague.
- moreover, a new rev of the document due this week (local copy already have text) will contain text about how the implementations should behave. (and at the same time, the backend, as stated above, being able to cope with bad implementations).

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 11 Feb 2014 09:09:42 -0500

Le 2014-02-11 à 02:03, Mark Nottingham <[email-masked]> a écrit :

> That seemed to precipitate <http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-00>,

no. it did not precipitate. this bootstrap discussion has been on going for quite some time and in parallel of the URI discussion.

> which describes a way to "bootstrap" a WEIRDS interaction, and I've been asked for feedback.
> 
> To me, this seems better than the previous solution (where you assumed that example.com had something available at a certain path),

actually, the previous solution was not addressing the bootstrap problem.

> but it still "bakes" URLs into the spec, relative to that base URI. I.e., the "/domain/whatever" bit above is locked into the spec and unchangeable, AIUI.
> 

yes. that is another way. it provides an additional level of indirection to remove the url component out from the spec. but it actually overload the registry with more data than typically necessary, and pretty repetitive. i.e. most likely every registry will have rel: domainlookup  href-template: http://exampleregistry1.com/lookup/{domain}, rel: domainlookup  href-template: http://exampleregistry2.com/lookup/{domain}, rel: domainlookup  href-template: http://exampleregistry3.com/lookup/{domain}.  Given the number of TLDs and that there are about 10 objects, we are multiplying the entries by 10, becomes pretty large registry operationally to parse.

> I'm very curious to hear what other APPS folks think about this -- especially those of a Web bent. We're trying to line up some conversations about this in London, and I'd like to inform them with…

btw, "them/they", "we":  we are the same IETF people. Why are we talking the "them" and "we" perspective?

Marc.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 11 Feb 2014 11:59:24 -0500

Mark,

Thank you for looking into this and for being proactive.

With regard to your idea to use templates in the registry, it seems to
me the current specification is already doing an implicit template of
the sort http://example.com/blah/{rest-of-weirds-uri}. As one of the
participants of the WEIRDS effort, I think your idea is worth
consideration. While the group has looked at templates but not found
favor with them, I believe what you are suggesting does not have the
issue to which the group objected to previously.

As for baked URIs, there was a suggestion to use .well-known with
which the WEIRDS group is struggling (very interrelated to
bootstrapping). Would you still suggest the use of .well-known with a
registry? Is the use of .well-known not just to avoid collisions but
to also allow applications to identify URIs by application type
without the need for creating a new URI scheme?

-andy

---

From: "John Levine" <[email-masked]>
Date: 11 Feb 2014 22:32:50 -0000

>I'm very curious to hear what other APPS folks think about this

RDAP is a new design.  There are no existing RDAP servers other than a
few prototypes run by people on the WEIRDS list.  There's nothing to
be backward compatible with.  

RDAP is intended as a replacement for WHOIS, to answer the same
questions that people ask now using WHOIS, e.g. information about
domain names, IP addresses, ASNs, and a few other things.  The
questions that people ask with WHOIS haven't changed materially in 20
years, and I see no reason to expect them to change in the future.

Small RDAP servers will likely adapt the RDAP prototype being funded
by ICANN.  Large RDAP servers will be written by a handful of large
registries, all of which are represented on the WEIRDS list and can
speak for themselves, but I can't remember any of them showing notable
enthusiasm for templates.

In this particular application, I really can't see any benefit to
templates other than the ability to be gratuitously different just to
prove that you can.

R's,
John

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Feb 2014 15:43:25 +1100

> issue to which the group objected to previously.

OK. To be clear, it was just a suggestion -- there are a lot of ways to do this, but templates seemed like a way to get there without inventing too much yourself (which seems to be the point, since you're already reusing HTTP :).

> without the need for creating a new URI scheme?

It really depends on the use case, which I don't feel like I yet have enough grasp of. I don't want to position .well-known as a panacea, because it's not -- it's for very specific circumstances (basically, when you need to bootstrap from a hostname, not a URI).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Feb 2014 15:49:01 +1100

> yes. that is another way. it provides an additional level of indirection to remove the url component out from the spec. but it actually overload the registry with more data than typically necessary…

Perhaps, but it may be possible to mitigate that, depending on the particulars of how it's going to be used and deployed.

E.g., have IANA run a lookup service themselves; e.g., http://iana.org/rdap/domain/foo.com

Or, define a document format that IANA points to in the registry, and *it* points to the various endpoints. 

Also, if the data is that voluminous, it suggests that you may have a problem anyway; adding such repetitive information shouldn't affect the size of the response after gzip (which you'd want to use in any case) that much.

> btw, "them/they", "we":  we are the same IETF people. Why are we talking the "them" and "we" perspective?

Strangely, we *do* organise ourselves into groups and areas here. Or are you proposing something more radical?

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 12 Feb 2014 08:57:58 -0500

> Or, define a document format that IANA points to in the registry, and *it* points to the various endpoints. 

I would suggest that you bring these discussion points to the weirds mailing list. The topic of bootstrap with various methods have been subject to many discussions so far. Not that we thought about everything, but some of your suggestions has been already debated.  There were no perfect solution, it has been a compromise between various. 

> Also, if the data is that voluminous, it suggests that you may have a problem anyway; adding such repetitive information shouldn't affect the size of the response after gzip (which you'd want to us…

it is not the size of the response. it is the parsing. some of the use cases are clients that are doing a _lot_ of requests. Again, I think you should bring these discussion points to the weirds mailing list.  

> Strangely, we *do* organise ourselves into groups and areas here.

right. but "we" are the same people. anyway. let's not continue that thread. 

Regards, Marc.

> Or are you proposing something more radical?
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Feb 2014 12:08:43 +1100

> I would suggest that you bring these discussion points to the weirds mailing list. The topic of bootstrap with various methods have been subject to many discussions so far. Not that we thought abou…

I suspected that was the case; like I said, there are a number of ways you can do this, with tradeoffs. My main concern is that definitely bad practices are avoided, mostly because of the precedent that sets when it becomes a standard.

I'm a little reluctant to get involved too deeply in the discussions on WEIRDS, because I'm already over-committed, and I don't really have much interest in the problem domain itself -- my interest (beyond that expressed above) is validating what's in the get-off-my-lawn draft (which is why I started the thread).

I've been talking to a few people about getting some folks together to talk about this over coffee / beer / cookies / whatever in London; to me, that's better than bringing it up in the WG, which will probably waste a fair amount of time (since it may very well be ground that you've already been over).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Feb 2014 12:34:50 +1100

It's this attitude that I (and apparently other Web folks here) find disturbing -- to paraphrase, "we're building a new protocol, so we don't have to worry about what we do to the Web."

Because WEIRDS has opted into using HTTP and URIs, it's opted into the Web, and that means it shouldn't harm other uses of the Web.

Squatting on URIs is bad practice on the Web. Requiring implementations to use certain URI patterns is bad practice on the Web. And so on.

While there may be no existing RDAP servers, the Web is pre-existing (and doing pretty well). If WEIRDS doesn't want to honour its architectural constraints, that's fine -- RDAP can use or define something else.

Cheers,

---

From: Tim Bray <[email-masked]>
Date: Wed, 12 Feb 2014 18:05:49 -0800

Speaking as a Web-centric sort of person and an Apps Area reviewer, if any
further specs come forward that try to do a URI-space land-grab, I can
promise you loud and sustained objections.

On Wed, Feb 12, 2014 at 5:34 PM, Mark Nottingham <[email-masked]> wrote:

> It's this attitude that I (and apparently other Web folks here) find
> disturbing -- to paraphrase, "we're building a new protocol, so we don't
> have to worry about what we do to the Web."
>
> Because WEIRDS has opted into using HTTP and URIs, it's opted into the
> Web, and that means it shouldn't harm other uses of the Web.
>
> Squatting on URIs is bad practice on the Web. Requiring implementations to
> use certain URI patterns is bad practice on the Web. And so on.
>
> While there may be no existing RDAP servers, the Web is pre-existing (and
> doing pretty well). If WEIRDS doesn't want to honour its architectural
> constraints, that's fine -- RDAP can use or define something else.
>
> Cheers,
>
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 13 Feb 2014 11:40:31 +0900

I can only confirm what Mark and Tim said. WEIRDS may be a new protocol, 
but HTTP isn't, and URIs aren't new, either. Both come with quite a few 
good practices that have been established over the more than 20 years 
that these are in use now.

Regards,   Martin.

On 2014/02/13 11:05, Tim Bray wrote:
> On Wed, Feb 12, 2014 at 5:34 PM, Mark Nottingham<[email-masked]>  wrote:
>
>> On 12 Feb 2014, at 9:32 am, John Levine<[email-masked]>  wrote:
>>
>>>> domain: example.com

---

From: "John R Levine" <[email-masked]>
Date: 13 Feb 2014 00:24:45 -0500

> It's this attitude that I (and apparently other Web folks here) find disturbing -- to paraphrase, "we're building a new protocol, so we don't have to worry about what we do to the Web."

I have no interest in breaking the web, but honestly, so far all I've seen 
is FUD.  Can you offer a plausible scenario where RDAP would break 
something?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 13 Feb 2014 00:25:42 -0500

> promise you loud and sustained objections.

Same question.  I really don't see a plausible scenario where RDAP would 
break anything.  Can you help us out with one?

Regards,

---

From: Tim Bray <[email-masked]>
Date: Wed, 12 Feb 2014 21:42:25 -0800

Suppose my server comes with a package where I have to route endpoints
based on URL parameters, so the WEIRDS requests come in to “
https://example.com?service=weirds <https://example.com/?service=weirds>"
so that’s my registry value.

In this case, appending /domain/whatever is going to result in a malformed
URI reference, or at least one that’s going to cause all the standard
parsing libraries trouble.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 13 Feb 2014 09:24:17 +0100

I don't understand this.

AFAICT, IANA is serving basically a giant discovery response pointing to 
lookup URLs. Why would the IANA registry have to contain only foo/rdap/ip 
for IPv4 lookups? I don't see why the lookups have to be constrained.

To look up AS31337, I retrieve the discovery response, usually from cache, 
and look up the right <link rel> in the xml. Then I ask that URL. Sounds 
good.

There are details I don't like. The draft indicates that I should take the 
URL I found in the IANA thing, append / and then my argument. Why isn't the 
slash already on the URL I found? And what escaping rules apply to my 
argument?

Arnt

---

From: Andrew Newton <[email-masked]>
Date: Thu, 13 Feb 2014 06:45:09 -0500

I don't understand this example. Doesn't it suppose that every web
application client, past, present, and future, uses templates? Since
that is not true and will never be true, this does not seem like a
valid point.

-andy

On Thu, Feb 13, 2014 at 12:42 AM, Tim Bray <[email-masked]> wrote:
> Suppose my server comes with a package where I have to route endpoints based
> on URL parameters, so the WEIRDS requests come in to
> "https://example.com?service=weirds" so that's my registry value.
>
> URI reference, or at least one that's going to cause all the standard

---

From: Graham Klyne <[email-masked]>
Date: Thu, 13 Feb 2014 12:05:11 +0000

+1 to what Mark says.

[later, on seeing some of the responses to this...]

A question I have (not having read your specs, and not intending to) is this: 
are you defining a specific *service*, or are you defining a protocol that 
others may use to deliver a service over the web?

If the former, then maybe there's not so much harm here, but it's not clear to 
me why this is seen as a potential IETF standard.  I.e. you define a service, 
and you define the URIs that will be used to access it.  Fine, it's your lawn.

But if you are defining a protocol, that tells others how to design and allocate 
URIs in their own URI space, then that tramples over the lawns of other web 
participants, and constrains their implementation and deployment choices. 
That's bad.

#g
--

---

From: "John R Levine" <[email-masked]>
Date: 13 Feb 2014 09:25:34 -0500

My, I seem to have kicked a hornet's nest here.

First, I am not speaking for WEIRDS, just for myself here.  If I seem to 
have a bad attitude, I suppose I do.  If you've ever tried to do anything 
that deals with the DNS, you'll have run into DNS fundamentalists, for 
whom the answer is to use a new RRTYPE, pretty much regardless of what the 
question was, and in at least one case (SPF) doing so broke the protocol. 
When I hear that we have to use templates, the situation feels not 
altogether dissimilar.

The advice in the get off my lawn draft reads to me as "some web servers 
are amazingly lame, so web clients have to use templates to deal with it." 
I certainly believe the first part, but it is not obvious that the second 
part is always the correct response.

> based on URL parameters, so the WEIRDS requests come in to 
> "https://example.com?service=weirds 
> <https://example.com/?service=weirds>" so that’s my registry value.

Why wouldn't it be reasonable to say if you want to run RDAP, use a server 
that can support it?  We expect there to be vastly more RDAP clients than 
servers, so it seems perverse to push complexity into the clients.

With regard to Graham's question, I'd say RDAP is a service.  It defines 
the queries, and it defines the return codes and blobs of JSON that come 
back.  If you are not a domain or IP registry, it's hard to think of a 
reason to run it.

Regards,

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Feb 2014 09:28:37 -0500

Le 2014-02-13 00:42, Tim Bray a écrit :
> based on URL parameters, so the WEIRDS requests come in
> to “https://example.com?service=weirds" so that’s my registry value.  
> 
> In this case, appending /domain/whatever is going to result in a
> malformed URI reference, or at least one that’s going to cause all the
> standard parsing libraries trouble. 

Probably a naive question, just trying to understand: couldn't you
reverse proxy that server with a front-end that would rewrite the URIs?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Feb 2014 15:27:23 -0600

> My, I seem to have kicked a hornet's nest here.

Maybe.  Perhaps the get-off-my-lawn argument needs some fleshing out.
Clearly there are people who don't see how it follows from the stated
principles.

> The advice in the get off my lawn draft reads to me as "some web servers are
> amazingly lame, so web clients have to use templates to deal with it." I
> certainly believe the first part, but it is not obvious that the second part
> is always the correct response.

I don't share this impression.

>> "https://example.com?service=weirds <https://example.com/?service=weirds>"

I think the harm from specifying baked-in local parts of URIs is that
they might collide with other pre-existing and unrelated local parts
of URIs on the servers that might want to run RDAP some day.

I.e., if I run foo.example and RDAP would make me displace an existing
resource at foo.example, that'd be bad for me.

ISTM that what's needed here is a method for discovering where the
RDAP service is hosted on foo.example.  A well-known URI would seem
appropriate.  Note that any discovery method not based on DNS is going
to add round trips -- I don't know how important that is to RDAP, or
that HTTP is a good choice if latency matters a lot to RDAP anyways.

> With regard to Graham's question, I'd say RDAP is a service.  It defines the
> queries, and it defines the return codes and blobs of JSON that come back.
> If you are not a domain or IP registry, it's hard to think of a reason to
> run it.

Yeah, but if you own a domain you're probably running an HTTP service
and some apps on it, and RDAP is stepping on your lawn.  If this sets
a precedent that one should not run anything but "standard apps" in
some domainnames, then that'd be extra bad (and definitely counter to
current practice).  It'd be much better to not do this.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2014 13:42:00 -0600

> resource at foo.example, that'd be bad for me.

Checking draft-ietf-weirds-bootstrap-01, I see that the RDAP proposal
does allow one to specify a fully formed base URI for the RDAP service
for a given domain.

Given that I fail to see the harm in specifying what resources *below*
that must look like.  It looks like any other HTTP API.  It looks like
there's no lawn squatting.

But then, there's also draft-ietf-weirds-rdap-query-10, which uses
well-known URIs, saying this in section 3:

   RDAP queries use well-known URLs [RFC5785] with the "rdap" prefix.
   Generally, a registry or other service provider will provide a base
   URL that identifies the protocol, host and port, and this will be
   used as a base URL that the well-known URL is resolved against, as
   per Section 5 of RFC 3986 [RFC3986].

   For example, if the base URL is "http://example.com/", all RDAP query
   URLs will begin with "http://example.com/.well-known/rdap".

   Note that path and query information in the base URL are not used,
   because the well-known URL is rooted at "/.well-known/rdap"; for
   example, if a registry provides "http://example.com/other/path" as a
   base URL, RDAP query URLs will still begin with "http://example.com/
   .well-known/rdap".

I see nothing wrong with the first-two paragraphs.  As for the third,
I find that surprising.  I'd expect that a well-known URI would be
used to find the correct, site-local, non-well-known base URI for
RDAP.

In particular, the third paragraph quoted above conflicts with
RFC5785, section 1.1 ("Appropriate Use of Well-Known URIs").

So there is something like URL squatting going on here, but it
shouldn't be too hard to fix this.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 14 Feb 2014 21:24:31 +0100

On Friday, February 14, 2014 8:42:00 PM CEST, Nico Williams wrote:
> I'd expect that a well-known URI would be

The URL of the IANA registry is used to find that, AIUI.

Arnt

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2014 14:39:19 -0600

> The URL of the IANA registry is used to find that, AIUI.

Then why bother with well-known URIs?

And if the whole base URI can be fetched from the IANA registry, then
there's no name squatting going on, no lawn to get off of.

I do question the scalability of IANA as a resolution service
though...  Does the IANA agree to be used this way??  Has the IANA
been consulted about this?

Also, don't we have a DNS that's meant to scale?  Why is WEIRDS not
using the DNS?

Nico
--

---

From: Andrew Newton <[email-masked]>
Date: Fri, 14 Feb 2014 15:53:17 -0500

> Then why bother with well-known URIs?

That's from a previous incarnation of helpful advice. It can probably
come out now.

> been consulted about this?

The IANA files are meant to be cached. And the IANA folks claim this
is workable.

> Also, don't we have a DNS that's meant to scale?  Why is WEIRDS not

Because not everything maps cleanly into the DNS. There were other
issues as well, all discussed on the WEIRDS list.

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 14 Feb 2014 15:58:35 -0500

> Le 2014-02-14 à 15:39, Nico Williams <[email-masked]> a écrit :
> 
> though...  Does the IANA agree to be used this way??  

Yes

> Has the IANA

Yes. See archives of weirds

> Also, don't we have a DNS that's meant to scale?  Why is WEIRDS not

Being discussed at length in weirds. I wrote multiple drafts (search draft-blanchet-weirds-bootstrap* ). Pros and cons. We settled on this one.

Marc.

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Feb 2014 15:15:33 -0600

> That's from a previous incarnation of helpful advice. It can probably

Yeah, my advice: rip it out.  It'd be nice to get a note from Mark N.
and Tim B. that yeah, there's no lawn to get off of, but don't wait
for them: that's what WG, IESG, and IETF reviews are for, and neither
of the I-Ds in question is even in WG LC, much less past it, so just
go with it.

> The IANA files are meant to be cached. And the IANA folks claim this

I meant scaling into the namespace...  But if you're only putting TLD
records in the IANA registry then yeah, it will scale.

> issues as well, all discussed on the WEIRDS list.

I'd think that WHOIS stuff does!  But OK, I don't care enough to look
into it any further.

Nico
--