IETF Logo Mail Archive

Re: Transport-independent naming of services

Marcos Sanz/Denic <sanz@denic.de> Sun, 13 July 2003 14:38 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25810 for <dnsext-archive@lists.ietf.org>; Sun, 13 Jul 2003 10:38:17 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.14) id 19bhqJ-000C9Y-A2 for namedroppers-data@psg.com; Sun, 13 Jul 2003 14:28:47 +0000
Received: from [194.246.96.22] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.14) id 19bhqG-000C9L-LV for namedroppers@ops.ietf.org; Sun, 13 Jul 2003 14:28:44 +0000
Received: from w4.denic.de ([194.246.96.15]) by smtp.denic.de with esmtp id 19bhqF-0001Cf-00; Sun, 13 Jul 2003 16:28:43 +0200
In-Reply-To: <87u19sgj11.fsf@deneb.enyo.de>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: namedroppers@ops.ietf.org
Subject: Re: Transport-independent naming of services
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003
From: Marcos Sanz/Denic <sanz@denic.de>
Message-ID: <OFF3415369.19D73DA4-ONC1256D62.004F12BF-C1256D62.004F4290@denic.de>
Date: Sun, 13 Jul 2003 16:28:34 +0200
X-MIMETrack: Serialize by Router on notes/Denic(601CF1HF55 | May 13, 2003) at 13.07.2003 16:28:43, Serialize complete at 13.07.2003 16:28:43
Content-Type: multipart/alternative; boundary="=_alternative 004F4085C1256D62_="
X-Spam-Status: No, hits=-18.4 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

On 12.07.2003 12:02 Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> 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?

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

Best regards,
Marcos Sanz
DENIC eG

v2.23.0 | Report a Bug | By Email