Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 16 July 2012 16:59 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC311E8157 for <ima@ietfa.amsl.com>; Mon, 16 Jul 2012 09:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.017
X-Spam-Level:
X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG7g6bVZcf8J for <ima@ietfa.amsl.com>; Mon, 16 Jul 2012 09:59:18 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3032211E8158 for <ima@ietf.org>; Mon, 16 Jul 2012 09:59:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342458002; d=isode.com; s=selector; i=@isode.com; bh=9oUAiz+M6mhQ4KOTMeNQA2w62aQv2N19bmDifqrpSrM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=liiHZGOdztUUQikdTVhWR6+VVIX44lHqTsGrmZcvhF6x5OAYNYMrq36CJ2aEAkLgDg06eQ fHJeEhG2rhs3pP0Aq/FP/MqbIq19yAacOchcCz4TJQxczIYYB+DP1MMj7uLoH6kDTro8Aj IAwc9vyXaQZuSIcR/vQOQsrY2yNY4Sc=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <UARIkQAdioQs@statler.isode.com>; Mon, 16 Jul 2012 18:00:02 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <5004488E.4020307@isode.com>
Date: Mon, 16 Jul 2012 17:59:58 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: John C Klensin <klensin@jck.com>
References: <A2474402D72A7B12E41E2D0F@[192.168.1.128]>
In-Reply-To: <A2474402D72A7B12E41E2D0F@[192.168.1.128]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: EAI WG <ima@ietf.org>
Subject: Re: [EAI] POP (draft-ietf-eai-rfc5721bis-05), SASLPrep, and Stringprep
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 16:59:19 -0000

On 15/07/2012 16:49, John C Klensin wrote:
> Hi.
Hi John,

> Just checking that what this document says is what everyone
> wants...
>
> Section 3.2 of draft-ietf-eai-rfc5721bis-05 is very heavily
> dependent on SASLprep [RFC4013], including MUST requirements.
> SASLPrep is, in turn, dependent on Stringprep, which is tied to
> Unicode 3.2.   Questions:
>
> (1) Could someone who is closer to SASLPrep and the PRECIS work
> tell us whether they are comfortable with this or whether the
> text in this spec should be modified somewhat?  If any changes
> are likely to be completely compatible, I don't think there is a
> problem.  However,...
>
> (2) If changes are needed, should Section 3.2 be rewritten to
> explicitly allow conformance with the successors of 4013 as an
> alternative?  I think that would require only a few changes of
> wording.
But that would require pointing to a document with unclear date of 
completion...
> (3) Or are we better off just leaving this alone and monitoring
> any 4013bis efforts to make sure they contain provisions to
> explicitly update our spec when the time comes?
>
> These are just questions --if the WG is ok with things as they
> are, so am I.  But I can see this causing questions during IETF
> Last Call and want to be sure we have considered the issue.

I think (3) is the best way forward, but just my 2 pence.