Phillip Hallam-Baker wrote:
I note in passing that this might have played out differently had we gotten
SRV
record support in place for all protocols a lot sooner. But without it for
HTTP
in particular you're faced with the need for multiple port 80s in a lot of
cases.
What I would like to see the IETF do is to produce a new architecture
document that tells application and Web Service designers how they
should be using the Internet. In my view DNS+SRV should become the
only way that Web services are located (I do not think the extra
capabilities of NAPTR are necessary or even useful for service
discovery).
Interesting.
The problem of SRV is that it is *NOT* URL friendly that web people
should have no idea on how to use it.
While SRV is designed following the syntax of IP as:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
most applications know <Service> and <Proto> by number from
the beginning that there is no room to convert them to ASCII
strings.
The only notable exception, of course, is when URLs are used.
However, as the syntax of Internet URLs is:
<scheme>://<user>:<password>@<host>:<port>/<url-path>
applications have no information on the ASCII representation of
Proto.
So, SRV should be used as:
_Scheme.Name TTL Class SRV Priority Weight Proto Port Target
where Weight and Proto are 8 bit quantities to make the RR
format compatible to todays.
Then, if we recommend web people try SRV when "Name" is not
resolved to addresses, they should be happy to use it.
Masataka Ohta
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf