Subject: Transport-independent naming of services

From: Florian Weimer <[email-masked]>
Date: Sat, 12 Jul 2003 12:02:18 +0200

A distributed application APP can use various transports (e.g., TCP and
SCTP, or, at a higher level, HTTP, HTTPS, WebDAV, SFTP and FTP) to
access remote resources.  Remote resources are identified by a
domain name.

Can existing DNS RRs be used to describe this scenario in a meaningful
way?  Registering a new SRV service doesn't help because the SRV RR
data does not indicate the transport service (just its port number,
which is not enough data).  The only approach seems to be to register
SRV service names "APP_http", "APP_https" etc. and to query for all
services the application might support, but this is not very elegant.

Any suggestions?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Tue, 15 Jul 2003 13:18:55 +0200

Marcos Sanz/Denic <[email-masked]> writes:

> A "straightforward" use of NAPTR records (NAPSTR) could be the thing you 
> are looking for:
> http://www.ietf.org/internet-drafts/draft-daigle-napstr-02.txt

Thanks.  This proposal adds the an indirection that straight usage of
SRV RRs lacks, and it appears to be sufficient.

I still have to check if the protocol ballast is acceptable, though.