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

From: Darrel Miller <[email-masked]>
Date: Sun, 16 Feb 2014 11:09:22 -0500

John,

Your client is a three line shell script because someone took the time
to write programs like wget that implement a standard protocol.  It
would surprise me if someone hasn't already written a URI template
processing utility that you can call from your script.  Your 3 lines
would likely end up being 4 lines. Pseudocode would look something
like,

get homedoc from homeUri
parse desired service uri template from homedoc
resolve URI template with parameters
get informationdoc from resolved URI

However, we seem to be addressing this whole issue from the wrong
perspective.  It is quite probable that the people who are
implementing the RDAP servers will have no issue handling the URIs.
It is quite likely that the clients will be able to successfully
create the necessary URIs.  It is possible that you will not need to
change the RDAP URI space once the spec has been baked.

However, you are highly visible, publicly accessible service that has
chosen to use HTTP.  IETF best practices recommend that you don't do
what you are doing.  Will it work for you, sure, probably, because of
your context.  The problem is that other developers developing HTTP
based services are going to look to what you have done as an example
and say, look, at how RDAP works.  If it works for them, then why
won't it work for us.  But their context may not be the same as yours.
 It is in the web's best interest if high profile services like RDAP
are a model for others to follow.

The question should not be, why should RDAP follow best practices when
they are not absolutely necessary? The question should be, what
justification exists for not following that guidance. Justifications
might include,
- there are no URITemplate processing libraries available on the
target client platforms.
- caching infrastructure does not exist on client platforms to
minimize the impact of the extra round-trip to get the home doc.

I don't know if these are valid objections, but I think that would be
a better discussion to have than the current one.

Regards,

Darrel

On Sat, Feb 15, 2014 at 10:55 PM, John Levine <[email-masked]> wrote:
>>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.
>
> 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
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

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

>processing utility that you can call from your script.

Quite posssibly, but it's hard to find among vast array of http
servers and proxies that can easily serve up any URL structure we
would ever define, removing any need for templates.  Why should tens
of thousands of clients change their code rather than hundreds (maybe
less, considering how concentrated the domain business is) of servers?

>what you are doing.

Yes, we're quite aware of that.  We're your friends, and we find this
advice unpersuasive, so I wouldn't even want to think about the
zillions of random RDAP users who just want to get some answers.

Andy has pointed out, more tactfully than me, that when the web crowd
has described something that might plausibly be a problem, we've gone
to some effort to fix it, e.g., path prefixes in RDAP bootstraps to
avoid an implicit need for RDAP servers to have their own (essentially
free these days) virtual domain.  At this point, the only concrete
reason I've seen to use templates is that someone might want to run
RDAP on a crappy server that can't implement our very simple URL
structure with its own chosen prefix, so we need to add all sorts of
template stuff to our clients just in case.

I can't speak for the rest of WEIRDS, but in view of what RDAP is and
the existing prototypes, that is simply not a problem I see any reason
to care about.  If you want people to follow your advice, you need
credible arguments about what could plausibly break in real world
scenarios and reasonable tradeoffs in implementation cost, not
"because we say so".  We went down the latter road with SPF, the IETF
best practices from the DNS crowd turned out to be completely wrong in
that context (something they still don't admit) and I for one am not
interested in doing it again.

R's,
John

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Feb 2014 22:38:58 -0600

> would likely end up being 4 lines. Pseudocode would look something

It'd probably still be three loc because where RDAP says to find base
URIs now one would find templates, and then it's just a matter of
passing the named parameters' values to wget in the one command.
Granted, wget (and curl) lacks template support, but it shouldn't be
hard to fix that (or to implement a command-line template expander).

Having just met and read RFC6570, I must say, it seems like the right way to go.

Here's a list of open source URI template implementations:

https://code.google.com/p/uri-templates/wiki/Implementations

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Feb 2014 17:25:28 +1100

> interested in doing it again.

So, you keep on using that analogy.

The thing is, introducing a new RRTYPE has well-understood, difficult-to-overcome operational problems.

However, here your argument seems to be "it's too hard; I want to write a three-line shell script."  Is there more? Because "I have to write a bit more code" is not equal to the fundamental deployment problems that introducing a new RRTYPE brings, not even close.

I think a better analogy is this -- you want to deploy a new protocol over TCP/IP, but for convenience you want to assume that all hosts on the local network ending in ".2" speak your protocol.

When the IP folks express concern about the operational problems this will bring, and the precedent it will set for others, you say "But, the people deploying my protocol will just deploy a new network for it -- it's not a problem!" And so on.

Like all analogies, it'll break down at some point; it's just closer than RRTYPE vs. TXT, IMO.

Cheers,

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