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(_at_)necom830(_dot_)hpcl(_dot_)titech(_dot_)ac(_dot_)jp> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf