Re: Where we stand and where we are going

John C Klensin <> Wed, 26 June 2002 15:47 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from; Wed, 26 Jun 2002 11:47:47 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Wed, 26 Jun 2002 11:47:46 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Wed, 26 Jun 2002 11:47:46 -0400 (EDT)
Received: from ( []) by (PMDF V6.0-025 #44856) with ESMTP id <> for; Wed, 26 Jun 2002 11:47:46 -0400 (EDT)
Received: from ([] helo=localhost) by with esmtp (Exim 3.35 #1) id 17NF0r-000Lqp-00; Wed, 26 Jun 2002 15:47:23 +0000
Date: Wed, 26 Jun 2002 11:47:19 -0400
From: John C Klensin <>
Subject: Re: Where we stand and where we are going
In-reply-to: <>
To: Michael Mealling <>
Message-id: <1448782.1025092039@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.2.1 (Win32)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <>
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>

--On Wednesday, 26 June, 2002 09:41 -0400 Michael Mealling
<> wrote:

>> I am working on getting another version of "dns-search" out
>> before next Monday's deadline.  While it contains a number of
>> clarifications and updates, the important material is in
>> several new (or almost-new) sections.  I will circulate those
>> to this group as they are ready, in the hope of getting
>> comments before I fold them into the document or, at least, of
>> giving the rest of you some time to think about them before
>> Yokohama.
>> I have realized as I have been working on it that it presents
>> an abstract model, but perhaps too many undefined choices.
>> Would it be helpful to have drafts that identify and specify
>> implementable protocols (even if they are wrong) as a means of
>> getting comments and moving forward?  If so, we need to figure
>> out how to get those written -- I can certainly produce some
>> text for people to revise and replace, but that may not be the
>> most efficient way to move forward.
> Would the SLS document help in that regard or are you suggesting
> something different? I expect to have the SLS document revised
> by thea deadline as well. 

I think the SLS document has been one of the more concrete bits
on the table.   I have been more concerned about all of the other
bits and pieces.

>> Suggestions as to how to proceed, comments on drafts, etc.,
>> are, of  course, welcome at any time.
> My intent is that the SLS document will be upgraded to reflect
> somethings we've learned in the past few months, along with an
> update of the transport to be more 'DNS-like'. This means
> moving away from the XML chattiness and into a binary,
> UDP-friendly packet format. Is there any concensus for using
> that as a strawman protocol to bang against for concrete
> protocol-level discussions?

I can't speak for consensus, but my preference in all of this is
to follow N. Wirth to the greatest degree possible, i.e., the
goal should be "as simple as possible, but no simplier".  And I
think, in that context, that, unless the capabilities and
flexibilities of XML are needed, that we should assume that this
is infrastructure. Hence, those capabilities and flexibilities
should be assumed to be overhead, fluff, and opportunities for
profiles that kill interoperability.