What Masataka san is saying here makes perfect sense to me. I proposed exactly this approach a decade ago.
Today we have separate registries for URIs, .well-known and SRV. These separate registries with two columns should become a single registry with four.
So instead of making three separate registrations for 'mmm', there should be one registry. If I (pre)register an mmm URI scheme, that automatically blocks out registration of 'mmm' for .well-known and srv.
Take FTP for example, it doesn't use SRV today, probably never will. But it does have an SRV registration and a URI registration. And while .well-known doesn't make a lick of sense for FTP, it would be really rather bad if there was a different protocol squatting on that code point.
IANA registries are not a control point like people imagine them to be. Nor are IPv6 address blocks. When I found there was no process for registering code points for use in SAML and the IETF refused to create one, I issued them myself. The reason there is now a process for registering SRV without a port is precisely because so many other people took that route that the IANA registry was losing credibility.
If that idiot in Congress remembers the idea he had about prohibiting Iran and Cuba registrations for IPv6 blocks and succeeds this time, the same will happen to that registry.
SRV+TXT meets all the discovery needs of my rather demanding system. I even have a prototype that allows me to avoid the need for the traditional two layer architecture for Web services and have one where a client is immediately directed to the host with the information to service a particular user.
The only thing I can think of to improve on SRV and TXT would be to have single stop records for host description and service description. But that would require new RRs and the only gain comes from minimizing the amount of DNSSEC signature validation required.
On Sun, Sep 17, 2023 at 10:51 PM Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Keith Moore wrote:
>> Then, what's wrong with SRV to be used for those URLs
>> having authority section resulting in port
>> independence?
>
> How do you map the path portion of a URL onto a label for a DNS RRset?
Why, do you think, I have to map??? Any example URL?
AFAIK. the following conversion of authority section from:
<scheme>://[<userinfo>@]<host>[:<port0>]<path>[?<query>]
to
<scheme>://[<userinfo>@]<target>:<port><path>[?<query>]
by
_<scheme>.<host> SRV <priority> <weight> <port1> <target>
should be good enough for port independence, because <port>
and <host> are fully specified by the authority section, with
which <path> has nothing to do.
Masataka Ohta
