Re: [newprep] wg/newprep project: clarification asked

JFC Morfin <jefsey@jefsey.com> Wed, 02 June 2010 20:27 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: newprep@core3.amsl.com
Delivered-To: newprep@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1669528C127 for <newprep@core3.amsl.com>; Wed, 2 Jun 2010 13:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.018
X-Spam-Level: *
X-Spam-Status: No, score=1.018 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5iK9-iWlNYt for <newprep@core3.amsl.com>; Wed, 2 Jun 2010 13:27:11 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 018493A6A43 for <newprep@ietf.org>; Wed, 2 Jun 2010 13:27:10 -0700 (PDT)
Received: from 94.87-225-89.dsl.completel.net ([89.225.87.94]:51337 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1OJuWe-0003BD-4z; Wed, 02 Jun 2010 13:26:56 -0700
Message-Id: <7.0.1.0.2.20100602214545.05e9b6f0@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 02 Jun 2010 22:26:57 +0200
To: Mark Lentczner <markl@lindenlab.com>, newprep@ietf.org
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <D557134D-37E8-4264-8557-B1BF502BB7FC@lindenlab.com>
References: <E9728BD9-05DE-485B-B2DB-7F3D440B49E6@lindenlab.com> <7.0.1.0.2.20100519230359.05dfd258@jefsey.com> <F6EBD01F-868D-48AD-A867-D0F021DC011A@lindenlab.com> <7.0.1.0.2.20100602015956.05ef91a8@jefsey.com> <D557134D-37E8-4264-8557-B1BF502BB7FC@lindenlab.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: gerard lang <gerard.lang@insee.fr>
Subject: Re: [newprep] wg/newprep project: clarification asked
X-BeenThere: newprep@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Stringprep after IDNA2008 <newprep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/newprep>, <mailto:newprep-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/newprep>
List-Post: <mailto:newprep@ietf.org>
List-Help: <mailto:newprep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/newprep>, <mailto:newprep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2010 20:27:12 -0000

At 16:10 02/06/2010, Mark Lentczner wrote:
>On Jun 1, 2010, at 5:09 PM, jefsey wrote:
> > This is not the documented aim.
>Perhaps I misunderstood, but it seemed that after the phrase "My 
>question is therefore:", you listed a statement of a goal, and asked 
>specifically if it was a goal of "newprep possible participants". I 
>thought it was your aim to ask if I shared that as an "immediate or 
>ultimate" goal, and I answered "no".

Dear Mark,

I just reacted to what you said: " This is not my goal for a newprep 
WG: It is too broad in aims, and unrealistic that a single method 
would serve all protocols and applications."

1) I asked the goal of the participants. You say "no" and this is OK with me.

2) I reacted to "for a newprep WG" and to your "too broad in aims and 
unrealistic". The reason why is I am strongly suggested by the IESG 
to consider a BOF on the transition to post-IDNA2008 Internet, in 
following RFC 5434. I therefore carefully read that RFC on the best 
way to prepare a BOF and prepare a WG.

It is very well made. So I try to learn from it:

- first I try to make sure that what I have in mind is not already 
engaged by a better team. For example NEWPREP.

- second, I do not try to discuss possible solutions, complexity, 
etc. just to list and illustrate needs towards a problem statement 
independent from any solution attempt.

- third, I do not position myself as an IETF engineer, but as a user. 
Please have a look at RFC 5434 Section 3, because this exactly why I 
try to do in here in order to help writing the most appropriate 
Charter: "Throughout the process of chartering new work in the IETF, 
a key issue is understanding (and finding consensus) on what the 
real, underlying problem is that the [lead user] customer, operator, 
or deployer of a technology has and that the WG needs to address. 
When a WG finishes an effort, the WG's output will only be useful if 
it actually solves a real, compelling problem faced by the actual 
user of the technology (i.e., the customer or operator).

"The best description and understanding of an actual problem usually 
comes from the [lead user], customer, operator, or deployer of a 
technology. They are the ones that most clearly understand the 
difficulties they have (that need addressing) and they are the ones 
who will have to deploy any proposed solution. Thus, it is critical 
to hear their voice when formulating the details of the problem 
statement. Moreover, when evaluating the relative merits of differing 
solution approaches, it is often helpful to go back to the underlying 
problem statement for guidance in selecting the more appropriate approach."

> > The documented aim was illustrated with the ISO 3166-4 needed 
> stringprep: the Internet exemple (Bulgarian case) is to permit an 
> IDNxTLD registration on a first come first serve basis.
>
>Do you mean that the aim you were asking about is the complex of 
>political, organizational, procedural, and technical points enmeshed 
>in your e-mail about Bulgarian TLD registration, and perhaps your 
>prior e-mails?

What you name a "complex ....prior e-mails" technically boils down to 
a adequate stringprep function.

Since ccTLDs are delegated since 1978 as per ISO 3166-1 ASCII list, 
it is reasonable to think they could/should be delegated according 
its discussed ISO 3166-4 (named IDN3166 by ICANN) in using a 
"Unigraph" table based on an "ISOprep" function. In such a case it is 
reasonable to suggest that the support of such an "ISOprep" function 
could be discussed by WG/NEWPREP.

However, if such an ISOprep function is a possibility, I thought it 
was premature in the Problem Definition and Charter finalization 
processes, to make it an objective. This is because the debate may 
lead to identify other candidates for that function, or a different 
direction for post-IDNA2008 stringprep support.

Best.
jfc