[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with 2052bis (SRV)



Jeffrey Altman <jaltman@watsun.cc.columbia.edu> writes:

> 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.

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
> records into their DNS if they see a benefit.

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