Re: on DNS records

It might be useful to distinguish service from protocol.

If we have an abstract service 'mail' then it might involve the use of
three separate existing application protocols SMTP, POP, IMAP plus new
protocols that do the same thing in XML, JSON or whatever you like.

SRV is only designed to support load balancing and failover. It does not
allow for announcing multiple protocols to do the same thing.


For HTTP the answer might seem rather simple, it is all just Web pages,
right?

But HTTP is also the transport for Web Services and those are much better
published as services in their own right. Say Gopple has a Web service
protocol for mapping and Aggle has a different protocol and they decide to
produce a common spec. The result is not going to be the same as either of
the input specs, it is going to be a third spec.

So now Gopple and Aggle will both be supporting at least two different Web
Service protocols and clients might support one, two or three of them. This
can't happen in the application protocol space because the network effects
and the fact that people can only use one client place heavy and early
pressure on convergence. But in the Web Services space the cost of
supporting multiple protocols is much lower and the convergence pressures
are much less. Witness the fact that none of the implementations of what
purports to be a single frame relay based payment protocol actually
inter-operate.

I have proposed sophisitcated proposals in the past but really what we need
for the purposes of HTTP/2.0 is much less.



On Wed, Nov 14, 2012 at 7:21 AM, Eliot Lear <lear@cisco.com> wrote:

>  Adrian,
>
> My question is how important is it to make use of different transport
> protocols?  I'm asking because there are at least three approaches that we
> can take to address DNS:
>
> 1.  SRV.  SRV is just fine at providing indirection for host and port, but
> not for protocol, and not in such a pretty way when a port number is
> specified.  The cost is typically one query per host, which can SOMETIMES
> be included in additional information, when the zone is the same, and when
> the client considers additional information.
> 2.  NAPTR combined with SRV.  This provides an additional level of
> indirection to allow the choice of protocol.  SIP uses this.  The cost is
> two fold: an additional query plus some additional complexity in terms of
> processing NAPTR.  It also would prove challenging to handle the case where
> different HTTP servers are running on the same host.
> 3.  An as-of-yet undefined record that describes what services are running
> over what protocols on a host.  Think of it as the old WKS record on
> steroids.  I've actually spec'd out the record and written some code for
> bind to test this idea, but it has its own set of costs: the first – and
> biggest – is that it scales linearly with the number of services that are
> to be advertised for a given host.  Put another way: you could just see the
> advice in an applicability statement "don't use me unless you really have
> to."
>
> One other note about SRV:
>
> Use of SRV of any form with regard to TLS would require a substantial
> change in how we clients validate hostnames.  I tell you from personal
> experience that having a new SAN "Other" type is *not* an easy thing to
> ask of CAs.
>
> Comments please?
>
> Eliot
>
>
>
>
> On 11/14/12 9:05 AM, Adrien W. de Croy wrote:
>
>
> IMO it's a real shame that the designers of the SRV record decided to code
> the transport protocol into the record name, rather than the record data.
>
> It means the client must pre-suppose what the transport protocol must be
> before doing the lookup, whereas if the transport were in the record, it
> would become server-driven, and extensible, e.g. add tls-over-tcp to
> indicate that the server is available over tls on tcp.
>
> Then you'd just look up something like _service.name and get back
> everything you needed to make a connection, e.g. the server, transport and
> sub-channel (e.g. port number or whatever describes the sub-channel for the
> transport).
>
> Adrien
>
> ------ Original Message ------
> From: "Eliot Lear" <lear@cisco.com> <lear@cisco.com>
> To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.orgGroup>
> <ietf-http-wg@w3.org> <ietf-http-wg@w3.org>
> Sent: 14/11/2012 4:07:18 a.m.
> Subject: on DNS records
>
> As I promised last week, I've substantially developed a draft (and some
> code) to look more closely at whether a DNS record can be helpful.  Before
> I get it out there, I wanted to check goals.  The situation is this: there
> is a 2.0-enabled client and it must determine whether or not the other end
> can speak 2.0.  Gabriel and Willy have already shown us that it can be done
> INSIDE the protocol at the expense of one roundtrip, but at the risk of a
> proxy doing the wrong thing (a classic case being that it allows an
> Upgrade: header but then barfs all over the upgrade).  So let's state our
> goals:
>
> 1.  Keep latency down.
>
>    - First, is this a reasonable goal?
>    - Can it reasonably be done better than what Willy & Gabriel have laid
>    out?
>
> 2.  Transport Protocol Discovery
>
>    - Some have suggested that it would be useful to do HTTP over UDP or
>    SCTP.  Is that something that is a reasonable goal?
>
> 3.  Handle the case where multiple instances of the same application
> protocol reside on the same host, but on different ports.
>
>    - Is this a reasonable goal?
>
> 4.  No new URI schema
>
>    - Address the 'side of the bus' problem.
>    - Is this a reasonable goal?
>
>
> Does this about cover it?  I claim we can solve all four, but not easily
> with SRV.
>
> Eliot
>
>
>


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