RE: Who does what (Re: [idn] San Diego Meeting Notes)

"Brian W. Spolarich" <briansp@walid.com> Thu, 25 January 2001 19:58 UTC

Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07579 for <idn-archive@lists.ietf.org>; Thu, 25 Jan 2001 14:58:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LsAq-000HRf-00 for idn-data@psg.com; Thu, 25 Jan 2001 11:35:12 -0800
Received: from [152.160.20.25] (helo=admin1.corp.walid.com) by psg.com with esmtp (Exim 3.16 #1) id 14LsAp-000HNo-00 for idn@ops.ietf.org; Thu, 25 Jan 2001 11:35:11 -0800
Received: from GONZO (admin1.corp.walid.com [152.160.20.25]) by admin1.corp.walid.com (8.9.3/8.9.3) with SMTP id TAA27934; Thu, 25 Jan 2001 19:30:03 GMT
From: "Brian W. Spolarich" <briansp@walid.com>
To: Harald Alvestrand <Harald@Alvestrand.no>, Paul Hoffman / IMC <phoffman@imc.org>, James Seng/Personal <James@Seng.cc>, idn@ops.ietf.org
Subject: RE: Who does what (Re: [idn] San Diego Meeting Notes)
Date: Thu, 25 Jan 2001 14:34:02 -0500
Message-ID: <IPEMICCPDPPICMIONJIOIEHFCBAA.briansp@walid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4.3.2.7.2.20010125003230.02ba5828@127.0.0.1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

| I think this working group should be the one that reviews the proposal
| for what is loosely termed "the IDN protocol" (IDNA or something very
| like it) before sending it to IETF-wide Last Call.

  What is the opinion of the working group on IDNA vs. IDNRA?  Paul and
Patrik have proposed two alternative ACE implementation approaches:  IDNRA
calls for an application and resolver-based approach, putting most of the
IDN work in the resolver, while IDNA calls for an application-only approach.

  One of the premises of the ACE approach is the belief that the
infrastructure will take too long to update (I'm purposefully simplifying
here) and the IDN handling needs to happen at the edge of the network.

  As I read IDNA, the authors believe that the bulk of IDN processing cannot
happen in the resolver (or perhaps immediately in front of the resolver) and
must happen solely in the application.  If that is so, is it reasonable to
assume that a significant percentage of application will be updated very
quickly?  Certainly there are market pressures that might make this so, but
I'm not convinced.  The authors do not state in IDNA why they believe IDNA
is a better approach than IDNRA, which would be a helpful clarification of
the draft.

  I briefly discussed this with Paul at IETF49 but we didn't have an
opportunity to discuss this in detail (except that we disagreed :-).

  It seems to me that in most cases, particularly with most of the
relatively simple applications, as long as the application "stays out of the
way" and passes the IDN intact to the resolver the IDN work can happen
completely in the resolver layer.  Some applications and protocols will have
to be reviewed and updated(and has already been discussed there will need to
be a review of the impact by the various WGs in the applications area), but
certainly by all means not every application.

  -bws