Subject: Re: DNS SRV question

From: Jeffrey Altman <[email-masked]>
Date: Wed, 27 Oct 99 20:32:38 EDT

> (Jeffrey, if you need a secure telnet on a different port, and are
> hacking your client and server anyway, use a locally assigned port
> number and run the service there.  Don't screw things up with
> a SRV record because you have one broken telnet client program.)

John, what good does hacking the port do?  I can't force Windows
machines to have local services files that use the redirected port and
I don't want the redirected port to be used on all hosts.  Only on
those hosts for which the broken client(s) are used.  This is the
perfect example of when a DNS SRV record SHOULD be used.  With DNS SRV
I don't hack the client or the server.

FYI:

C-Kermit 7.0 will support the following command

  SET TCP DNS-SERVICE-RECORDS { ON, OFF }

When set to ON, a DNS SRV query will be performed using the "service" 
string provided on the 

  OPEN HOST <host> [<service> [<protocol>]]

command line.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: John Gilmore <[email-masked]>
Date: Thu, 28 Oct 1999 12:06:56 -0700

Phillip Hallam-Baker said:
> One of the longstanding projects of the Web group has been HTTP-NG which
> has had various incarnations, some of which have been binary protocols.
> 
> Now imagine that we would want to deploy HTTP-NG. As a practical matter
> legacy clients have to be supported and so the URLs will have to use the
> HTTP:// prefix. We could specify HTTPNG as a prefix but that would mean
> maintaing two separate sets of content.

You mean like http:// and ftp://?  What's the point of having a
protocol specifier in the URL if you can't add a new one when you make
a new protocol?

I do see that if you're serving up the same content with a new
protocol, having http://... continue to work to access it from old
clients that don't know the new protocol is valuable.  This new
protocol sounds more like a revision of HTTP than a new protocol,
though.  You might have to introduce it in backward-compatible steps:
create HTTP version X that provides a way to parse and skip binary
data, deploy that widely in servers, then create protocol version Y
that uses the binary data to make the protocol more efficient.

> The HTTPNG protocol is therefore likely to register itself with the
> O/S as the HTTP protocol and perform a protocol something like
> 'do an SRV lookup for _HTTPNG._TCP, if that fails cache the information
> and fall back to standard HTTP.'

A similar approach that doesn't require DNS SRV records would be 'open
a connection to the HTTPNG port, if that fails cache the information
and fall back to using the old HTTP protocol and port'.

	John