Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jan 13, 2016 at 10:43 PM, Patrik Fältström <[e-mail]> wrote:
> This goes back to the preference of one group of people to have things in
>DNS (like the URI resource record) and via DNS lookup know what URI to
 >fetch over HTTP, and the preference from another group of people to have
 >the redirect in HTTP from a well known URI to whatever URI to fetch over
 >HTTP. And we have had this discussion the now last 20 years. Without
 >really resolving it.

There are two models of Internet development. One is to let chaos
reign and the other is to keep control at all costs. The first
invariably wins in the end.

Existing practice is that most developers simply ignore the
registration process unless they are proposing the protocol to the
IETF.

I know about the URI record of course. I just can't use it with my
service provider which is a very large one using the same DNS
configuration tool used by most of the other service providers.
Deployment of new DNS record types remains a challenge.


> We all use our favorite tools, right? ;-)

No, I use the tools that are expedient and get the job done.

Since I want to make use of service identifiers inside other
identifiers, there is actually a real difference to me between
example.com and http://example.com/foo/bar. I can use the first to
construct a reasonable account identifier for the service:

[e-mail]

I really don't think people will accept identifiers of the form

alice@http://example.com/foo/bar

And no, that isn't as far fetched as it might sound. The original
OpenID proposal was to use URLs for user identifiers. And the people
involved were utterly wedged on that lunacy (someone had a patent on a
scheme to make the names friendly).


> My point is that regardless of whether method A or method B is in use, each one of them should be allowed to in the IETF to be designed properly.

+1 absolutely.

> What is actually deployed is what Daniel implements in libcurl anyway, right? :-D

Not in this case as these are all Web Services that are built way
above the level of 'fetch data'.