Subject: RE: Issues with 2052bis (SRV)

From: Jeffrey Altman <[email-masked]>
Date: Fri, 27 Aug 99 14:27:54 EDT

I believe I posted a long response to Robert's e-mail back in July
when it was originally sent.

The most significant of which is Item #3.  As I have stated before,
putting in text that states "SRV records should not be used unless a
protocol specification says to use it" is ridiculous.  It will force
any application developer that wants to use SRV records to submit an
Internet-Draft to describe how to use SRV records with that
application.  I don't the Applications Area Director's want the extra
work.  Nor do I believe it will prevent anyone from putting SRV
records into their DNS if they see a benefit.  

Instead there should be a boilerplate mechansim in place describing
how the existing services namespace is implemented using SRV records
instead of locally distributed files.  At least that way SRV records
have a chance to be used consistently.

    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: Thomas Narten <[email-masked]>
Date: Fri, 27 Aug 1999 16:55:45 -0400

Jeffrey Altman <[email-masked]> writes:

> application.  I don't the Applications Area Director's want the
> extra work.

I don't think the App's ADs consider this a huge burden on
them. Indeed, they requested the SHOULD NOT. The purpose of that
requirement is to get consensus within the community that clients,
when interacting with a server using a specific protocol, should be
using SRV. If they should, this implies that the providers of that
service need to put SRV records in the DNS. Documenting this would
seem to be a wise thing, otherwise no one will know to do it.

If an implementor comes along and decides that from now on, their
browser (or pick any existing widely deployed protocol) will user SRV
records rather than querying for A records, but none of the deployed
server's know about that, well, at best we'll get a lot of useless
traffic on the network that slows down performance. At worst, things
could get ugly. Hence the need for a document that explains how to
handle transition issues, etc.

For someone doing a new protocol, adding a few paragraphs about SRV
seems pretty easy relative to documenting the rest of the protocol.

> Nor do I believe it will prevent anyone from putting SRV

They can do this, but that doesn't mean we should allow them to do so
and say they are following "standard" behavior. And when inappropriate
use of SRV causes problems, folks can point to the spec and say "you
shouldn't be doing that".

Thomas