The URI syntax you specify is only used for some protocols and most of the elements are defaulted. In fact we have got to the point where for Web browsing everything is defaulted except for the domain name. I think we need to break the idea that a Web service should have a URL that starts HTTP. Rather, if we are connecting to the Google mapping Web Service we would type in either google.com - if the type of service needed was obvious from the context ws:google.com:maps - for the fully qualified version Under the covers this would of course expand via SRV to a http URL, probably something of the form http://services1.google.com/ws/maps/1/0 http://services2.google.com/ws/maps/1/0 Since the SRV record is expanding to a domain name that we presume to be reserved for hosting of Web services we can take over the specification of the URI stem in the protocol. The real advantage of this approach is of course that we then have a layer that we can later use to lift ourselves off of using HTTP as a Web Services transport. If the web service offers SSL we can put a record in the DNS that says 'use SSL for this connection'. If there is a binary version we can have a hint to say that the binary version is available. And within this framework we can slip in a hint to the effect 'works best with IPv6' On Fri, Jun 11, 2010 at 4:09 PM, Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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 > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf