On Mon, Jun 14, 2010 at 1:18 PM, Alfred HÎnes <ah(_at_)tr-sys(_dot_)de> wrote:
At Fri, 11 Jun 2010 23:30:03 -0400, Phillip Hallam-Baker
wrote, in response to a message from Masataka Ohta:
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.
Sounds reasonable, but below you obviously want to arrive at just
such a HTTP URI!
Of course we would use HTTP under the covers for quite some time,
possibly indefinitely. But the advantage of abstracting it away from
the URI is that we are not obliged to.
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.
I'm getting confused very much.
DNS SRV RRs map a triple
{domain name, transport protocol, service name}
to a target FQDN and a service port number (where the application
server is listening) -- setting aside the priority information,
which esentially allows to add redundancy and fallback, but no
additional kind of information.
So you already need to know the service name and the transport protocol.
That might be reasonable in your context.
But how do you envision to obtain the URIs (like those you show above)
from the RDATA in a SRV RR?
Let us imagine that we have a client that implements version 1.0 - 2.3
of the _maps._ws Web service.
The host that is supporting that Web service is probably going to be
running multiple web services and quite likely different versions of
that Web Service. In some cases it may be desirable to run different
executables to support different Web Service versions.
It is one thing to require a host to have a different domain name for
use to bind Web services. Requiring a new DNS name to be registered
for every Web Service instance on the host would violate the single
point of administration principle.
So as a practical matter the host services1.example.com would probably
have a services layout something like
http://services1.example.com/_ws/_maps/1/0 [maps1.exe]
http://services1.example.com/_ws/_maps/2/0 [maps_new.exe]
http://services1.example.com/_ws/_xkms/* [xkms.cgi.exe]
http://services1.example.com/_ws/_keyprov/* [keyprov.exe]
... etc
The URI stem being formed from the SRV protocol prefix and the
protocol version number
First lets look through what the client has to do if there is no
negotiation information in the DNS besides the SRV record.
The client pulls the SRV record _maps._ws.example.com and chooses a
host according to the weighting. It now has to choose a protocol
version to attempt. If version 2.0 is incompatible with version 1.0
the client is going to have to guess which one to attempt first.
Better is to have a mechanism that allows the site to tell the client
which Web Service versions are supported so that the correct one can
be chosen. In some cases this may mean selecting a different host
because the legacy Web service version is only supported on an older
host.
Did you have in mind a (yet unspecified) DDDS (RFC 3401-3404)
application, which would employ the use of DNS NAPTR RRs
(and then most likely SRV RRs as a 'backend') ?
NAPTR RRs can (with particular flag settings) produce an URI
out of a domain name and a service tag. But please note that
NAPTR RRs contain the service tag as an embedded selector and
therefore need particular thoughts -- cf. the IAB deliberations
in RFC 5507.
I am not a fan of NAPTR. Regular expressions have a great deal of
power and really should not be resorted to lightly in my view.
In this case I want to get to a world where the SRV records can be
managed automatically by the service applications themselves. To make
that practical I need to squeeze out all the flexibility and site
specific options from the configuration as is possible.
While machines can write their own NAPTR records they are not able to
make sense of records written by humans.
The idea here is that to place the Web service on IIS or Apache, the
code module simply requests access to the relevant Web Service prefix
port and the Web server then makes the (authenticated) dynamic DNS
request to register the SRV record. When the Web service shuts down
the SRV record can be automatically deleted.
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf