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

From: Darrel Miller <[email-masked]>
Date: Sat, 15 Feb 2014 17:44:34 -0500

On Fri, Feb 14, 2014 at 2:42 PM, Nico Williams <[email-masked]> wrote:
> On Thu, Feb 13, 2014 at 3:27 PM, Nico Williams <[email-masked]> wrote:
>>
>> 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.
>
> 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.
>

Preventing collisions is only one of the reasons that get-off-my-lawn
mentions for avoiding specifying URI structure.  Enforcing any kind of
structural rule on URIs can interfere with implementation choices of
the server framework.  Limiting the server framework, limits where
RDAP can be used, which seems counter productive to me.

As an example, this URL,
http://example.com/.well-known/rdap/ip/192.0.2.0/24 would be pain for
a few of the frameworks that I am familiar with as it is not possible
to have a slash as part of a parameter value.  Creating a routing that
would handle both the IP and CIDR parameters would be tricky.

One of the major advantages of using URI templates, beyond freeing the
server from conforming to conventions, is that it makes client code
really simple.  All a client needs to do is retrieve a URI template
identified by a link relation and pass parameters to a URI template
resolution library (of which there are many).  The client doesn't need
to know any of the details about to construct URIs.  URI construction
can be a pain as there are quite a number of esoteric rules for
accurate production of a URI.  Why burden all the clients with that
work and constrain the usable server frameworks, all to save one level
of indirection that can be easily be cached on the client?

>From briefly reviewing the rdap-query spec, it would seem that the
spec could reduce down a set of link relation specifications

rel="http://rdap.org/rels/ip"  - Points to IP information using the
parameter {ipaddress} where {ipaddress} is a IPv4/IPV6 address or
IPv4/IPv6 CIDR.

rel="http://rdap.org/rels/autnum"  - Points to autonomous system
number registrations where the parameter {autnum} is an AS Plain
autonomous system number.

rel="http://rdap.org/rels/domain"  - Points to domain information
where the parameters {domain} is is a fully-qualified (relative to the
root) domain name  [RFC1594] in either the in-addr.arpa or ip6.arpa
zones (for RIRs) or a fully-qualified domain name in a zone
administered by the server operator (for DNRs)..

rel="http://rdap.org/rels/nameserver" - you get the idea....
rel="http://rdap.org/rels/entity"

and help already exists as a standard link relation, so no need to
redefine. And for searches,

rel="http://vnd.rdap.domains"
rel="http://vnd.rdap.nameservers"
rel="vnd.rdap.entities"

Now all you need is a single .well-known name, such as,
http://example.com/.well-known/rdap/home that could return something
like this application/home+json document,

{
  "resources": {
    "http://rdap.org/rels/ip": {
      "href-template": "http://rdap1.example.org/myrdap/ip/{ip}",
      "href-vars": {
        "ip": null
      }
    },
    "http://rdap.org/rels/autnum": {
      "href-template": "http://rdap1.example.org/myrdap/autnum/{autnum}",
      "href-vars": {
        "autnum": null
      }
    },
    "http://rdap.org/rels/domain": {
      "href-template": "http://rdap1.example.org/myrdap/domain/{domain}",
      "href-vars": {
        "domain": null
      }
    },
    "http://rdap.org/rels/nameserver": {
      "href-template":
"http://rdap1.example.org/myrdap/nameserver/{nameserver}",
      "href-vars": {
        "nameserver": null
      }
    },
    "http://rdap.org/rels/entity": {
      "href-template": "http://rdap1.example.org/myrdap/entity/{handle}",
      "href-vars": {
        "handle": null
      }
    },
    "help": {
      "href": "http://rdap1.example.org/help"
    },
    "http://rdap.org/rels/domains": {
      "href-template": "http://rdap2.example.org/myrdap/domains{?name}",
      "href-vars": {
        "name": null
      }
    },
    "http://rdap.org/rels/nameservers": {
      "href-template": "http://rdap2.example.org/myrdap/nameservers{?name,ip}",
      "href-vars": {
        "name": null,
        "ip": null
      }
    },
    "http://rdap.org/rels/entities": {
      "href-template": "http://rdap2.example.org/myrdap/entity{?fn,handle}",
      "href-vars": {
        "fn": null,
        "handle": null
      }
    }
  }
}

This document can be cached by clients and provides all the URI
templates to access the RDAP server's services.  By using complete URI
templates you get the opportunity to do other things, like in this
example I moved the search queries onto a different host "rdap2" to
distribute load.

This is just one way of creating a discovery process that would be
familiar to web developers and requires minimal specification because
it is reusing existing techniques.

If you don't think this would work for this use case, don't hold back,
you won't hurt me feelings :-).  I would be really interested to
understand why it wouldn't work.

Regards,

Darrel Miller

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2014 03:55:39 -0000

>really simple.

People keep saying this.  My client is a three line shell script that
uses wget and grep (really.)  Could you explain how that works with
templates?

While you're at it, it'd also be helpful to identify some web servers
that people might plausibly use to implement RDAP in 2014 (as opposed
to an exercise in retrocomputing) that couldn't handle the syntax in
rdap-query.  You can skip the .wellknown stuff, which is a holdover
from a point when we thought we might use something like SRV records
that don't provide a path in the bootstrap.

R's,
John

---

From: Tim Bray <[email-masked]>
Date: Sat, 15 Feb 2014 21:49:24 -0800

I gather that you are fortunate enough never to have dealt with various
sorts of shared or enterprise deployments where you have all sorts of
constraints on what bits of webspace you’re allowed to touch and what kinds
of things you’re allowed to have in your URIs.  Anyone who can deploy their
own server infrastructure and pick what to use is probably able to dance to
whatever RFC’s tune, but lots can’t.

Anyhow; by definition, the server is authoritative on the URI space it
serves and standards shouldn’t screw with that.

On Sat, Feb 15, 2014 at 7:55 PM, John Levine <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Andrew Newton <[email-masked]>
Date: Sun, 16 Feb 2014 08:11:38 -0500

> would handle both the IP and CIDR parameters would be tricky.

And yet there are some methods/frameworks that would have a problem
doing as you suggest as well, so it's a tradeoff. As it stands, all
RDAP lookups can be laid down on a file system. Your suggestion would
remove that.

> like this application/home+json document,

[..snip..]

I believe this is where Mark was going with the bootstrapping. It's
worth exploring at that layer as it is more useful there than with
.well-known.

Thanks.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 16 Feb 2014 14:58:20 -0400

>> uses wget and grep (really.)  Could you explain how that works with

We seem to be talking past each other here.

I believe that there are web servers that for reasons of bureacracy are 
run in ways with weird limitations, and it would be nice for them if http 
clients would do arbitrarily complex stuff to work around those servers' 
limitations.  Although it's hard to imagine why a domain or IP registry 
would use a server like that (none do now), it's not hard to imagine ISPs 
delegating the RDAP for an IPv6 /56 or /60 to a a SOHO router that's 
routing the IP traffic, where RDAP will share the tiny http server with 
the one for the config panel.

But there are also web clients that are rather constrained for both 
administrative and technical reasons, and "use templates" is not helpful 
advice.  (See unanswered question above.)

I also think I understand why it is not a good idea to invent random fixed 
URL syntax that people might shove into random places in a web server, but 
that's not what RDAP is proposing.  Each RDAP server picks its own 
arbitrary URL prefix which the bootstrap or upstream servers know about, 
and the RDAP stuff is all constrained to be under that prefix, not 
anywhere else in the name space. It's true, the syntax requires that some 
stuff be in the path and some as queries, but so be it.

As firmly as one side can say get better clients that can handle arbitrary 
templates, the other side can say get better servers that can handle the 
syntax that everyone uses.  Since there will be way more clients than 
servers, fixing the servers will minimize the global pain.

Having been through this kind of stuff before,* if RDAP is forced to stick 
in templates to get through the IESG, here's what will happen: a few 
clients that already have template libraries will use them.  Everyone else 
will see that the largest domain and IP registries use the syntax in the 
draft (their prototypes do now), and the small registries and 
subregistries will use the free python server commissioned by ICANN, which 
also uses the same syntax, so in practice you can skip the templates and 
it'll work.

A few registries or LIRs might take the spec at face value and use 
different URL syntax and expect the templates to deal with it. They will 
get a stream of complaints from people who tell them that their clients 
work fine with everyone else, you're broken, don't waste our time playing 
RFC lawyer.  So they'll eventually give up and stick in a rewriting proxy 
to match the defacto standard syntax, or for registries who are stubborn, 
helpful entrepreneurs will run proxies on their behalf which translate the 
queries, and also snoop on the query stream.  There are plenty of web 
WHOIS sites right now now that conveniently find the right WHOIS server 
for you and sell the queries to domain speculators, so this isn't a 
stretch at all.

I hope we agree that would be a ridiculous outcome.  If you want to help 
us, you need to understand RDAP enough to see what has a realistic chance 
of posing a problem in actual deployed implementations, and how to offer 
advice we can realistically follow.

R's,
John

* - I'm thinking of when SPF was forced to add a new RRTYPE

---

From: Darrel Miller <[email-masked]>
Date: Sun, 16 Feb 2014 17:24:55 -0500

John,

Wow, that sucks for you guys.  I'm glad I don't have to spend time
writing specs that people are going choose to ignore at their own
convenience.

I wish you the best of luck.

Darrel

On Sun, Feb 16, 2014 at 1:58 PM, John R Levine <[email-masked]> wrote:
> I believe that there are web servers that for reasons of bureacracy are run
> in ways with weird limitations, and it would be nice for them if http
> delegating the RDAP for an IPv6 /56 or /60 to a a SOHO router that's routing
> the IP traffic, where RDAP will share the tiny http server with the one for
> the config panel.
>
> that's not what RDAP is proposing.  Each RDAP server picks its own arbitrary
> URL prefix which the bootstrap or upstream servers know about, and the RDAP
> stuff is all constrained to be under that prefix, not anywhere else in the
> name space. It's true, the syntax requires that some stuff be in the path
> and some as queries, but so be it.
>
> in templates to get through the IESG, here's what will happen: a few clients
> that already have template libraries will use them.  Everyone else will see
> that the largest domain and IP registries use the syntax in the draft (their
> prototypes do now), and the small registries and subregistries will use the
> free python server commissioned by ICANN, which also uses the same syntax,
> so in practice you can skip the templates and it'll work.
>
> A few registries or LIRs might take the spec at face value and use different
> URL syntax and expect the templates to deal with it. They will get a stream
> of complaints from people who tell them that their clients work fine with
> everyone else, you're broken, don't waste our time playing RFC lawyer.  So
> they'll eventually give up and stick in a rewriting proxy to match the
> defacto standard syntax, or for registries who are stubborn, helpful
> entrepreneurs will run proxies on their behalf which translate the queries,
> and also snoop on the query stream.  There are plenty of web WHOIS sites
> right now now that conveniently find the right WHOIS server for you and sell
> the queries to domain speculators, so this isn't a stretch at all.
>
> I hope we agree that would be a ridiculous outcome.  If you want to help us,
> you need to understand RDAP enough to see what has a realistic chance of
> posing a problem in actual deployed implementations, and how to offer advice
> we can realistically follow.
>
> R's,
> John
>

---

From: Graham Klyne <[email-masked]>
Date: Sun, 16 Feb 2014 11:08:39 +0000

> uses wget and grep (really.)  Could you explain how that works with

I've done something like this for apps I write by providing a simple template 
expansion service (POST template+parameters as JSON, get URI back).

E.g.

[[
# URI template expansion

echo "==== Request URI-template expansion ===="
cat >sample-params.txt <<END
{
   "template": "$TEMPLATE",
   "params":
   {
     "RO": "http://sandbox.wf4ever-project.org/rodl/ROs/simple-requirements/",
     "minim": "checklist-runnable.rdf",
     "purpose": "Runnable"
   }
}
END

EVALURI=$HOST`curl -X POST --data @sample-params.txt $HOST/uritemplate`

echo "==== URI: $EVALURI"
]]

#g
--

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Feb 2014 09:09:30 -0800

There is clearly a question of whether the WEIRDS WG will be allowed to use their current approach or be forced to change to templates. That question cannot be answered by more messages on this mailing list.

draft-ietf-weirds-using-http-08 has a protocol that would not be acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP. That determination should be answered sooner rather than later so that the WG can progress with their protocol.

--Paul Hoffman

---

From: Andrew Newton <[email-masked]>
Date: Mon, 17 Feb 2014 12:22:31 -0500

> There is clearly a question of whether the WEIRDS WG will be allowed to use their current approach or be forced to change to templates. That question cannot be answered by more messages on this mai…

I think you have incorrectly framed the issue and resolution. The
issue is if the WEIRDS WG is specifying a protocol with URI
collisions. If they are, one of possible resolutions is to use URI
templates.

-andy

---

From: Tim Bray <[email-masked]>
Date: Mon, 17 Feb 2014 10:40:07 -0800

Andy’s right, there are other ways out of the box. For example, to use an
HTTP header on their GET, or to use a POST rather than a GET with selector
information in the message body.  Or even better a PUT since it’s
idempotent.

On Mon, Feb 17, 2014 at 9:22 AM, Andrew Newton <[email-masked]> wrote:

> > There is clearly a question of whether the WEIRDS WG will be allowed to
> use their current approach or be forced to change to templates. That
> question cannot be answered by more messages on this mailing list.
> >
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Feb 2014 11:07:41 -0800

On Mon, Feb 17, 2014 at 9:09 AM, Paul Hoffman <[email-masked]> wrote:

> draft-ietf-weirds-using-http-08 has a protocol that would not be
> acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP.
> That determination should be answered sooner rather than later so that the
> WG can progress with their protocol.

Feedback about the content of draft-ietf-appsawg-uri-get-off-my-lawn is
perfectly appropriate for this list.  I don't believe there's any need to
get the ADs to rule on anything at this point.

Feedback specific to draft-ietf-weirds-using-http and how it resolves this
question should appear on that WG's mailing list, and not here.  I don't
believe we need an AD ruling on anything there yet either; the WG is still
doing its work on this document.

-MSK, co-chair of both WGs

---

From: Pete Resnick <[email-masked]>
Date: Mon, 17 Feb 2014 13:38:50 -0600

On 2/17/14 12:40 PM, Tim Bray wrote:
> On Mon, Feb 17, 2014 at 9:22 AM, Andrew Newton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman
>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     There is clearly a question of whether the WEIRDS WG will be
>>     allowed to use their current approach or be forced to change to
>>     templates. That question cannot be answered by more messages on
>>     this mailing list.
>
> Andy's right, there are other ways out of the box. For example, to use 
> an HTTP header on their GET, or to use a POST rather than a GET with 
> selector information in the message body.  Or even better a PUT since 
> it's idempotent.

Yep. And as Murray said, the specific discussion belongs over on the 
WEIRDS list. The chairs of that WG (gee, do we know any of them?) should 
of course invite the right people into that discussion if they need 
specific inviting. And if progress can't be made on the list, perhaps 
some cross-group face-to-face time would solve the problem. (I wonder 
where and when that could happen... :-) )

Look, nobody died and made me (or Barry) king. This is a technical 
issue, and you folks need to figure it out. We (and the chairs) are here 
to help out if you finally decide, "We are not getting what these people 
are saying. Help us find a path out of this mess." But I don't think you 
all are there yet.

It would help very much if both sides refrained from saying, "It's 
obvious that you don't get the obvious solution to this, which is 
obviously stated in our draft." Some folks are not understanding what 
the problem is (on both sides). Some folks are not explaining well 
enough for others to understand what the solution space is. If everyone 
gets on the same page, I'm hopeful that a good solution will at least be 
easier to see, if not "obvious".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Feb 2014 11:46:00 -0800

On Feb 17, 2014, at 11:07 AM, Murray S. Kucherawy <[email-masked]> wrote:

> Feedback about the content of draft-ietf-appsawg-uri-get-off-my-lawn is perfectly appropriate for this list.  

I believe what I said is feedback:

> draft-ietf-weirds-using-http-08 has a protocol that would not be acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP.

That is, if Mark had gotten grumpier a year earlier and we already made draft-ietf-appsawg-uri-get-off-my-lawn a BCP, it would *prevent* the WEIRDS WG from doing what is in draft-ietf-weirds-using-http-08, assuming that the Apps ADs wanted to enforce it. A BCP full of MUSTs that are ignored does not sound like a good idea.

Asking Pete and Barry to give direction now to this WG and/or to WEIRDS seems appropriate, given the mere timing issue.

--Paul Hoffman