RE: Where we stand and where we are going

Nicolas Popp <nico@realnames.com> Thu, 27 June 2002 18:50 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00D04OCB5L@eListX.com> (original mail from nico@realnames.com); Thu, 27 Jun 2002 14:50:35 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00D01OCA5I@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 14:50:34 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYD00D01OCA5G@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Thu, 27 Jun 2002 14:50:34 -0400 (EDT)
Received: from friendly.realnames.com (friendly.realnames.com [63.251.238.102]) by eListX.com (PMDF V6.0-025 #44856) with SMTP id <0GYD003E9OC9AM@eListX.com> for ietf-irnss@lists.elistx.com; Thu, 27 Jun 2002 14:50:34 -0400 (EDT)
Received: (qmail 14287 invoked by uid 104); Thu, 27 Jun 2002 18:50:19 +0000
Received: from nico@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.851521 secs); Thu, 27 Jun 2002 18:50:19 +0000
Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; Thu, 27 Jun 2002 18:50:18 +0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2590]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <940577@heaven.internal.realnames.com> for <leslie@thinkingcat.com>; Thu, 27 Jun 2002 11:44:07 +0000 (AM)
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id <KHQCM6WF>; Thu, 27 Jun 2002 11:50:10 -0700
Date: Thu, 27 Jun 2002 11:44:51 -0700
From: Nicolas Popp <nico@realnames.com>
Subject: RE: Where we stand and where we are going
To: 'Leslie Daigle' <leslie@thinkingcat.com>, John C Klensin <klensin@jck.com>
Cc: Michael Mealling <michael@neonym.net>, ietf-irnss@lists.elistx.com
Message-id: <7FC3066C236FD511BC5900508BAC86FED21D31@trestles.internal.realnames.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>

I strongly agree with Leslie on that one (it reminds me of the WAP binary
XML debate).
That being said, I am not even sure why we are focusing on the transport at
this stage.

Maybe it is just me, but my recollection from the Mineapolis meeting is that
we still have substantial conceptual issues for which I have not seen clear
definition or consensus. 
>From the top of my head: what is the final list for layer 2 facets (e.g.
what about service-type, serviceID and network-location? String matching
rules: how fuzzy does it need to be? Do we need to standardize string
matching rules within a cultural context (e.g. geography & language) or is
it up to the service? should the match fuzzines be specified in the query
(distance function)? How? Should the output be DNS names or URIs?...

I still don't have a good mental picture of what needs to be passed back and
forth, so it hard to focus on XML versus binary encoding. Can we see the
latest work (even in its draft form) first & soon? 

Thanks.

-Nico

-----Original Message-----
From: Leslie Daigle [mailto:leslie@thinkingcat.com]
Sent: Wednesday, June 26, 2002 12:28 PM
To: John C Klensin
Cc: Michael Mealling; ietf-irnss@lists.elistx.com
Subject: Re: Where we stand and where we are going



Howdy,

John C Klensin wrote:
>  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.

Actually, I'm not ready to agree with this (not saying I won't
get there -- saying I'm not there yet).  XML in toto is overkill,
but we're not talking about that; we're trying to define a
constrained service and leverage XML as an expression for it.

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