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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf