Re: [apps-discuss] unpersuasive advice, was draft-ietf-weirds-bootstrap-00

["John Levine" <[e-mail]>]

>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.

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?

>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.

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