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

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

On Thu, Jan 14, 2016 at 10:01 AM, Eliot Lear <[e-mail]> wrote:
> Mark,
>
> On 1/14/16 6:34 AM, Mark Nottingham wrote:
>> You can also register /.well-known/phks-protocols/ and do whatever you like under it.
>
> By your own words, that's simply not true unless there is a
> specification tied to it, and personally I think that's a very high
> bar.  On the one hand this is not like port numbers- there are a near
> infinite number of possible subtrees under .well-known, as compared to
> the somewhat constrained port number space.  On the other hand,  one
> doesn't want to create a land rush on mnemonics.  IMHO this is possible
> to fix.  Simply allocate a random string of 8 characters or so for a
> developer to use (not for them to choose).  This should suit developers
> who do not wish to publish their specifications or otherwise have reason
> to apply more meaning or structure as you mention in Section 3 of 5785,
> but otherwise do not wish to produce specifications.  For those who
> still want a mnemonic, they can produce a spec.

Actually SRV and .well-known are both very much like ports in that
they serve different aspects of the same function without the port
number restriction.

The original Internet discovery mechanism had two steps:

1) Conversion of the DNS name of the service to a network host
(identified by IP address) via DNS A record lookup

2) Identifying the protocol to the host at the specified address.


The SRV record was originally proposed as a replacement for both parts
of this problem and equally importantly, to provide the fault
tolerance and load balancing capabilities that the MX record provided.

The fact that HTTP does not use SRV records is irrelevant because Web
Services have used SRV since the very first Web Services standards
were written. I know because I wrote those parts of the specs.

People developing Web Services certainly want to use a mechanism like
SRV records to get the benefits of the fault tolerance mechanism.
Using an SRV record we specify the priority, wieghting, port number
and host name of each server providing a service:

_mmm._tcp.example.com 0 20 80 host1.example.com
_mmm._tcp.example.com 0 80 80 host2.example.com
_mmm._tcp.example.com 1 5 80 voldemort.example.com

This specifies three hosts that can provide service for the domain.
When host1 and host2 are both available, host2 gets 80% of the
requests and host1 gets the rest. If a client can't connect to either,
they connect to voldemort.


The reason SRV isn't sufficient for Web services by itself is that Web
Service hosts typically host multiple services and it would be really
inconvenient (and inefficient) to separate them by port number.

Some other means of separating the Web Services is required. Some time
ago now Patrik suggested the URI scheme which is a perfectly sensible
way to achieve the objective but it does introduce other problems.

One of these is that there are now two different mechanisms for
discovery and the person configuring the protocol has to know which
one to use. Another is that many ISPs do not provide a means to
configure URI records, only SRV is supported.

So just as Netscape discovered that it was necessary to add the Host:
header to the original HTTP protocol, there is now a need to add the
SRV prefix which serves the equivalent function. The most
straightforward way to do that is to use the .well-known convention.

The logic of this approach over the URI RR becomes apparent when the
design of a HTTP successor protocol that is specifically for Web
Services is considered. Most Web services make almost no use of HTTP
features beyond the protocol identification described above and the
message framing. If one was developing a protocol that was only for
Web Services, it would not have features such as caching which are
almost never desirable. Such a protocol would probably treat URLs that
are outside the .well-known set as the exceptions.


So far I have not seen a single technical argument been made against
this approach. It quite definitely works and it is certainly as well
founded as a published RFC written by someone who was an IAB member at
the time.

The only arguments I have seen are about the need for gatekeepers to
protect the integrity of the Internet. Which in this case are being
made by the gatekeeper in question. I think that we need to know the
following:

* Approximately how many requests are made each year?
* Of these what proportion are accepted / rejected / abandoned?
* In what cases have changes been made to a protocol in order to make
it acceptable?


But regardless of the answers to these questions, there is a much
larger policy question which is what should be the IETF policy for
assignment of code points in registries that have an effectively
unlimited supply?

I am genuinely troubled by a situation in which being a domain expert
for an IANA registry seems to be giving one individual a degree of
power we do not afford the IESG. When the response to raising such
issues is personal attacks, then I take offense.


In answer to Eliot's issue, I do not see SRV prefix squatting as being
a problem. It certainly hasn't been a problem to date. The worst that
can happen is that we run out of easy to remember prefixes and people
have to use unmemorable ones. But the only practical alternative being
to start with unmemorable ones, I can't see it helping.