Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV)

From: Doug Barton <[email-masked]>
Date: Sat, 02 Feb 2013 17:07:17 -0800

On 01/22/2013 06:21 AM, Phillip Hallam-Baker wrote:
> OK so looks like the optional policy string is not a good idea. At least
> as far as the normal form goes.
>
>
>
> On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote:
>
>         * SRV (does not work well for Web services)
>
>
>     Can you elaborate, or provide a reference?
>
>     Doug
>
>
> The problem with SRV and Web services is that a typical Web Server
> deployment supports multiple Web Services, some of which are only going
> to be called maybe five times a day, if that. So the Web Services
> actually make use of the stem part of the URI to identify the location
> on the Web Server.

How would that change with the use of an SRV record?

> So to use SRV to announce a Web Service you need some way to specify the
> location on the Web Server.

Why?

> One approach is to specify a .well-known
> location for the service but that is rather less flexible than many
> deployments will accept and it stops a server having two different
> versions of the same protocol running in parallel - something you are
> very likely to want to do if you are witching between protocol versions
> or implementation versions.

Sorry, I don't parse the above paragraph at all.

In my (perhaps naive) view, the purpose of the SRV record is to allow 
the end user system to find the right address and port to connect to for 
the specified service. The things you're describing seem to me to be the 
business of the web server once the end user is connected. If I have 
missed something here, please clue me in.

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Feb 2013 12:15:42 -0500

>> location on the Web Server.

It is very common for a single Apache server to be supporting a dozen or
more Web Services as applets. The Microsoft platforms now go even further
providing what amounts to an operating system level treatment of Web
Service locations as if they were TCP/IP port numbers complete with
granular security privileges.

SRV only allows for defining a DNS name and a port number, there is no
provision for a service location which is why the 'well known' locations
were originally proposed. But just like fixed port numbers, that is a
pretty inflexible approach that gets in the way of development and test
deployment. It is OK to have a requirement for the Web Service to be at
/.well-known/foo for production, but most of us would want to bring up a
new service by first deploying it on the target server somewhere else,
testing it and then cutting over to the new one by changing the config.

Which is why the URI proposal is a logical extension of the SRV idea.

My original belief was that SRV would be sufficient and all we needed was
to define a _wk space for SRV prefixes so that defining a .well-known
prefix would automatically assign an SRV prefix just like a well known port
used to when there were ports left. People in the apps area convinced me
otherwise.

URI would be a logical choice only it hasn't had wide uptake yet and does
not support any mechanism to allow the client to make an informed choice
between the services offered according to its own criteria or policy advice.

> In my (perhaps naive) view, the purpose of the SRV record is to allow the
> end user system to find the right address and port to connect to for the
> specified service. The things you're describing seem to me to be the
> business of the web server once the end user is connected. If I have missed
> something here, please clue me in.

If you have multiple services on different hosts you need to make the
choice before you connect to the server. Afterwards is too late.

-- 
Website: http://hallambaker.com/