From y.oiwa@aist.go.jp Mon Feb 3 16:18:38 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDD81A02B8 for ; Mon, 3 Feb 2014 16:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrxRzV6p5zWO for ; Mon, 3 Feb 2014 16:18:36 -0800 (PST) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A61A026A for ; Mon, 3 Feb 2014 16:18:35 -0800 (PST) Received: from mail-ve0-f172.google.com ([209.85.128.172]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUvAx2+AXXNjMXy1K0eLsLX8yzlWb9kcE@postini.com; Mon, 03 Feb 2014 16:18:36 PST Received: by mail-ve0-f172.google.com with SMTP id c14so5562541vea.3 for ; Mon, 03 Feb 2014 16:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fqwaK3F6W1EAaOeN7KfsH1QiM0CJliyYpJuPM/soF8g=; b=b6kB6n/x17YQFm7MD49ROnW13yXSm01sO7c2M8Rel8m1uq4q60vy6UdUaLLUPpoNfa lge7vbhg3cph4puQlxOhPee421hDF966gp/h0GQn235E+3rze26n7QJMR0LYdVo9L8qi YYaIYZV8SharrXmrCg2p8rTnSEL3j62O3xGQo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fqwaK3F6W1EAaOeN7KfsH1QiM0CJliyYpJuPM/soF8g=; b=mbB7mt8FUH71wMbSQNP6JTgcpETimOIibF6h+qYsONKc3uvV4BUajPiYMFY9kYdiFb mlvmauy1hYlNaf6A6J+pkvjVnw/57ejjDXt3WiqQo8NtNtFLNBAaDhL0yQ3wjD3KQzaC 7sw2c0BdDdyWONs1MO1+wCPCGJssZD+q0P7cAKWSSpnlLvIbLVbtR6D7P/uZl4XSQhPz VzkTjls0hTpuoziO4YoRaJzac3nJIZK8O4Z6soxsUY0arwtaQWOaSMKulkeLS6DqRG6R pyrEsl7bZUGg7t1x6dZ79B+ab5r4ZOPj4jCnpV1+W75GGzV3oBVzPsGGA46I0advS74h drHg== X-Gm-Message-State: ALoCoQkdxI7p6BOt+Fr5anSYRx5q7ufm+9DXi0n1KDPZq4N6GzcsSrASH7gXxAN6u2kKqO3IwsIOi8qA7SEj5y4IHeajGjuz5OtDU5uMcDLu9ZM6P68g0S3/sGpq9gaa8nMGsPRrIJ8WnU8GrpFjBviZT8wFjiunyw== X-Received: by 10.52.117.115 with SMTP id kd19mr25494576vdb.15.1391473115199; Mon, 03 Feb 2014 16:18:35 -0800 (PST) X-Received: by 10.52.117.115 with SMTP id kd19mr25494568vdb.15.1391473115098; Mon, 03 Feb 2014 16:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Mon, 3 Feb 2014 16:18:14 -0800 (PST) In-Reply-To: <52EFCA1F.5070609@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> From: Yutaka OIWA Date: Tue, 4 Feb 2014 09:18:14 +0900 Message-ID: To: Julian Reschke , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , Matthew Lepinski , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 00:18:38 -0000 Dear Julian and Peter (added), how about the things ongoing about handling of HTTP-AUTH normalization in context of PRECIS? I proposed general-purpose HTTP-AUTH normalization profile to PRECIS WG (just because I need it :-), and they considered merging it with new SASLPREPbis. My current draft is http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . SASLPREPbis is in WG pool as http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . I am awaiting actions for whether the merging will actually happen or not. In my understanding, removing of SASL-dependent natures (e.g. that in Username grammer) from current saslprepbis is not going forward yet, and current SASLPREPbis is, at least personally, not applicable for any HTTP auth schemes except SASL-backed ones. For clarify, SASLPREPbis is really good, and the differences are not large but critical. I think there is several possible directions for us to go: 1) Go merging: push forward to make saslprepbis a general-purpose precis profile by separating still-remaining SASL-only features. IMO, in this case we may need two separate application notes documents for SASL and HTTP-AUTH. 2) Go separate: discuss HTTPAUTH in context of PRECIS separately from SASLPREP. I believe that my draft will give us a good starting point, as my best effort. 3) for Julian, one possible best current cheating, if you can't wait PRECIS WG, might be just specify NFC as a canonical form. Both SASLPREP and HTTPAUTHprep (and many other PRECIS profiles) are NFC based, so it will not likely harm future development of proper PRECIS-based "preparation" (including normalization). Also, I would be happy if Julian (as talked in Vancouver) and other people in HTTPAUTH WG and PRECIS WG could give us a feedback on my proposal from the both WG's points of view. 2014-02-04 Julian Reschke : > On 2013-10-05 11:01, Julian Reschke wrote: >> >> On 2013-09-12 12:35, Julian Reschke wrote: >>> >>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>> >>>> Draft minutes for the HTTP-AUTH session have been posted. >>>> >>>> They can be found at: >>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>> >>>> If you notice any omissions or other errors in the minutes, please let >>>> us know. >>>> ... >>> >>> >>> OK, the minutes mention: >>> >>> "Unicode Normalization : Getting from what is typed in to Unicode code >>> points will require discussion" >>> >>> So how do we proceed from here? Any concrete proposals for what to say? >> >> >> It seems we don't know what to say then, right? >> >> How about: "Beware that differing Unicode normalization forms can cause >> interoperability problems. See [http://unicode.org/reports/tr15/]."? >> >> >> Best regards, Julian > > > So, does anybody have a good plan how to approach the normalization problem? > > Otherwise we'll just have to state that there are dragons out there, and > that we don't know the solution... > > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nico@cryptonector.com Mon Feb 3 16:32:15 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA021A026A; Mon, 3 Feb 2014 16:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNGw2-T88cW2; Mon, 3 Feb 2014 16:32:14 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF181A0264; Mon, 3 Feb 2014 16:32:14 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id D42612005D105; Mon, 3 Feb 2014 16:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=h1e6PNoE2SLLI9viwhHE 7XN1BGo=; b=otROKLRJQ3+3Jdwbp0XUNAjPOehxSwGSSb/J+Txik50LmReibDqR nJt4uZkXxBm7mHyITGbt+OVCXz90CjApxDj2uOCWU0kfHumndDH/puLxik6170VL 9aqjuwnNjXRmQ/1X+fmBdmqDjvV+3ogd4aRtbtrAY7WYdvgwtLSlUxI= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 584452005D107; Mon, 3 Feb 2014 16:32:13 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so3467181wes.12 for ; Mon, 03 Feb 2014 16:32:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXFMVFTPhrMNZyrd/wXhkUVkUj3p0HAcNLsl7tssS4c=; b=OsKGQy1v7j0iz//ir9ijyzVqxmVBxBHOX7b0jqZacYGyPNJSBpa52tcdS5qGMy+3wW BE3HKPDzkTe8iIWeqdUP56rXIN6F68rnkOh8Eu2WYW4Pm3uAPE7ZFA7ac3i28spGImso 23X+dIK/o7zgYYI+Q/TqiQXVWB1cBmkSpsIi5Y55AIi/r1Q0/7SyfieD/4rrb0Lpoaay a4zCu4VPiJFguGfUVLI8D8WqF4Gy7wFNnrsVkZT6Gz0ZFGbK4vFylugGXdCi1cviCcFD u/ARhMgcSoLVI0OmhfevLDpOqwBGUytShIjLf1c9siBZ9nFDDw7UCP/4mQVtc+AaQOfW SlPQ== MIME-Version: 1.0 X-Received: by 10.194.86.200 with SMTP id r8mr3625083wjz.49.1391473931578; Mon, 03 Feb 2014 16:32:11 -0800 (PST) Received: by 10.227.198.69 with HTTP; Mon, 3 Feb 2014 16:32:11 -0800 (PST) In-Reply-To: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> Date: Mon, 3 Feb 2014 18:32:11 -0600 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 00:32:15 -0000 +1 to using/referencing PRECIS, but first make sure that it doesn't continue to say anything inappropriate about case folding. Nico -- From stpeter@stpeter.im Mon Feb 3 18:31:57 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1D1A0251; Mon, 3 Feb 2014 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jguE6dz2qoEk; Mon, 3 Feb 2014 18:31:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB391A01B6; Mon, 3 Feb 2014 18:31:56 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 320C34010C; Mon, 3 Feb 2014 19:31:55 -0700 (MST) Message-ID: <52F0511A.5010200@stpeter.im> Date: Mon, 03 Feb 2014 19:31:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams , Yutaka OIWA References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:31:57 -0000 On 2/3/14, 5:32 PM, Nico Williams wrote: > +1 to using/referencing PRECIS, but first make sure that it doesn't > continue to say anything inappropriate about case folding. Nico, as you might recall, with your help we revised the saslprepbis document to remove the inappropriate text about case folding. :-) Also, after talking with Yutaka and Julian at the last IETF meeting, personally I concluded that we do indeed need a separate PRECIS profile for HTTPAUTH (not merge it into saslprepbis). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Feb 3 18:33:58 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCB1A0257; Mon, 3 Feb 2014 18:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRv_RcLeShiM; Mon, 3 Feb 2014 18:33:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B81FE1A0251; Mon, 3 Feb 2014 18:33:55 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F19CC4010C; Mon, 3 Feb 2014 19:33:49 -0700 (MST) Message-ID: <52F0518C.9060506@stpeter.im> Date: Mon, 03 Feb 2014 19:33:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yutaka OIWA , Julian Reschke References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Matthew Lepinski , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:33:58 -0000 Yes, I think it is best to define a separate profile for HTTPAUTH (based on various conversations at the last IETF meeting). I will try to review your document again very soon. Peter On 2/3/14, 5:18 PM, Yutaka OIWA wrote: > Dear Julian and Peter (added), > > how about the things ongoing about handling of > HTTP-AUTH normalization in context of PRECIS? > > I proposed general-purpose HTTP-AUTH normalization > profile to PRECIS WG (just because I need it :-), > and they considered merging it with new SASLPREPbis. > My current draft is > http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . > SASLPREPbis is in WG pool as > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . > > I am awaiting actions for whether the merging > will actually happen or not. > In my understanding, removing of SASL-dependent > natures (e.g. that in Username grammer) from current > saslprepbis is not going forward yet, and current > SASLPREPbis is, at least personally, not applicable > for any HTTP auth schemes except SASL-backed ones. > For clarify, SASLPREPbis is really good, and the differences > are not large but critical. > > I think there is several possible directions for us to go: > > 1) Go merging: push forward to make saslprepbis a > general-purpose precis profile by separating > still-remaining SASL-only features. > IMO, in this case we may need two separate > application notes documents for SASL and HTTP-AUTH. > > 2) Go separate: discuss HTTPAUTH in context of > PRECIS separately from SASLPREP. > I believe that my draft will give us a good starting point, > as my best effort. > > 3) for Julian, one possible best current cheating, if you > can't wait PRECIS WG, might be just specify NFC as a > canonical form. Both SASLPREP and HTTPAUTHprep > (and many other PRECIS profiles) are NFC based, > so it will not likely harm future development of proper > PRECIS-based "preparation" (including normalization). > > Also, I would be happy if Julian (as talked in Vancouver) > and other people in HTTPAUTH WG and PRECIS WG > could give us a feedback on my proposal from the > both WG's points of view. > > 2014-02-04 Julian Reschke : >> On 2013-10-05 11:01, Julian Reschke wrote: >>> >>> On 2013-09-12 12:35, Julian Reschke wrote: >>>> >>>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>>> >>>>> Draft minutes for the HTTP-AUTH session have been posted. >>>>> >>>>> They can be found at: >>>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>>> >>>>> If you notice any omissions or other errors in the minutes, please let >>>>> us know. >>>>> ... >>>> >>>> >>>> OK, the minutes mention: >>>> >>>> "Unicode Normalization : Getting from what is typed in to Unicode code >>>> points will require discussion" >>>> >>>> So how do we proceed from here? Any concrete proposals for what to say? >>> >>> >>> It seems we don't know what to say then, right? >>> >>> How about: "Beware that differing Unicode normalization forms can cause >>> interoperability problems. See [http://unicode.org/reports/tr15/]."? >>> >>> >>> Best regards, Julian >> >> >> So, does anybody have a good plan how to approach the normalization problem? >> >> Otherwise we'll just have to state that there are dragons out there, and >> that we don't know the solution... >> >> >> Best regards, Julian >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > > -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Tue Feb 4 14:01:08 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5F1A015A for ; Tue, 4 Feb 2014 14:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM-CzgJYp8sp for ; Tue, 4 Feb 2014 14:01:05 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A93401A0169 for ; Tue, 4 Feb 2014 14:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1391551261; d=isode.com; s=selector; i=@isode.com; bh=y30J3y8oOgk90tojh0p8zmzPfIYTjaXs3RXlwu3TXHk=; 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=BRPxX4I9CLpF8KB3N5HnO+pgjAp1wLm6Csi9R+rIbdb7RBkKwT8+36a+TrtObM0nwM86Br i9lKw2xJVSRu6xiFhgMf28aM3H44RhWix6RYMzIsz86QwSHmKiVtRPUjjoPyNyo2Sa59Zv pBSDuw2ODX8F0dHqvSqym90aKOa3CSQ=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Feb 2014 22:01:01 +0000 Message-ID: <52F1631C.3050908@isode.com> Date: Tue, 04 Feb 2014 22:01:00 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Peter Saint-Andre , precis@ietf.org References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> In-Reply-To: <52E2714A.3030208@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 22:01:08 -0000 Hi Peter, On 24/01/2014 13:57, Peter Saint-Andre wrote: > On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: [...] >> We changed the definition of local case mapping and > That is better, thanks. If I understand your text correctly, we might > want to say very clearly that a PRECIS profile needs to either use > case mapping or use local case mapping, but that it can't use both > (i.e., local case mapping is an alternative to case mapping, not > something additional on top of case mapping, since the local case > mapping rule will apply normal case mapping if there is no > locale-specific mapping). If that is the way we want to go, then this contradicts section 5 of draft-ietf-precis-framework: 2. Optionally, additional mappings such as those as specified in [I-D.ietf-precis-mappings]: 1. Delimiter mapping 2. Special mapping 3. Local case mapping 3. Non-local case mapping I.e. draft-ietf-precis-framework needs to be updated to make this clear as well. From stpeter@stpeter.im Tue Feb 4 16:03:18 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8158E1A016C for ; Tue, 4 Feb 2014 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji3qPdKUsD1v for ; Tue, 4 Feb 2014 16:03:16 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A74891A016A for ; Tue, 4 Feb 2014 16:03:16 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E9DF74032A; Tue, 4 Feb 2014 17:03:15 -0700 (MST) Message-ID: <52F17FC2.3090103@stpeter.im> Date: Tue, 04 Feb 2014 17:03:14 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexey Melnikov , precis@ietf.org References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> In-Reply-To: <52F1631C.3050908@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 00:03:18 -0000 On 2/4/14, 3:01 PM, Alexey Melnikov wrote: > Hi Peter, > > On 24/01/2014 13:57, Peter Saint-Andre wrote: >> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: > [...] >>> We changed the definition of local case mapping and >> That is better, thanks. If I understand your text correctly, we might >> want to say very clearly that a PRECIS profile needs to either use >> case mapping or use local case mapping, but that it can't use both >> (i.e., local case mapping is an alternative to case mapping, not >> something additional on top of case mapping, since the local case >> mapping rule will apply normal case mapping if there is no >> locale-specific mapping). > If that is the way we want to go, then this contradicts section 5 of > draft-ietf-precis-framework: > > 2. Optionally, additional mappings such as those as specified in > [I-D.ietf-precis-mappings]: > 1. Delimiter mapping > 2. Special mapping > 3. Local case mapping > 3. Non-local case mapping > > > I.e. draft-ietf-precis-framework needs to be updated to make this clear > as well. Agreed. I think that the definition of "local case mapping" has changed in the latest version of the mappings document, such that (if we think the new direction is appropriate) we'd need to do this: OLD 2. Optionally, additional mappings such as those as specified in [I-D.ietf-precis-mappings]: 1. Delimiter mapping 2. Special mapping 3. Local case mapping 3. Non-local case mapping NEW 2. Optionally, additional mappings such as those as specified in [I-D.ietf-precis-mappings]: 1. Delimiter mapping 2. Special mapping 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or case mapping as described under Section 4.1.3 of this document Does that look right? Peter -- Peter Saint-Andre https://stpeter.im/ From julian.reschke@gmx.de Tue Feb 4 07:33:24 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA41A00F9 for ; Tue, 4 Feb 2014 07:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwsFr7uZ8TVs for ; Tue, 4 Feb 2014 07:33:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C31A012A for ; Tue, 4 Feb 2014 07:33:20 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVvDo-1ViDqA2hei-00X034 for ; Tue, 04 Feb 2014 16:33:18 +0100 Message-ID: <52F1083B.2020102@gmx.de> Date: Tue, 04 Feb 2014 16:33:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Saint-Andre , Yutaka OIWA References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> In-Reply-To: <52F0518C.9060506@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uhBaGZu9W+8WW3noeIVippvCmJ2qSmj40aQAvnaqJlTQNZf0had K5YYuy/MsyLUy77UB5SCB1B3wpeLVmlHEkQxbJSha+QwymFqxn4GI90SvvFdLvBK0WLj4sQ sdBkbi/zkxI81Nq967vCt09vK6PcyALwYUtTaZ0ddUXTU0QVSf7mukgXZccm5yI71LrdN3n ONf3L2iu6QHCeNLoN1J2g== X-Mailman-Approved-At: Tue, 04 Feb 2014 17:09:51 -0800 Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:33:24 -0000 On 2014-02-04 03:33, Peter Saint-Andre wrote: > Yes, I think it is best to define a separate profile for HTTPAUTH (based > on various conversations at the last IETF meeting). I will try to review > your document again very soon. > > Peter Peter: that would be awesome. That being said I fear that this is going to take some time. Alternatives for "Basic": 1) Keep the separation of the base spec (draft-ietf-httpauth-basicauth-update) from the one addressing I18N (draft-ietf-httpauth-basicauth-enc), and try to get the former out of the door as soon as possible. 2) As previously agreed upon, merge the two specs but only do some handwaving with respect to normalization for now. Best regards, Julian From derhoermi@gmx.net Tue Feb 4 17:26:19 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949331A01B2 for ; Tue, 4 Feb 2014 17:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFd530o6cGiw for ; Tue, 4 Feb 2014 17:26:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49E1A0196 for ; Tue, 4 Feb 2014 17:26:16 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.28.118]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lurin-1VAx5q043N-01082n for ; Wed, 05 Feb 2014 02:26:15 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Wed, 05 Feb 2014 02:26:16 +0100 Message-ID: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> In-Reply-To: <52F1083B.2020102@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:dvVXJV7kZQT/HBvhhik9GsM2vzDBHGxr1BMPbvSXdlNHu0uAJD8 RPf+ESa9fjWac1JYUqnPqFnl7pYID0zl7+PW3d7yBmhtosm1KVKqCq+qo0nnr5kHGbJBoUi 4PSEMrfdi+at1PMC335Dlt4eYWMaPwdM4CFoQb6bB9FcAl8c0xgemXyhwJcYoxhgI9cjsso vProO5F6bPRh6cMvAAvJw== Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 01:26:19 -0000 * Julian Reschke wrote: >Alternatives for "Basic": > >1) Keep the separation of the base spec >(draft-ietf-httpauth-basicauth-update) from the one addressing I18N >(draft-ietf-httpauth-basicauth-enc), and try to get the former out of >the door as soon as possible. > >2) As previously agreed upon, merge the two specs but only do some >handwaving with respect to normalization for now. I like 2). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From y.oiwa@aist.go.jp Wed Feb 5 01:15:15 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17281A00B1 for ; Wed, 5 Feb 2014 01:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PizIDlwZ4T0H for ; Wed, 5 Feb 2014 01:15:13 -0800 (PST) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2C71E1A00A5 for ; Wed, 5 Feb 2014 01:15:13 -0800 (PST) Received: from mail-vc0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUvIBILCtcnjjdnQMr1eqXMnwA4xaOA8C@postini.com; Wed, 05 Feb 2014 01:15:12 PST Received: by mail-vc0-f170.google.com with SMTP id hu8so79446vcb.15 for ; Wed, 05 Feb 2014 01:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ApOr162ZL8aV5qnYGIQKPiBLDr8YNwZe+KIINGGJuss=; b=acccS9KcrIIOlDxk93luhNUY+0BAwDpSI6BGSQM6byu7znkHJoc+lMXz77N45xRtWJ VIf2FXpjdxkR/o47AZpIEHyEtw8lEHoaXR18u+PuOZjV6LATq9w+mSpYLViYtzFIZ2qp JbR1OMercLG9uFonNqZIiBgoOLzwLkFk0TPgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ApOr162ZL8aV5qnYGIQKPiBLDr8YNwZe+KIINGGJuss=; b=i8hF6haRs7gBAwu8dhr6AHfQOAAgqKgMkugu2/vzkTpQH9X7xyEt4iIKLW0a69+KVB xPoSS9Pvh+wndasz7sz0H4pX97quCjfohx3DPwUg4FH/l7+QzqQszS3IflM3fuECQ6+g M9r3NehEPzIAUZL60rbibWsFqhESk9V1Dx97ivglrq4RbckwFDMDEKO5s0YFy66aDRVR ng0sPy5PsskfRP+UFoIZWCpSFJG7sIzWa4pjRuuK0ykKUs36gJ7ZKPX0Q8OZZcrWyf4S I4DzQ2z2/+EGHlbqD6CXfCxXd8KTSNdwlrpXHu8IKVDVNLduK7owbIZZIwoajwqlPvg6 VNPA== X-Gm-Message-State: ALoCoQmrlul5WiTb1mologSpHOjdkAI+Xy1YXAL+QuNVvtfk4vpXE+FECbaooZ2MLUKXKvVDhHDIhln3jM6d2VwkR2DSc6g7nSMygktA+6+7dzMlovHqXMPkduEduiyXVn+KWxiGsQQ+uACOXqwulSVa4EkljiyqDQ== X-Received: by 10.58.181.230 with SMTP id dz6mr143895vec.35.1391591711935; Wed, 05 Feb 2014 01:15:11 -0800 (PST) X-Received: by 10.58.181.230 with SMTP id dz6mr143887vec.35.1391591711818; Wed, 05 Feb 2014 01:15:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 01:14:51 -0800 (PST) In-Reply-To: <52F0518C.9060506@stpeter.im> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> From: Yutaka OIWA Date: Wed, 5 Feb 2014 18:14:51 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "http-auth@ietf.org" , Matthew Lepinski , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:15:16 -0000 Thank you very much for making our next steps very clear. I'll do my best to improve our proposal. 2014-02-04 Peter Saint-Andre : > Yes, I think it is best to define a separate profile for HTTPAUTH (based on > various conversations at the last IETF meeting). I will try to review your > document again very soon. > > Peter > > > On 2/3/14, 5:18 PM, Yutaka OIWA wrote: >> >> Dear Julian and Peter (added), >> >> how about the things ongoing about handling of >> HTTP-AUTH normalization in context of PRECIS? >> >> I proposed general-purpose HTTP-AUTH normalization >> profile to PRECIS WG (just because I need it :-), >> and they considered merging it with new SASLPREPbis. >> My current draft is >> http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . >> SASLPREPbis is in WG pool as >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . >> >> I am awaiting actions for whether the merging >> will actually happen or not. >> In my understanding, removing of SASL-dependent >> natures (e.g. that in Username grammer) from current >> saslprepbis is not going forward yet, and current >> SASLPREPbis is, at least personally, not applicable >> for any HTTP auth schemes except SASL-backed ones. >> For clarify, SASLPREPbis is really good, and the differences >> are not large but critical. >> >> I think there is several possible directions for us to go: >> >> 1) Go merging: push forward to make saslprepbis a >> general-purpose precis profile by separating >> still-remaining SASL-only features. >> IMO, in this case we may need two separate >> application notes documents for SASL and HTTP-AUTH. >> >> 2) Go separate: discuss HTTPAUTH in context of >> PRECIS separately from SASLPREP. >> I believe that my draft will give us a good starting point, >> as my best effort. >> >> 3) for Julian, one possible best current cheating, if you >> can't wait PRECIS WG, might be just specify NFC as a >> canonical form. Both SASLPREP and HTTPAUTHprep >> (and many other PRECIS profiles) are NFC based, >> so it will not likely harm future development of proper >> PRECIS-based "preparation" (including normalization). >> >> Also, I would be happy if Julian (as talked in Vancouver) >> and other people in HTTPAUTH WG and PRECIS WG >> could give us a feedback on my proposal from the >> both WG's points of view. >> >> 2014-02-04 Julian Reschke : >>> >>> On 2013-10-05 11:01, Julian Reschke wrote: >>>> >>>> >>>> On 2013-09-12 12:35, Julian Reschke wrote: >>>>> >>>>> >>>>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>>>> >>>>>> >>>>>> Draft minutes for the HTTP-AUTH session have been posted. >>>>>> >>>>>> They can be found at: >>>>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>>>> >>>>>> If you notice any omissions or other errors in the minutes, please let >>>>>> us know. >>>>>> ... >>>>> >>>>> >>>>> >>>>> OK, the minutes mention: >>>>> >>>>> "Unicode Normalization : Getting from what is typed in to Unicode code >>>>> points will require discussion" >>>>> >>>>> So how do we proceed from here? Any concrete proposals for what to say? >>>> >>>> >>>> >>>> It seems we don't know what to say then, right? >>>> >>>> How about: "Beware that differing Unicode normalization forms can cause >>>> interoperability problems. See [http://unicode.org/reports/tr15/]."? >>>> >>>> >>>> Best regards, Julian >>> >>> >>> >>> So, does anybody have a good plan how to approach the normalization >>> problem? >>> >>> Otherwise we'll just have to state that there are dragons out there, and >>> that we don't know the solution... >>> >>> >>> Best regards, Julian >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >> >> >> >> > > > -- > Peter Saint-Andre > https://stpeter.im/ -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Wed Feb 5 01:21:26 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C661A00B5 for ; Wed, 5 Feb 2014 01:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iitSTNh86p2h for ; Wed, 5 Feb 2014 01:21:24 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id DDCFE1A00B0 for ; Wed, 5 Feb 2014 01:21:23 -0800 (PST) Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUvICk+b5DP+62G5sqPZA1kmCDHBwM99y@postini.com; Wed, 05 Feb 2014 01:21:23 PST Received: by mail-vc0-f181.google.com with SMTP id ie18so80017vcb.40 for ; Wed, 05 Feb 2014 01:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=87ZI9PmBlpw8Em6DkLz/xW7fTrkxENYoHnq8Dq9FkO4=; b=enNeEJdOle7pADNTBb4AN6G6yUb11mKyEj2ZpnhjbOD7TuCJMQk6en9AninVgJYEfL cRYpMBrvWCjuANrsDLUb+zKYFTQaus/VuKb4IcLyyyEqaCheLa4L5TZfGudiTPLLmSkd iqxpofVeUosUVN+wIc2dSfudqgb7fRma9yqNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=87ZI9PmBlpw8Em6DkLz/xW7fTrkxENYoHnq8Dq9FkO4=; b=lqmBGJD51L4+OLIoIocDAeD6WBZtviLZggB59TUZotwsTXBh66uj19jSlYzzNgNoF2 /FuBlzMLa9Q6ibgOekVsBW6xdvvma3xINHiZwl+AlIBCmtHv2Kl1OlqtelMi2LU2Yk+F JIKcdEB3bp1pFcMrVnbD6ymeZJinfcKVDm8NP/yeQebzYGuzJjGxmTIVOdgvo9NU3U2+ oSYnMP/r/cwyzmNlvRjr1GnpxB79TgBQigo/9x3miZWFR2YWrVRQ1IkV9TGCsvlMjVSG cEf+4NXiG6KJPolXfd3iVXqLPsSky19M+sP6+mqamx4ybrmQesI4RcS6ih8hHAbM0G8p VngQ== X-Gm-Message-State: ALoCoQm67dGCzqDD0cbRVcZFSsWgdMqE6rOnYtspq1n6lMtv5bNUu1+c+a/yH97/zOnaQHsgasekIYhMZO0W1VBvhK/Sustl9UgcL+8EXUKvud+JCabmDRqBV3LsqViEmBK5vZgy/alBzUmusVoQ+wIcFqFeZ3M85Q== X-Received: by 10.58.90.202 with SMTP id by10mr217347veb.6.1391592082919; Wed, 05 Feb 2014 01:21:22 -0800 (PST) X-Received: by 10.58.90.202 with SMTP id by10mr217331veb.6.1391592082720; Wed, 05 Feb 2014 01:21:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 01:21:02 -0800 (PST) In-Reply-To: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> From: Yutaka OIWA Date: Wed, 5 Feb 2014 18:21:02 +0900 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "http-auth@ietf.org" , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:21:26 -0000 >>2) As previously agreed upon, merge the two specs but only do some >>handwaving with respect to normalization for now. > > I like 2). Given taking 2), is it technically possible to make an "update" to the merged Basic-auth spec by a PRECIS profile document defined later (but sooner)? # I think, if any, the update may be something to "RECOMMEND" # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", # considering very pervasive and pragmatic nature of the Basic authenticati= on. 2014-02-05 Bjoern Hoehrmann : > * Julian Reschke wrote: >>Alternatives for "Basic": >> >>1) Keep the separation of the base spec >>(draft-ietf-httpauth-basicauth-update) from the one addressing I18N >>(draft-ietf-httpauth-basicauth-enc), and try to get the former out of >>the door as soon as possible. >> >>2) As previously agreed upon, merge the two specs but only do some >>handwaving with respect to normalization for now. > > I like 2). > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC= ) National Institute of Advanced Industrial Science and Technology (AIST= ) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From julian.reschke@gmx.de Wed Feb 5 01:41:17 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F2B1A00B9 for ; Wed, 5 Feb 2014 01:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jGs5TmzeXFN for ; Wed, 5 Feb 2014 01:41:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7754D1A00B3 for ; Wed, 5 Feb 2014 01:41:15 -0800 (PST) Received: from [192.168.1.102] ([93.217.75.252]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LtJAR-1VDYen0EiB-012m8D for ; Wed, 05 Feb 2014 10:41:14 +0100 Message-ID: <52F20734.4080405@gmx.de> Date: Wed, 05 Feb 2014 10:41:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yutaka OIWA , Bjoern Hoehrmann References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:U8/InVKQH+hBaLPRsYMufZBFzI1fPB34aizRxl7AvAYusex3yqs 1g1qhiZdrlcs+LZckMe7EJVCymLgqOdCUuHdsn5VpW5ayX8cn6XnWdOedcIcjyF2rk6uyJ1 HZWUYttUAZxWjJQ9UBhOPQqPn5i76aJ0nTpciqjruUNShCUWcoIub3t4Umfh4p3Q+L5sOlS 34DqLMfchyhHO+wXNT8JA== X-Mailman-Approved-At: Wed, 05 Feb 2014 01:52:00 -0800 Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:41:18 -0000 On 2014-02-05 10:21, Yutaka OIWA wrote: >>> 2) As previously agreed upon, merge the two specs but only do some >>> handwaving with respect to normalization for now. >> >> I like 2). > > Given taking 2), is it technically possible to make an "update" to > the merged Basic-auth spec by a PRECIS profile document defined > later (but sooner)? > > # I think, if any, the update may be something to "RECOMMEND" > # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", > # considering very pervasive and pragmatic nature of the Basic authentication. We're going for Proposed Standard here. We can always revise the document again, change this, and go to Full Standard later on. The key issue aren't the specs, but what implementations do. So we need to agree on what they should do and try to get *that* implemented, Otherwise the whole exercise is completely academic. Best regards, Julian From julian.reschke@gmx.de Wed Feb 5 01:43:04 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AC1A00B7 for ; Wed, 5 Feb 2014 01:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGRA5XqMLSK0 for ; Wed, 5 Feb 2014 01:43:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 904071A00B3 for ; Wed, 5 Feb 2014 01:43:02 -0800 (PST) Received: from [192.168.1.102] ([93.217.75.252]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LdZAI-1VSbZ83lre-00ihJN for ; Wed, 05 Feb 2014 10:43:01 +0100 Message-ID: <52F207A1.80506@gmx.de> Date: Wed, 05 Feb 2014 10:42:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir , Yutaka OIWA , Bjoern Hoehrmann References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NNE4NQiJyDGhv9N1VHcY0zufCAiAbmH16w3Rla8J46LKFDrEoOb hbDOjqqwfEKnJFjdObjMGNkZ/a8YLXo/hWAunvFzWbSwYf2/G9M50qvh5u+bKqgC08Vflad AZ82ZypPQ63DIgNm3rZSphc0+QTNdGclz94q8rgE7pUtoyPB8qRaOwQxmsQxLWJpOxpi6vL OAa4tbCBsJ/ii2pD2UBbw== X-Mailman-Approved-At: Wed, 05 Feb 2014 01:52:00 -0800 Cc: "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:43:04 -0000 On 2014-02-05 10:30, Yoav Nir wrote: > [With http-auth chair hat on] > > It is possible for one draft document to normatively reference another draft document. It can go through WGLC, IETF-LC, and IESG review and approval with this reference. > > In such cases, the document does not get published until the reference also becomes an RFC, at which point the RFC editor converts the reference to a reference to the new RFC. > > There are two downsides to this process: > - It delays the original document indefinitely. Not a problem in our case because nobody (other than the authors is waiting for our document) Understood, but no, I believe we should get this done. Either by ignoring I18N for now (a), or by documenting what happens in practice (b). (a) Status Quo (b) Requires research. > ... Best regards, Julian From ynir@checkpoint.com Wed Feb 5 01:31:03 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25671A00B5; Wed, 5 Feb 2014 01:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9e0xwTEspQb; Wed, 5 Feb 2014 01:31:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC31A00B1; Wed, 5 Feb 2014 01:31:00 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s159Uofa005566; Wed, 5 Feb 2014 11:30:50 +0200 X-CheckPoint: {52F1FDE8-15-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 11:30:50 +0200 From: Yoav Nir To: Yutaka OIWA , Bjoern Hoehrmann Thread-Topic: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session Thread-Index: AQHPIlOqXWllV0ATE0aQ3qoBK1NG85qmYu9w Date: Wed, 5 Feb 2014 09:30:49 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Feb 2014 01:52:00 -0800 Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:31:03 -0000 [With http-auth chair hat on] It is possible for one draft document to normatively reference another draf= t document. It can go through WGLC, IETF-LC, and IESG review and approval = with this reference.=20 In such cases, the document does not get published until the reference also= becomes an RFC, at which point the RFC editor converts the reference to a = reference to the new RFC. There are two downsides to this process: - It delays the original document indefinitely. Not a problem in our case = because nobody (other than the authors is waiting for our document) - You get into a messy situation if the precis document ends up stalled. If we have a direction, and we have authors volunteering to write this in p= recis, I'm not opposed to taking this route.=20 Please note, that precise encoding issues apply to both passwords and usern= ames, as the new Digest algorithm allows hiding of usernames ([1]) Yoav [1] http://tools.ietf.org/html/draft-ietf-httpauth-digest-04#section-3.4.4 -----Original Message----- From: http-auth [mailto:http-auth-bounces@ietf.org] On Behalf Of Yutaka OIW= A Sent: Wednesday, February 05, 2014 11:21 AM To: Bjoern Hoehrmann Cc: Julian Reschke; http-auth@ietf.org; precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes= Posted for IETF 87 HTTP-AUTH Session >>2) As previously agreed upon, merge the two specs but only do some=20 >>handwaving with respect to normalization for now. > > I like 2). Given taking 2), is it technically possible to make an "update" to the merg= ed Basic-auth spec by a PRECIS profile document defined later (but sooner)? # I think, if any, the update may be something to "RECOMMEND" # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", # con= sidering very pervasive and pragmatic nature of the Basic authentication. 2014-02-05 Bjoern Hoehrmann : > * Julian Reschke wrote: >>Alternatives for "Basic": >> >>1) Keep the separation of the base spec >>(draft-ietf-httpauth-basicauth-update) from the one addressing I18N=20 >>(draft-ietf-httpauth-basicauth-enc), and try to get the former out of=20 >>the door as soon as possible. >> >>2) As previously agreed upon, merge the two specs but only do some=20 >>handwaving with respect to normalization for now. > > I like 2). > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20 > http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681= =20 > =B7 http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20 > http://www.websitedev.de/ --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC= ) National Institute of Advanced Industrial Science and Technology (AIST= ) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth Email secured by Check Point From alexey.melnikov@isode.com Wed Feb 5 02:41:14 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB41A00D4 for ; Wed, 5 Feb 2014 02:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4Ul-_ZZxejn for ; Wed, 5 Feb 2014 02:41:12 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2851A00CB for ; Wed, 5 Feb 2014 02:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1391596870; d=isode.com; s=selector; i=@isode.com; bh=gpjHMC9wgs2JPBV7yuwTa0EjFVdslpAudxZB3LySxpE=; 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=EGYBHhp6ZJYvV7mBT7wUGsvQboqiBXVzVj1tLOtULhsqSqOzYDeyb1f3MQ75bT1rr0yMg6 lIqlpOHQQjjc4nMyE7QMZoGuLXb3sNMurTmMAmSzKrt9XZbTkIq8PRWfg36JHD5coKRfWl fD9xJb48/lh94eqJNhXZW03XFe6BoiI=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Feb 2014 10:41:10 +0000 Message-ID: <52F21547.8030806@isode.com> Date: Wed, 05 Feb 2014 10:41:11 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Peter Saint-Andre , precis@ietf.org References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> In-Reply-To: <52F17FC2.3090103@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:41:14 -0000 On 05/02/2014 00:03, Peter Saint-Andre wrote: > On 2/4/14, 3:01 PM, Alexey Melnikov wrote: >> Hi Peter, >> >> On 24/01/2014 13:57, Peter Saint-Andre wrote: >>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: >> [...] >>>> We changed the definition of local case mapping and >>> That is better, thanks. If I understand your text correctly, we might >>> want to say very clearly that a PRECIS profile needs to either use >>> case mapping or use local case mapping, but that it can't use both >>> (i.e., local case mapping is an alternative to case mapping, not >>> something additional on top of case mapping, since the local case >>> mapping rule will apply normal case mapping if there is no >>> locale-specific mapping). >> If that is the way we want to go, then this contradicts section 5 of >> draft-ietf-precis-framework: >> >> 2. Optionally, additional mappings such as those as specified in >> [I-D.ietf-precis-mappings]: >> 1. Delimiter mapping >> 2. Special mapping >> 3. Local case mapping >> 3. Non-local case mapping >> >> >> I.e. draft-ietf-precis-framework needs to be updated to make this clear >> as well. > > Agreed. I think that the definition of "local case mapping" has > changed in the latest version of the mappings document, such that (if > we think the new direction is appropriate) we'd need to do this: > > OLD > 2. Optionally, additional mappings such as those as specified in > [I-D.ietf-precis-mappings]: > 1. Delimiter mapping > 2. Special mapping > 3. Local case mapping > 3. Non-local case mapping > > NEW > 2. Optionally, additional mappings such as those as specified in > [I-D.ietf-precis-mappings]: > 1. Delimiter mapping > 2. Special mapping > 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or > case mapping as described under Section 4.1.3 of this document > > Does that look right? Yes, this looks good. I think [I-D.ietf-precis-mappings] is definitely normative now with your new text (it wasn't before). From y.oiwa@aist.go.jp Wed Feb 5 02:46:04 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D791A00D4 for ; Wed, 5 Feb 2014 02:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csl1Haa5aua9 for ; Wed, 5 Feb 2014 02:46:02 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 030501A00D3 for ; Wed, 5 Feb 2014 02:46:01 -0800 (PST) Received: from mail-vb0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUvIWaVp4VA014o2xDNNo55wskZen13bQ@postini.com; Wed, 05 Feb 2014 02:46:01 PST Received: by mail-vb0-f50.google.com with SMTP id w8so144397vbj.37 for ; Wed, 05 Feb 2014 02:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eLLjRxA9+8srn4t0Lk4XcZPtzPjVjM1y8KiaAZsYhCo=; b=CAzfKrqAO5UGd+yd6Engk5qLncQPZtEMQJW0jtqZmLBXYLKv4bAUxwmqpKQTu5o2Ky td4YuzFEJWyUa5577VVL2OxYD1hNKSdPrRLVFpAIcWGACRVUGW32aplDI5LxPOPKrpP7 HBkEkL1wz4veIMBlzz9hKYNCLO2YXZHTJoSCM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eLLjRxA9+8srn4t0Lk4XcZPtzPjVjM1y8KiaAZsYhCo=; b=DPutShVQd43QPioV37hStfq0z06UW5dHY2+pB5RXT2Sjz+6zMwmkxO5zAGn9uocvqp Hfkz98oj6UGOZnbCnPYvogGJ+832uV5gH/4qh4iH5pC6D/W//W/EjF7VIw0eMD2cS6p8 BS/AzWe/ilZmFze5MWaIkuVfLIeqRRoxD3kgrMyrEoRUSyGGWkpVDDvQEMHueLVZqQj0 SW5a2/lURGY75MAjMLKxa8Bi6N63v59hvkStCB0BNgshcpBad/peQ1WeLS6I0B/1g39C B1V7KGmXVIe2aXaw7Tcz0LW7ciqqs+cPZSLBD6wORH8IATR+bXFTJk7qFx7M75GFW4eo x0UA== X-Gm-Message-State: ALoCoQnAsGlNdtHUOTvwFnUSp+2c1K2md2lB95MVcHk1abL/FqFih+ftjSlLZI5cOJOyTLm2KrsNj321dybeXujhxehGYkggLamJ/IzphGJR1WEIUZqu15Moi7aZfcPF5zArntxe++fVLWv63mA2/qPDXE62n+j0ZA== X-Received: by 10.52.170.3 with SMTP id ai3mr387254vdc.35.1391597160712; Wed, 05 Feb 2014 02:46:00 -0800 (PST) X-Received: by 10.52.170.3 with SMTP id ai3mr387247vdc.35.1391597160601; Wed, 05 Feb 2014 02:46:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 02:45:40 -0800 (PST) In-Reply-To: <52F20734.4080405@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> <52F20734.4080405@gmx.de> From: Yutaka OIWA Date: Wed, 5 Feb 2014 19:45:40 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:46:04 -0000 Dear Julian, > The key issue aren't the specs, but what implementations do. So we need to agree on what they should do and try to get *that* implemented, Otherwise the whole exercise is completely academic. Your point is really understood and agreed. We need a thorough discussion for requirement strength of string preparation (including Unicode normalization) for Basic and Digest schemes. There is a tough trade-off: if the requirement is too weak, it decreases interoperability and the users will experience a frustrating failed authentications; if too strong, implementors will not just follow it. We need to find a good mid-point. My current position is not actually insisting PRECIS-based handling for a MUST requirement of UTF-8 Basic. My current preference is, assuming that the majority of people think MUST-required PRECIS handling too strong, the following: "to require NFC Unicode normalization a SHOULD, and some PRECIS handling a MAY with stating it's a good practice to do." The reason is: Unicode normalization is hard to be worked-around by end users; other PRECIS preparations are generally workaround-able by users by avoiding some characters in their input. (Oppositely, if the majority thought that UTF-8 Basic should do a correct PRESIS-based preparation as a MUST for the best interoperability assurance, I would happily follow it.) * Regarding general issue on string preparation for HTTP authentication, I have two strong opinions around here: 1) "single solution": Within HTTPAUTH technology area, There should not be randomly many ways of preparations with minor differences with no justifiable reasons. There should be a single default way of preparation which will be used for almost all HTTP-related authentications *if they do preparation*, unless there are some other dependencies (like SASLprep for SASL-backed schemes.) 2) "new good things for new technologies": For *new* auth schemes, for which we can expect they will have a new implementation efforts anyway, we have a motivation for MUST-or-SHOULD requirement of correct I18N handling. (It is something like an exercise anyway, so we may try to do the "correct" thing.) However, for retrofitting schemes like Basic and Digest, I suspect that the normative requirements for correct I18N may be too strong. I guess we may need to allow implementors to "ignore" such complex handling, and still saying their implementations are compliant to the new UTF-8 Basic. That's why, in my HTTPAUTHprep draft, I said it will serve as a dual-purpose document, both as a normative reference for new things and a best practice for other existing schemes. (See Section 1.2 of my draft, understanding the phrase is not yet polished). 2014-02-05 Julian Reschke : > On 2014-02-05 10:21, Yutaka OIWA wrote: >>>> >>>> 2) As previously agreed upon, merge the two specs but only do some >>>> handwaving with respect to normalization for now. >>> >>> >>> I like 2). >> >> >> Given taking 2), is it technically possible to make an "update" to >> the merged Basic-auth spec by a PRECIS profile document defined >> later (but sooner)? >> >> # I think, if any, the update may be something to "RECOMMEND" >> # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", >> # considering very pervasive and pragmatic nature of the Basic >> authentication. > > > We're going for Proposed Standard here. We can always revise the document > again, change this, and go to Full Standard later on. > > The key issue aren't the specs, but what implementations do. So we need to > agree on what they should do and try to get *that* implemented, Otherwise > the whole exercise is completely academic. > > Best regards, Julian > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From t.nemo10@kmd.keio.ac.jp Wed Feb 5 06:18:12 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D44F1A0147 for ; Wed, 5 Feb 2014 06:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB5Uf_I0h7rI for ; Wed, 5 Feb 2014 06:18:09 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 29E321A015B for ; Wed, 5 Feb 2014 06:18:09 -0800 (PST) Received: from [192.168.0.5] (i114-191-9-138.s41.a012.ap.plala.or.jp [114.191.9.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 54DFA7FDE2 for ; Wed, 5 Feb 2014 23:18:07 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_80028694-8737-4313-9F9E-77BA8F30D4F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <54FFC4FD-6D68-4387-A809-3C9FA7668D38@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Wed, 5 Feb 2014 23:17:51 +0900 References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> To: "precis@ietf.org" In-Reply-To: <52F21547.8030806@isode.com> X-Mailer: Apple Mail (2.1510) Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:18:12 -0000 --Apple-Mail=_80028694-8737-4313-9F9E-77BA8F30D4F6 Content-Type: multipart/alternative; boundary="Apple-Mail=_33CA6384-7231-40FE-BA1D-2084B7C356A4" --Apple-Mail=_33CA6384-7231-40FE-BA1D-2084B7C356A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Peter-san, Alexey-san, thank you for your quick response. If you have any comments for open issues in mappings-06, I would like to = hear about it.=20 These comments will be reflected on the updated mappings document as -07 = before cut off date(2/14),=20 as it will influence the framework document. There are two points that have not reached a consensus in the mappings = document . (1) Define local case mapping as an alternative to case mapping in the = PRECIS framework pros: German eszett, Turkish dotless i, etc. will not be mapped = contrary to the users' expectation. cons: It is necessary to modify the framework document. options: (A) Support the change of -06 (B) Don't support the change of -06, and restore the = algorithm of -05 (2) Way to deal with the context dependent mapping for both Greek sigma = and final sigma. (a) Define extra mapping table for sigma and final sigma inside = mappings document pros: Sigma and final sigma will not be mapped contrary to = users' expectation. cons: It will be necessary to update this document to follow = unicode's updated version. (b) Leave it to unicode's definition pros: It is not necessary to define extra mapping table for = sigma and final sigma. cons: Unless unicode is updated and a new definition to map both = sigma and final sigma has been added, final sigma will be mapped to sigma.=20 options: (A) Support the above (a) (B) Support the above (b) I would appreciate your comment. Regards, Nemo On 2014/02/05, at 19:41, Alexey Melnikov = wrote: > On 05/02/2014 00:03, Peter Saint-Andre wrote: >> On 2/4/14, 3:01 PM, Alexey Melnikov wrote: >>> Hi Peter, >>>=20 >>> On 24/01/2014 13:57, Peter Saint-Andre wrote: >>>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: >>> [...] >>>>> We changed the definition of local case mapping and >>>> That is better, thanks. If I understand your text correctly, we = might >>>> want to say very clearly that a PRECIS profile needs to either use >>>> case mapping or use local case mapping, but that it can't use both >>>> (i.e., local case mapping is an alternative to case mapping, not >>>> something additional on top of case mapping, since the local case >>>> mapping rule will apply normal case mapping if there is no >>>> locale-specific mapping). >>> If that is the way we want to go, then this contradicts section 5 of >>> draft-ietf-precis-framework: >>>=20 >>> 2. Optionally, additional mappings such as those as specified in >>> [I-D.ietf-precis-mappings]: >>> 1. Delimiter mapping >>> 2. Special mapping >>> 3. Local case mapping >>> 3. Non-local case mapping >>>=20 >>>=20 >>> I.e. draft-ietf-precis-framework needs to be updated to make this = clear >>> as well. >>=20 >> Agreed. I think that the definition of "local case mapping" has = changed in the latest version of the mappings document, such that (if we = think the new direction is appropriate) we'd need to do this: >>=20 >> OLD >> 2. Optionally, additional mappings such as those as specified in >> [I-D.ietf-precis-mappings]: >> 1. Delimiter mapping >> 2. Special mapping >> 3. Local case mapping >> 3. Non-local case mapping >>=20 >> NEW >> 2. Optionally, additional mappings such as those as specified in >> [I-D.ietf-precis-mappings]: >> 1. Delimiter mapping >> 2. Special mapping >> 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or >> case mapping as described under Section 4.1.3 of this document >>=20 >> Does that look right? > Yes, this looks good. I think [I-D.ietf-precis-mappings] is definitely = normative now with your new text (it wasn't before). >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_33CA6384-7231-40FE-BA1D-2084B7C356A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii pros: =  German eszett, Turkish dotless i, etc. will not be mapped contrary = to the users' expectation.
cons: It is necessary to = modify the framework document.

= options:
(A) Support the change of = -06
= (B) Don't support the change of -06, and restore the algorithm of = -05


(2) Way to deal with the context dependent = mapping for both Greek sigma and final sigma.
  (a) Define extra = mapping table for sigma and final sigma inside mappings = document
= pros: Sigma and final sigma will not be mapped contrary to = users' expectation.
cons: It will be necessary to = update this document to follow unicode's updated = version.

  (b) Leave it to unicode's = definition
= pros: It is not necessary to define extra mapping table for sigma = and final sigma.
cons: Unless unicode is updated = and a new definition to map both sigma and final = sigma has been added,
      final = sigma will be mapped to sigma. 

= options:
(A) Support the above = (a)
= (B) Support the above (b)

I would appreciate = your = comment.

Regards,

Nemo

On 2014/02/05, at 19:41, Alexey Melnikov = <alexey.melnikov@isode.com>= ; wrote:

On 05/02/2014 00:03, Peter Saint-Andre = wrote:
On 2/4/14, 3:01 PM, Alexey Melnikov = wrote:
Hi Peter,

On 24/01/2014 = 13:57, Peter Saint-Andre wrote:
On = 01/24/2014 06:02 AM, Takahiro Nemoto wrote:
=  [...]
We = changed the definition of local case mapping and
That is = better, thanks. If I understand your text correctly, we might
want to = say very clearly that a PRECIS profile needs to either use
case = mapping or use local case mapping, but that it can't use both
(i.e., = local case mapping is an alternative to case mapping, not
something = additional on top of case mapping, since the local case
mapping rule = will apply normal case mapping if there is no
locale-specific = mapping).
If that is the way we want to go, then this = contradicts section 5 of
draft-ietf-precis-framework:

=    2.  Optionally, additional mappings such as those = as specified in
=        [I-D.ietf-precis-mappings]:
=        1.  Delimiter mapping
=        2.  Special mapping
=        3.  Local case = mapping
   3.  Non-local case = mapping


I.e. draft-ietf-precis-framework needs to be updated = to make this clear
as well.

Agreed. I think that = the definition of "local case mapping" has changed in the latest version = of the mappings document, such that (if we think the new direction is = appropriate) we'd need to do this:

OLD
 2. =  Optionally, additional mappings such as those as specified in
=       [I-D.ietf-precis-mappings]:
=       1.  Delimiter mapping
=       2.  Special mapping
=       3.  Local case mapping
=   3.  Non-local case mapping

NEW
 2. =  Optionally, additional mappings such as those as specified in
=       [I-D.ietf-precis-mappings]:
=       1.  Delimiter mapping
=       2.  Special mapping
=   3.  Either "local case mapping" from = [I-D.ietf-precis-mappings] or
=       case mapping as described under = Section 4.1.3 of this document

Does that look = right?
Yes, this looks good. I think = [I-D.ietf-precis-mappings] is definitely normative now with your new = text (it wasn't = before).

_______________________________________________
precis = mailing list
precis@ietf.org
https://www.ietf.or= g/mailman/listinfo/precis

= --Apple-Mail=_33CA6384-7231-40FE-BA1D-2084B7C356A4-- --Apple-Mail=_80028694-8737-4313-9F9E-77BA8F30D4F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8kgPAAoJEJk7o/xhVana708H/izvkwPhBaoVQCTS9ymlgZTQ UBsvUVBLsGqJklnwDeXchSCxe1eGughCa3HKRXbAFZEoOKPvprqaAhml9nVHoWAA qzOFoZMjKH3lnCkwrnyN/ngkT31a1/WSN+QHWfIjJ8J2XRakg4ZNLrsgwwZqX5m6 GKC1rHX4DEa027Yiz+/q1D7YvusXUa0W440uFfa2Qz4l72DdZ+dBijAvlHvW3sPo ZQD+Ap11KzmqSeB6iEV4mKgf7lTGIwuUurZQff86YX02ktxq+UkQvamc/4PXlf7+ wwRSRNVskAMZFLf11Ivnb48UVJOl3atsvhV7x+b44A1gexYrPIGE5oPiGTTa+/8= =gNwS -----END PGP SIGNATURE----- --Apple-Mail=_80028694-8737-4313-9F9E-77BA8F30D4F6-- From stpeter@stpeter.im Wed Feb 5 16:38:48 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382FE1A02A3 for ; Wed, 5 Feb 2014 16:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpiYh2g1db3W for ; Wed, 5 Feb 2014 16:38:46 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9691D1A0280 for ; Wed, 5 Feb 2014 16:38:46 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 97EDB4010C; Wed, 5 Feb 2014 17:38:45 -0700 (MST) Message-ID: <52F2D98D.4090500@stpeter.im> Date: Wed, 05 Feb 2014 17:38:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [precis] framework dependency on mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:38:48 -0000 The framework document has a normative dependency on the mappings document. I see 3 options: (1) change the reference to informative (2) change the mappings document to standards track (3) keep the mappings document informational and add to the list of exceptions for dependency checking Does the WG have a preference? I like (3) best, followed by (2) and then (1). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Feb 5 16:39:36 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848E91A022C for ; Wed, 5 Feb 2014 16:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2b0rcclj7X0 for ; Wed, 5 Feb 2014 16:39:35 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE91A01CC for ; Wed, 5 Feb 2014 16:39:35 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C5A634010C; Wed, 5 Feb 2014 17:39:33 -0700 (MST) Message-ID: <52F2D9BE.9040607@stpeter.im> Date: Wed, 05 Feb 2014 17:39:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexey Melnikov , precis@ietf.org References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> In-Reply-To: <52F21547.8030806@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:39:36 -0000 On 2/5/14, 3:41 AM, Alexey Melnikov wrote: > On 05/02/2014 00:03, Peter Saint-Andre wrote: >> On 2/4/14, 3:01 PM, Alexey Melnikov wrote: >>> Hi Peter, >>> >>> On 24/01/2014 13:57, Peter Saint-Andre wrote: >>>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: >>> [...] >>>>> We changed the definition of local case mapping and >>>> That is better, thanks. If I understand your text correctly, we might >>>> want to say very clearly that a PRECIS profile needs to either use >>>> case mapping or use local case mapping, but that it can't use both >>>> (i.e., local case mapping is an alternative to case mapping, not >>>> something additional on top of case mapping, since the local case >>>> mapping rule will apply normal case mapping if there is no >>>> locale-specific mapping). >>> If that is the way we want to go, then this contradicts section 5 of >>> draft-ietf-precis-framework: >>> >>> 2. Optionally, additional mappings such as those as specified in >>> [I-D.ietf-precis-mappings]: >>> 1. Delimiter mapping >>> 2. Special mapping >>> 3. Local case mapping >>> 3. Non-local case mapping >>> >>> >>> I.e. draft-ietf-precis-framework needs to be updated to make this clear >>> as well. >> >> Agreed. I think that the definition of "local case mapping" has >> changed in the latest version of the mappings document, such that (if >> we think the new direction is appropriate) we'd need to do this: >> >> OLD >> 2. Optionally, additional mappings such as those as specified in >> [I-D.ietf-precis-mappings]: >> 1. Delimiter mapping >> 2. Special mapping >> 3. Local case mapping >> 3. Non-local case mapping >> >> NEW >> 2. Optionally, additional mappings such as those as specified in >> [I-D.ietf-precis-mappings]: >> 1. Delimiter mapping >> 2. Special mapping >> 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or >> case mapping as described under Section 4.1.3 of this document >> >> Does that look right? > Yes, this looks good. Thanks for the feedback. > I think [I-D.ietf-precis-mappings] is definitely > normative now with your new text (it wasn't before). You are right. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Feb 5 16:41:16 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A01A0280 for ; Wed, 5 Feb 2014 16:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Amp6s2BfDiY for ; Wed, 5 Feb 2014 16:41:14 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 984D91A022C for ; Wed, 5 Feb 2014 16:41:14 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A16874010C; Wed, 5 Feb 2014 17:41:13 -0700 (MST) Message-ID: <52F2DA22.3000403@stpeter.im> Date: Wed, 05 Feb 2014 17:41:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Takahiro Nemoto , "precis@ietf.org" References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> <54FFC4FD-6D68-4387-A809-3C9FA7668D38@kmd.keio.ac.jp> In-Reply-To: <54FFC4FD-6D68-4387-A809-3C9FA7668D38@kmd.keio.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:41:17 -0000 On 2/5/14, 7:17 AM, Takahiro Nemoto wrote: > Dear all, > > Peter-san, Alexey-san, thank you for your quick response. > > If you have any comments for open issues in mappings-06, I would like to > hear about it. > These comments will be reflected on the updated mappings document as -07 > before cut off date(2/14), > as it will influence the framework document. > > There are two points that have not reached a consensus in the mappings > document . > > (1) Define local case mapping as an alternative to case mapping in the > PRECIS framework > pros: German eszett, Turkish dotless i, etc. will not be mapped > contrary to the users' expectation. > cons: It is necessary to modify the framework document. > > options: > (A) Support the change of -06 > (B) Don't support the change of -06, and restore the algorithm of -05 I think -06 is fine, so I support (A). > (2) Way to deal with the context dependent mapping for both Greek sigma > and final sigma. > (a) Define extra mapping table for sigma and final sigma inside > mappings document > pros: Sigma and final sigma will not be mapped contrary to users' > expectation. > cons: It will be necessary to update this document to follow unicode's > updated version. > > (b) Leave it to unicode's definition > pros: It is not necessary to define extra mapping table for sigma and > final sigma. > cons: Unless unicode is updated and a new definition to map both sigma > and final sigma**has been added, > final sigma will be mapped to sigma. > > options: > (A) Support the above (a) > (B) Support the above (b) > > I would appreciate your comment. I support (B). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Feb 7 16:24:20 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67611A0522 for ; Fri, 7 Feb 2014 16:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK-pj9s_vWBi for ; Fri, 7 Feb 2014 16:24:19 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0561AD694 for ; Fri, 7 Feb 2014 16:24:19 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6505E40352; Fri, 7 Feb 2014 17:24:18 -0700 (MST) Message-ID: <52F57930.70205@stpeter.im> Date: Fri, 07 Feb 2014 17:24:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Alexey Melnikov , precis@ietf.org References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> <52F2D9BE.9040607@stpeter.im> In-Reply-To: <52F2D9BE.9040607@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 00:24:20 -0000 On 2/5/14, 5:39 PM, Peter Saint-Andre wrote: > On 2/5/14, 3:41 AM, Alexey Melnikov wrote: >> On 05/02/2014 00:03, Peter Saint-Andre wrote: >>> On 2/4/14, 3:01 PM, Alexey Melnikov wrote: >>>> Hi Peter, >>>> >>>> On 24/01/2014 13:57, Peter Saint-Andre wrote: >>>>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: >>>> [...] >>>>>> We changed the definition of local case mapping and >>>>> That is better, thanks. If I understand your text correctly, we might >>>>> want to say very clearly that a PRECIS profile needs to either use >>>>> case mapping or use local case mapping, but that it can't use both >>>>> (i.e., local case mapping is an alternative to case mapping, not >>>>> something additional on top of case mapping, since the local case >>>>> mapping rule will apply normal case mapping if there is no >>>>> locale-specific mapping). >>>> If that is the way we want to go, then this contradicts section 5 of >>>> draft-ietf-precis-framework: >>>> >>>> 2. Optionally, additional mappings such as those as specified in >>>> [I-D.ietf-precis-mappings]: >>>> 1. Delimiter mapping >>>> 2. Special mapping >>>> 3. Local case mapping >>>> 3. Non-local case mapping >>>> >>>> >>>> I.e. draft-ietf-precis-framework needs to be updated to make this clear >>>> as well. >>> >>> Agreed. I think that the definition of "local case mapping" has >>> changed in the latest version of the mappings document, such that (if >>> we think the new direction is appropriate) we'd need to do this: >>> >>> OLD >>> 2. Optionally, additional mappings such as those as specified in >>> [I-D.ietf-precis-mappings]: >>> 1. Delimiter mapping >>> 2. Special mapping >>> 3. Local case mapping >>> 3. Non-local case mapping >>> >>> NEW >>> 2. Optionally, additional mappings such as those as specified in >>> [I-D.ietf-precis-mappings]: >>> 1. Delimiter mapping >>> 2. Special mapping >>> 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or >>> case mapping as described under Section 4.1.3 of this document >>> >>> Does that look right? >> Yes, this looks good. > > Thanks for the feedback. > >> I think [I-D.ietf-precis-mappings] is definitely >> normative now with your new text (it wasn't before). > > You are right. Seeing no objections, I'll submit a new version with that revised text. Peter -- Peter Saint-Andre https://stpeter.im/ From t.nemo10@kmd.keio.ac.jp Sun Feb 9 21:50:34 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7E1A072D for ; Sun, 9 Feb 2014 21:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9bia7mbcDCU for ; Sun, 9 Feb 2014 21:50:31 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 808981A068D for ; Sun, 9 Feb 2014 21:50:31 -0800 (PST) Received: from [IPv6:2001:200:167:2ec1:f5d3:6fd0:55d9:d1ab] (unknown [IPv6:2001:200:167:2ec1:f5d3:6fd0:55d9:d1ab]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 3D1237FBE7 for ; Mon, 10 Feb 2014 14:50:30 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_21F8878C-CEA7-4137-892B-844C0C8F547A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <5789F205-1F81-433B-B835-9F305ECD9555@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 10 Feb 2014 14:50:29 +0900 References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> <52F2D9BE.9040607@stpeter.im> <52F57930.70205@stpeter.im> To: "precis@ietf.org" In-Reply-To: <52F57930.70205@stpeter.im> X-Mailer: Apple Mail (2.1510) Subject: Re: [precis] I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 05:50:34 -0000 --Apple-Mail=_21F8878C-CEA7-4137-892B-844C0C8F547A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Peter-san Thank you very much for your comment. If there are not any comments, we would like to revise the mappings document according to the current consensus. Regards, Nemo On 2014/02/08, at 9:24, Peter Saint-Andre wrote: > On 2/5/14, 5:39 PM, Peter Saint-Andre wrote: >> On 2/5/14, 3:41 AM, Alexey Melnikov wrote: >>> On 05/02/2014 00:03, Peter Saint-Andre wrote: >>>> On 2/4/14, 3:01 PM, Alexey Melnikov wrote: >>>>> Hi Peter, >>>>> >>>>> On 24/01/2014 13:57, Peter Saint-Andre wrote: >>>>>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote: >>>>> [...] >>>>>>> We changed the definition of local case mapping and >>>>>> That is better, thanks. If I understand your text correctly, we might >>>>>> want to say very clearly that a PRECIS profile needs to either use >>>>>> case mapping or use local case mapping, but that it can't use both >>>>>> (i.e., local case mapping is an alternative to case mapping, not >>>>>> something additional on top of case mapping, since the local case >>>>>> mapping rule will apply normal case mapping if there is no >>>>>> locale-specific mapping). >>>>> If that is the way we want to go, then this contradicts section 5 of >>>>> draft-ietf-precis-framework: >>>>> >>>>> 2. Optionally, additional mappings such as those as specified in >>>>> [I-D.ietf-precis-mappings]: >>>>> 1. Delimiter mapping >>>>> 2. Special mapping >>>>> 3. Local case mapping >>>>> 3. Non-local case mapping >>>>> >>>>> >>>>> I.e. draft-ietf-precis-framework needs to be updated to make this clear >>>>> as well. >>>> >>>> Agreed. I think that the definition of "local case mapping" has >>>> changed in the latest version of the mappings document, such that (if >>>> we think the new direction is appropriate) we'd need to do this: >>>> >>>> OLD >>>> 2. Optionally, additional mappings such as those as specified in >>>> [I-D.ietf-precis-mappings]: >>>> 1. Delimiter mapping >>>> 2. Special mapping >>>> 3. Local case mapping >>>> 3. Non-local case mapping >>>> >>>> NEW >>>> 2. Optionally, additional mappings such as those as specified in >>>> [I-D.ietf-precis-mappings]: >>>> 1. Delimiter mapping >>>> 2. Special mapping >>>> 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or >>>> case mapping as described under Section 4.1.3 of this document >>>> >>>> Does that look right? >>> Yes, this looks good. >> >> Thanks for the feedback. >> >>> I think [I-D.ietf-precis-mappings] is definitely >>> normative now with your new text (it wasn't before). >> >> You are right. > > Seeing no objections, I'll submit a new version with that revised text. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_21F8878C-CEA7-4137-892B-844C0C8F547A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS+GilAAoJEJk7o/xhVanaJ88H/1bNTpTck7W2F9lWCBx/4pTF 3GUoblOPg93vRAXvgfSzrc+VVcCKoyl/AH5omZ9ozHvYHE/W6xN9Pm/2ROiBCdVC EgpkGGD93cumUiajCfYt172wU9Ma6EFUhX1PPiQFs/XpnYFb3WDOKkTJh1wasazw HTtubH8d5Kw6EnfVZP1/PgSYBxUPfu/2ZbrZP4f5I7CkuXLe+11Rgsboezmo/hJS JlbWTr+mX9CZcxkSYjbZMO4qn4zSA6uSsu+CxnojEEGchDgtxM9LhByxLkbdFof/ ++UmVX6xZyOh0I7Lic5BpCX88sOZM8M8FiHCcSNKHpW4th0h2D72S9wfqomRfMo= =2x1o -----END PGP SIGNATURE----- --Apple-Mail=_21F8878C-CEA7-4137-892B-844C0C8F547A-- From t.nemo10@kmd.keio.ac.jp Sun Feb 9 22:03:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154EC1A0798 for ; Sun, 9 Feb 2014 22:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.461 X-Spam-Level: * X-Spam-Status: No, score=1.461 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsb1AT8xUg4Q for ; Sun, 9 Feb 2014 22:02:58 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id ABDD61A04C6 for ; Sun, 9 Feb 2014 22:02:58 -0800 (PST) Received: from [IPv6:2001:200:167:2ec1:f5d3:6fd0:55d9:d1ab] (unknown [IPv6:2001:200:167:2ec1:f5d3:6fd0:55d9:d1ab]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id A886C7FBE7 for ; Mon, 10 Feb 2014 15:02:58 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_974B6AEB-9AA5-46C3-B679-029BDDB4A7F7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <4AE02B96-3329-4353-BCE6-5CA2F78A552A@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 10 Feb 2014 15:02:57 +0900 References: <52F2D98D.4090500@stpeter.im> To: "precis@ietf.org" In-Reply-To: <52F2D98D.4090500@stpeter.im> X-Mailer: Apple Mail (2.1510) Subject: Re: [precis] framework dependency on mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 06:03:00 -0000 --Apple-Mail=_974B6AEB-9AA5-46C3-B679-029BDDB4A7F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014/02/06, at 9:38, Peter Saint-Andre wrote: > The framework document has a normative dependency on the mappings = document. I see 3 options: >=20 > (1) change the reference to informative >=20 > (2) change the mappings document to standards track >=20 > (3) keep the mappings document informational and add to the list of = exceptions for dependency checking >=20 > Does the WG have a preference? I like (3) best, followed by (2) and = then (1). In my opinion, the mappings document is a supplementary guideline for = the framework document, so I prefer to the keep the mappings document informational.=20 However, local case mapping in the mappings document is an alternative = to casemapping in the framework document,=20 so I support (3) as well. Regards, Nemo >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_974B6AEB-9AA5-46C3-B679-029BDDB4A7F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS+GuRAAoJEJk7o/xhVana1RoH/imvo35JGFRr52qPQxi4UJ6g vx3NSOxvq5RJQ7uhtOqk7nk8rZuHM0YJE+xG64s6CDMRKVQeGhflc1wn8szYu8O0 Uc7NXBSDGlbQr1QQkueTUKa/HUh0mDTQZaqKFSwumyrPz9MtAUl0zj/1Xb4DhAA1 A1WKqPFrmvAnfLNiZhP2JA6fyOP8TMSRxn5RwhHWAxUABMHagAxd/nnHHVn/zFhz Iq1RnB94fLtjG82nqqJfGzMn0vUbMgMHgXdFGmbJW9DoVVxnITf6ZJhiYP+Ot7Aq 6WX2gtSsTe11JWye8y1/EKyKQSShHBEDAnDnwtX85fN+XH96r8VA8igrCFFZVA4= =MQhH -----END PGP SIGNATURE----- --Apple-Mail=_974B6AEB-9AA5-46C3-B679-029BDDB4A7F7-- From david.black@emc.com Mon Feb 10 06:41:55 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD691A0307 for ; Mon, 10 Feb 2014 06:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lztl6CKH4Uoo for ; Mon, 10 Feb 2014 06:41:54 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 491EC1A02E1 for ; Mon, 10 Feb 2014 06:41:51 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1AEfmnE022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 09:41:50 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s1AEfmnE022224 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1392043310; bh=oiEjtu8QUyx0To7TW4JbO1GG91c=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=awTBd8+UB3ePCV/tdRJYH20/pxT+hgYSdzkYvF/EFTMK8rem29NZIM1IePVIOF5CU iaK8/kuEsNe79QlwovGdXmV8ZlLF+s+DX+2jKVPwNSj5R5DR8WMxq6BqVIZfnOYhx/ 1g6ki4BEucA3QAXwCKeEaRJVdyOuMa3UQnpKe9b8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s1AEfmnE022224 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 10 Feb 2014 09:41:37 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1AEfbsi030060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 09:41:37 -0500 Received: from mx15a.corp.emc.com ([169.254.1.167]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Mon, 10 Feb 2014 09:41:36 -0500 From: "Black, David" To: Peter Saint-Andre , "precis@ietf.org" Date: Mon, 10 Feb 2014 09:41:36 -0500 Thread-Topic: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt Thread-Index: Ac8i1Cj1WGf5xFXYS/mdAbAfQ4zoaQDmZjlA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712027105AD96@MX15A.corp.emc.com> References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> <54FFC4FD-6D68-4387-A809-3C9FA7668D38@kmd.keio.ac.jp> <52F2DA22.3000403@stpeter.im> In-Reply-To: <52F2DA22.3000403@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:41:56 -0000 I agree with Peter. For (1), the double-mapping behavior (local case mapping then PRECIS case mapping) for German eszett that occurred with the old approach was both subtle and non-obvious because it was spread across two drafts. The new approach documents this behavior completely in the mappings draft, which is a welcome clarity improvement. Thanks, --David > -----Original Message----- > From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Peter Saint-An= dre > Sent: Wednesday, February 05, 2014 7:41 PM > To: Takahiro Nemoto; precis@ietf.org > Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt >=20 > On 2/5/14, 7:17 AM, Takahiro Nemoto wrote: > > Dear all, > > > > Peter-san, Alexey-san, thank you for your quick response. > > > > If you have any comments for open issues in mappings-06, I would like t= o hear about it. > > These comments will be reflected on the updated mappings document as -0= 7 before cut off date(2/14), > > as it will influence the framework document. > > > > There are two points that have not reached a consensus in the mappings = document . > > > > (1) Define local case mapping as an alternative to case mapping in the = PRECIS framework > > pros: German eszett, Turkish dotless i, etc. will not be mapped contra= ry to the users' expectation. > > cons: It is necessary to modify the framework document. > > > > options: > > (A) Support the change of -06 > > (B) Don't support the change of -06, and restore the algorithm of -05 >=20 > I think -06 is fine, so I support (A). >=20 > > (2) Way to deal with the context dependent mapping for both Greek sigma= and final sigma. > > (a) Define extra mapping table for sigma and final sigma inside mapp= ings document > > pros: Sigma and final sigma will not be mapped contrary to users' expec= tation. > > cons: It will be necessary to update this document to follow unicode's = updated version. > > > > (b) Leave it to unicode's definition > > pros: It is not necessary to define extra mapping table for sigma and f= inal sigma. > > cons: Unless unicode is updated and a new definition to map both sigma = and final sigma**has been added, > > final sigma will be mapped to sigma. > > > > options: > > (A) Support the above (a) > > (B) Support the above (b) > > > > I would appreciate your comment. >=20 > I support (B). >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From internet-drafts@ietf.org Mon Feb 10 08:49:54 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E1E1A031B; Mon, 10 Feb 2014 08:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg2cviwvs6CX; Mon, 10 Feb 2014 08:49:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A231A06E4; Mon, 10 Feb 2014 08:49:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210164951.31531.29161.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 08:49:51 -0800 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-14.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:49:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-14.txt Pages : 64 Date : 2014-02-10 Abstract: Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Mon Feb 10 08:53:08 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2A1A06D3 for ; Mon, 10 Feb 2014 08:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQQFllnNiKPc for ; Mon, 10 Feb 2014 08:53:07 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CED471A06F0 for ; Mon, 10 Feb 2014 08:53:05 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C33D34032A; Mon, 10 Feb 2014 09:53:05 -0700 (MST) Message-ID: <52F903F1.60405@stpeter.im> Date: Mon, 10 Feb 2014 09:53:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140210164951.31531.29161.idtracker@ietfa.amsl.com> In-Reply-To: <20140210164951.31531.29161.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-14.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:53:09 -0000 Updates to address recent list discussion about the mappings text. Alexey pointed out a small editorial error, too, but it has no impact on the meaning of the text, so I think we'll fix that later in the publication process. Thanks! Peter On 2/10/14, 9:49 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols > Authors : Peter Saint-Andre > Marc Blanchet > Filename : draft-ietf-precis-framework-14.txt > Pages : 64 > Date : 2014-02-10 > > Abstract: > Application protocols using Unicode characters in protocol strings > need to properly prepare such strings in order to perform valid > comparison operations (e.g., for purposes of authentication or > authorization). This document defines a framework enabling > application protocols to perform the preparation and comparison of > internationalized strings ("PRECIS") in a way that depends on the > properties of Unicode characters and thus is agile with respect to > versions of Unicode. As a result, this framework provides a more > sustainable approach to the handling of internationalized strings > than the previous framework, known as Stringprep (RFC 3454). This > document obsoletes RFC 3454. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-framework-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-14 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Wed Feb 12 17:51:50 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAFF1A00AB; Wed, 12 Feb 2014 17:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5NHuxjbnq8N; Wed, 12 Feb 2014 17:51:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE44D1A00B6; Wed, 12 Feb 2014 17:51:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213015147.4325.15881.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 17:51:47 -0800 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:51:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Mapping characters for PRECIS classes Authors : Yoshiro YONEYA Takahiro Nemoto Filename : draft-ietf-precis-mappings-07.txt Pages : 11 Date : 2014-02-12 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. Case mapping is defined because many protocols perform case-sensitive or case-insensitive string comparison and so preparation of the string is mandatory. The Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describes mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other specials that can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as an additional mapping and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-mappings-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From t.nemo10@kmd.keio.ac.jp Wed Feb 12 18:03:46 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB91A00BE for ; Wed, 12 Feb 2014 18:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqci6alUvCpg for ; Wed, 12 Feb 2014 18:03:43 -0800 (PST) Received: from mail.kmd.keio.ac.jp (mail.kmd.keio.ac.jp [IPv6:2001:200:167:2e90::164]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA41A00B2 for ; Wed, 12 Feb 2014 18:03:40 -0800 (PST) Received: from [192.168.0.7] (i114-185-245-87.s41.a012.ap.plala.or.jp [114.185.245.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id A6A177FBD3 for ; Thu, 13 Feb 2014 11:03:35 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/signed; boundary="Apple-Mail=_B9E3B268-7780-4D26-A02C-966A7D877ED1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <2042B01B-5A19-4E63-AA71-8FE2BC550C8C@kmd.keio.ac.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Thu, 13 Feb 2014 11:03:34 +0900 References: <20140124125552.1466.22416.idtracker@ietfa.amsl.com> <52E2714A.3030208@stpeter.im> <52F1631C.3050908@isode.com> <52F17FC2.3090103@stpeter.im> <52F21547.8030806@isode.com> <54FFC4FD-6D68-4387-A809-3C9FA7668D38@kmd.keio.ac.jp> <52F2DA22.3000403@stpeter.im> <8D3D17ACE214DC429325B2B98F3AE712027105AD96@MX15A.corp.emc.com> To: "precis@ietf.org" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712027105AD96@MX15A.corp.emc.com> X-Mailer: Apple Mail (2.1510) Subject: Re: [precis] I-D Action: draft-ietf-precis-mappings-06.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:03:46 -0000 --Apple-Mail=_B9E3B268-7780-4D26-A02C-966A7D877ED1 Content-Type: multipart/alternative; boundary="Apple-Mail=_9484F235-6BE3-4E9A-8E50-5026EDA97AED" --Apple-Mail=_9484F235-6BE3-4E9A-8E50-5026EDA97AED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David-san Thank you for your comment. I have updated the mappings document to reflect comments received form = you. There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-07 Regards, Nemo On 2014/02/10, at 23:41, "Black, David" wrote: > I agree with Peter. For (1), the double-mapping behavior (local case > mapping then PRECIS case mapping) for German eszett that occurred with > the old approach was both subtle and non-obvious because it was spread > across two drafts. The new approach documents this behavior = completely > in the mappings draft, which is a welcome clarity improvement. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Peter = Saint-Andre >> Sent: Wednesday, February 05, 2014 7:41 PM >> To: Takahiro Nemoto; precis@ietf.org >> Subject: Re: [precis] Fwd: I-D Action: = draft-ietf-precis-mappings-06.txt >>=20 >> On 2/5/14, 7:17 AM, Takahiro Nemoto wrote: >>> Dear all, >>>=20 >>> Peter-san, Alexey-san, thank you for your quick response. >>>=20 >>> If you have any comments for open issues in mappings-06, I would = like to hear about it. >>> These comments will be reflected on the updated mappings document as = -07 before cut off date(2/14), >>> as it will influence the framework document. >>>=20 >>> There are two points that have not reached a consensus in the = mappings document . >>>=20 >>> (1) Define local case mapping as an alternative to case mapping in = the PRECIS framework >>> pros: German eszett, Turkish dotless i, etc. will not be mapped = contrary to the users' expectation. >>> cons: It is necessary to modify the framework document. >>>=20 >>> options: >>> (A) Support the change of -06 >>> (B) Don't support the change of -06, and restore the algorithm of = -05 >>=20 >> I think -06 is fine, so I support (A). >>=20 >>> (2) Way to deal with the context dependent mapping for both Greek = sigma and final sigma. >>> (a) Define extra mapping table for sigma and final sigma inside = mappings document >>> pros: Sigma and final sigma will not be mapped contrary to users' = expectation. >>> cons: It will be necessary to update this document to follow = unicode's updated version. >>>=20 >>> (b) Leave it to unicode's definition >>> pros: It is not necessary to define extra mapping table for sigma = and final sigma. >>> cons: Unless unicode is updated and a new definition to map both = sigma and final sigma**has been added, >>> final sigma will be mapped to sigma. >>>=20 >>> options: >>> (A) Support the above (a) >>> (B) Support the above (b) >>>=20 >>> I would appreciate your comment. >>=20 >> I support (B). >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_9484F235-6BE3-4E9A-8E50-5026EDA97AED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://t= ools.ietf.org/html/draft-ietf-precis-mappings-07

<= div>Regards,
Nemo

On 2014/02/10, at 23:41, = "Black, David" <david.black@emc.com> = wrote:

I agree with Peter.  For (1), the double-mapping = behavior (local case
mapping then PRECIS case mapping) for German = eszett that occurred with
the old approach was both subtle and = non-obvious because it was spread
across two drafts.  The new = approach documents this behavior completely
in the mappings draft, = which is a welcome clarity = improvement.

Thanks,
--David


-----Original Message-----
From: precis = [mailto:precis-bounces@ietf.org] = On Behalf Of Peter Saint-Andre
Sent: Wednesday, February 05, 2014 = 7:41 PM
To: Takahiro Nemoto; precis@ietf.org
Subject: Re: = [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt

On = 2/5/14, 7:17 AM, Takahiro Nemoto wrote:
Dear = all,

Peter-san, Alexey-san, thank you for your quick = response.

If you have any comments for open issues in = mappings-06, I would like to hear about it.
These comments will be = reflected on the updated mappings document as -07 before cut off = date(2/14),
as it  will influence the framework = document.

There are two points that have not reached a consensus = in the mappings document .

(1) Define local case mapping as an = alternative to case mapping in the PRECIS framework
pros: =  German eszett, Turkish dotless i, etc. will not be mapped contrary = to the users' expectation.
cons: It is necessary to modify the = framework document.

options:
(A) Support the change of = -06
(B) Don't support the change of -06, and restore the algorithm of = -05

I think -06 is fine, so I support = (A).

(2) Way to deal with the context = dependent mapping for both Greek sigma and final sigma.
=   (a) Define extra mapping table for sigma and final sigma = inside mappings document
pros: Sigma and final sigma will not be = mapped contrary to users' expectation.
cons: It will be necessary to = update this document to follow unicode's updated version.

=   (b) Leave it to unicode's definition
pros: It is not = necessary to define extra mapping table for sigma and final = sigma.
cons: Unless unicode is updated and a new definition to map = both sigma and final sigma**has been added,
=       final sigma will be mapped to = sigma.

options:
(A) Support the above (a)
(B) Support the = above (b)

I would appreciate your comment.

I = support (B).

Peter

--
Peter Saint-Andre
https://stpeter.im/
__________________= _____________________________
precis mailing = list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

_______________________________________________
preci= s mailing list
precis@ietf.org
https://www.ietf.or= g/mailman/listinfo/precis

= --Apple-Mail=_9484F235-6BE3-4E9A-8E50-5026EDA97AED-- --Apple-Mail=_B9E3B268-7780-4D26-A02C-966A7D877ED1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS/Cf2AAoJEJk7o/xhVana7REIAJTmV7oBib06/6wnqccD3OZs PfBPVmfqxfg+nkXC5hXPcpPkfPthnsxzh08v1eWAq2AiOkjqqym6N8cd+WKd5UsQ Z5dbOVbUWfU6RfrAi1C6ClkJZQ7lDBSEJAsG7NWFnl5Axx/XWYIImSvxkxzHZryp uhs04tvjVGovu9r2p1U+ikjuMzvVxSByqDU4YN0ff7i3ee/YuGN6oAnI8khlCXWK mAC7EeH+w24+SMeaUqt9UZdz6Vvi8TcHdL93YZvzFHvXbCx35X5vrrsD7EaRqmES P3gjEBRPgfhALbW3d9PKbFymLmudiesetsXlrKmkTSw2f5pvQhI0Fls19op/6FM= =jth4 -----END PGP SIGNATURE----- --Apple-Mail=_B9E3B268-7780-4D26-A02C-966A7D877ED1-- From stpeter@stpeter.im Wed Feb 12 18:10:46 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65F51A00BE for ; Wed, 12 Feb 2014 18:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0an7GWz7xlJS for ; Wed, 12 Feb 2014 18:10:44 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5731A00BA for ; Wed, 12 Feb 2014 18:10:44 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EACC403AE; Wed, 12 Feb 2014 19:10:43 -0700 (MST) Message-ID: <52FC29A2.20203@stpeter.im> Date: Wed, 12 Feb 2014 19:10:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140213015147.4325.15881.idtracker@ietfa.amsl.com> In-Reply-To: <20140213015147.4325.15881.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [precis] I-D Action: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:10:46 -0000 I've reviewed the changes it they look good. When I have more time (perhaps next week), I'll read the entire document again carefully and comment further if needed. On 2/12/14, 6:51 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > Title : Mapping characters for PRECIS classes > Authors : Yoshiro YONEYA > Takahiro Nemoto > Filename : draft-ietf-precis-mappings-07.txt > Pages : 11 > Date : 2014-02-12 > > Abstract: > The framework for preparation and comparison of internationalized > strings ("PRECIS") defines several classes of strings for preparation > and comparison. Case mapping is defined because many protocols > perform case-sensitive or case-insensitive string comparison and so > preparation of the string is mandatory. The Internationalized Domain > Names in Applications (IDNA) and the PRECIS problem statement > describes mappings for internationalized strings that are not limited > to case, but include width mapping and mapping of delimiters and > other specials that can be taken into consideration. This document > provides guidelines for authors of protocol profiles of the PRECIS > framework and describes several mappings that can be applied between > receiving user input and passing permitted code points to > internationalized protocols. The mappings described here are > expected to be applied as an additional mapping and alternative to > Unicode Default Case Folding as case mapping in the PRECIS framework. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-mappings-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-mappings-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Sun Feb 16 18:11:48 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5D1A030E for ; Sun, 16 Feb 2014 18:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykWYuWOb8Rrz for ; Sun, 16 Feb 2014 18:11:44 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61F1A030C for ; Sun, 16 Feb 2014 18:11:44 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s1H2BfJu030262 for ; Mon, 17 Feb 2014 11:11:41 +0900 X-AuditID: ac120820-b7f196d00000167f-e0-53016fdc5974 Received: from NOTE701 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 9A.C4.05759.CDF61035; Mon, 17 Feb 2014 11:11:40 +0900 (JST) Date: Mon, 17 Feb 2014 11:11:38 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20140217111138.5ca80018e76b482231d9dc37@jprs.co.jp> In-Reply-To: <52F903F1.60405@stpeter.im> References: <20140210164951.31531.29161.idtracker@ietfa.amsl.com> <52F903F1.60405@stpeter.im> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsWyRoiFT/dOPmOwwfMfZha7vv9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtMT7YIl4hW7+lUbGJuFuhg5OSQETCT+bm5mgbDFJC7cW8/W xcjFISRwnFHi6/qDTCAJFgFVidbtj1hBbDYBA4lfy36DxUUEhCVu3V4IFhcWcJFY/20hcxcj BwevgIPEsiPVIGFOAQ2J0+1zwMqFBOIluq5cY4XYZSFxoamDHaJcUOLvDmGQMLOAlsTDX7dY IGx5ie1v5zBPYOSbhVA1C0nVLCRVCxiZVzHK5Kel6Ran5qUU56YbGOqVVObrZRUUFeslg+hN jOCw4lDYwTjjlMEhRgEORiUe3upX/4OEWBPLiitzDzFKcjApifJuz2AMFuJLyk+pzEgszogv Ks1JLT7EKMHBrCTC6x4HlONNSaysSi3Kh0lJc7AoifMe/3MmUEggPbEkNTs1tSC1CCYrw8Gh JMGbngfUKFiUmp5akZaZU4KQZuLgBBnOAzT8JEgNb3FBYm5xZjpE/hSjpJQ47wWQhABIIqM0 D673FaM40AvCvKdBsjzAFAHX9QpoIBPQwFWn/wYBDSxJREhJNTBKfq85dWAVg5XsEZ6nqbkH NwV+/s37aDFf+aSXk17nbDQzux61g2vCDBXDf+eElqa79DRFSWT+enPtfqbpezUP45rIF0tq Px0N2KhQ9HxOX4KUScJUkwz5wDk/mhiP57Z5vHvfZipw+UTQP/Mu12173XxSQovqWlOjHVLZ dP2X51vX+tzYfUiJpTgj0VCLuag4EQBq1utzzgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ip3DA1F7wcwcduyN1hkXFTKRHVE Subject: Re: [precis] I-D Action: draft-ietf-precis-framework-14.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:11:46 -0000 Dear all, I'm pleased to let you know that WG co-chairs requested to publish the document to the IESG. Regards, -- Yoshiro YONEYA On Mon, 10 Feb 2014 09:53:05 -0700 Peter Saint-Andre wrote: > Updates to address recent list discussion about the mappings text. > > Alexey pointed out a small editorial error, too, but it has no impact on > the meaning of the text, so I think we'll fix that later in the > publication process. > > Thanks! > > Peter > > On 2/10/14, 9:49 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. > > > > Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols > > Authors : Peter Saint-Andre > > Marc Blanchet > > Filename : draft-ietf-precis-framework-14.txt > > Pages : 64 > > Date : 2014-02-10 > > > > Abstract: > > Application protocols using Unicode characters in protocol strings > > need to properly prepare such strings in order to perform valid > > comparison operations (e.g., for purposes of authentication or > > authorization). This document defines a framework enabling > > application protocols to perform the preparation and comparison of > > internationalized strings ("PRECIS") in a way that depends on the > > properties of Unicode characters and thus is agile with respect to > > versions of Unicode. As a result, this framework provides a more > > sustainable approach to the handling of internationalized strings > > than the previous framework, known as Stringprep (RFC 3454). This > > document obsoletes RFC 3454. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-precis-framework-14 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-14 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > precis mailing list > > precis@ietf.org > > https://www.ietf.org/mailman/listinfo/precis > > > > > -- > Peter Saint-Andre > https://stpeter.im/ > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From nobody Mon Feb 17 23:14:17 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26C1A04E1 for ; Mon, 17 Feb 2014 23:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_4hc_Cu2ga2 for ; Mon, 17 Feb 2014 23:14:13 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 948AF1A0437 for ; Mon, 17 Feb 2014 23:14:13 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s1I7E9nM027193 for ; Tue, 18 Feb 2014 16:14:09 +0900 X-AuditID: ac120820-b7f196d00000167f-51-530308411a98 Received: from NOTE701 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 8C.AD.05759.14803035; Tue, 18 Feb 2014 16:14:09 +0900 (JST) Date: Tue, 18 Feb 2014 16:14:06 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsWyRoiFT9eRgznY4PVEGYtd3/+wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+aybuaCpWwVMzsaGRsYZ7J2MXJySAiYSBz418QGYYtJXLi3 Hsjm4hASOM4o8e74FhaQBIuAqsSWT4uYQGw2AQOJX8t+g9kiAsISt24vBBskDBSf2XUVyObg 4BVwkGjt1YCYaSFxoamDHSIsKPF3hzBImFlAS+Lhr1ssELa8xPa3c5gnMPLMQqiahaRqFpKq BYzMqxhl8tPSdItT81KKc9MNDPVKKvP1sgqKivWSQfQmRnCocCjsYJxxyuAQowAHoxIPL7M2 U7AQa2JZcWXuIUZJDiYlUV5rduZgIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8d+4DlfOmJFZW pRblw6SkOViUxHmP/zkTKCSQnliSmp2aWpBaBJOV4eBQkuD1ARkqWJSanlqRlplTgpBm4uAE Gc4DNFwBpIa3uCAxtzgzHSJ/ilFSSpz3BRtQQgAkkVGaB9f7ilEc6AVh3tcgWR5g3MN1vQIa yAQ00GsvI8jAkkSElFQD481ZFUG3zjY4sZ/i1G0K/Cmrone8ijutNPOtzrZzdcplXJuuAMNy p1JMMnPBKl73d6xHJ59WuffSvVa+dqe262JZi6z5c1t/znbzt9H4rPng2aW3/6fON7n1Ku7O ptJrLi1GcyeGpUzcMXPjsRtb19gxyit01h17d79H+sCCRZk/jrBqZZyaoMRSnJFoqMVcVJwI ADfps4q4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/precis/85ZStTqsMB42SZ_5hKtW88xkek8 Subject: [precis] WGLC: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:14:15 -0000 Dear all, As discussed on the mailing list in recent months, the latest mappings document seemed to address issues raised in Vancouver, and seemed to have good relation with the latest framework well, so co-chairs decided to perform WG LC again to the document. This message starts two weeks Working Group Last Call (WGLC) on draft-ietf-precis-mappings-07.txt (Mapping characters for PRECIS classes). Please review the document and send comments to the list (precis@ietf.org), the co-chairs (precis-chairs@tools.ietf.org), or the authors (draft-ietf-precis-mappings@tools.ietf.org) by the end of WGLC. The WGLC start at on Tuesday, Feb 18th and will end on Monday, Mar 3rd. Regards, -- Marc & Yoshiro, co-chairs From nobody Tue Feb 18 02:40:09 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410D1A062B for ; Tue, 18 Feb 2014 02:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl1av3rIjnoc for ; Tue, 18 Feb 2014 02:40:05 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0431A0653 for ; Tue, 18 Feb 2014 02:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1392720001; d=isode.com; s=selector; i=@isode.com; bh=yXrS5DmOHX47bRdMzsVct2Guk3TJJey91/Nz8D5kue0=; 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=HgGMR6mKNjmCO48MzlNIayvoa6BPKMfSM/wzOkEwb0CanufQC5m0h+OzFiETv7lsMAHPYf zWgrw6iBcK5RLfu8AVTM/FR+Z19oCbB4+CHlIOXh1PG0drAvQUujfiwosOw8nYnurPI29a G+dWXlcIEWrl9Lj/k4ZZasQxd7Bm89U=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 Feb 2014 10:40:01 +0000 Message-ID: <5303387E.4060700@isode.com> Date: Tue, 18 Feb 2014 10:39:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Peter Saint-Andre , "precis@ietf.org" References: <52F2D98D.4090500@stpeter.im> In-Reply-To: <52F2D98D.4090500@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/nGhIizG0_LYzyGm2lHJuvrbmeAs Subject: Re: [precis] framework dependency on mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:40:07 -0000 On 06/02/2014 00:38, Peter Saint-Andre wrote: > The framework document has a normative dependency on the mappings > document. I see 3 options: > > (1) change the reference to informative > > (2) change the mappings document to standards track > > (3) keep the mappings document informational and add to the list of > exceptions for dependency checking > > Does the WG have a preference? I like (3) best, followed by (2) and > then (1). I think I slightly prefer (2) over (3) over (1), but not a big deal for me either way. From nobody Tue Feb 18 05:56:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE551A01DE for ; Tue, 18 Feb 2014 05:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STgsUCqGVEG6 for ; Tue, 18 Feb 2014 05:55:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E26571A01DC for ; Tue, 18 Feb 2014 05:55:56 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 79ABD403BB; Tue, 18 Feb 2014 06:55:53 -0700 (MST) Message-ID: <53036668.7000409@stpeter.im> Date: Tue, 18 Feb 2014 06:55:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alexey Melnikov , "precis@ietf.org" References: <52F2D98D.4090500@stpeter.im> <5303387E.4060700@isode.com> In-Reply-To: <5303387E.4060700@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/lrm599l6Zo-gKncN1xLzg_inZ3M Subject: Re: [precis] framework dependency on mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:55:58 -0000 On 2/18/14, 3:39 AM, Alexey Melnikov wrote: > On 06/02/2014 00:38, Peter Saint-Andre wrote: >> The framework document has a normative dependency on the mappings >> document. I see 3 options: >> >> (1) change the reference to informative >> >> (2) change the mappings document to standards track >> >> (3) keep the mappings document informational and add to the list of >> exceptions for dependency checking >> >> Does the WG have a preference? I like (3) best, followed by (2) and >> then (1). > > I think I slightly prefer (2) over (3) over (1), but not a big deal for > me either way. I do, too. Peter From nobody Tue Feb 18 16:38:33 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7339D1A010A for ; Tue, 18 Feb 2014 16:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4lF4PbJh1EE for ; Tue, 18 Feb 2014 16:38:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1F1A0013 for ; Tue, 18 Feb 2014 16:38:28 -0800 (PST) Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C6D6B403BB; Tue, 18 Feb 2014 17:38:24 -0700 (MST) Message-ID: <5303FCFF.9090206@stpeter.im> Date: Tue, 18 Feb 2014 17:38:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> In-Reply-To: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/gvP7MD4k9c8lfj8t5F9kmrKeblw Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:38:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2014 12:14 AM, Yoshiro YONEYA wrote: > Dear all, > > As discussed on the mailing list in recent months, the latest > mappings document seemed to address issues raised in Vancouver, and > seemed to have good relation with the latest framework well, so > co-chairs decided to perform WG LC again to the document. > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-mappings-07.txt (Mapping characters for PRECIS > classes). > > > Please review the document and send comments to the list > (precis@ietf.org), the co-chairs (precis-chairs@tools.ietf.org), or > the authors (draft-ietf-precis-mappings@tools.ietf.org) by the end > of WGLC. Overall it looks very good. Here are a few relatively small comments... First, I think this document should be standards track. It defines technical rules that could be subject to testing and further improvement, and thus does not seem completely informational to me. ABSTRACT The mappings described here are expected to be applied as an additional mapping and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. I think this would be a bit clearer: The delimiter mapping and special mapping rules described here are applied as "additional mappings" beyond those defined in the PRECIS framework, whereas the "local case mapping" rule is applied as an alternative to Unicode Default Case Folding, which is the case mapping rule specified in the PRECIS framework. The same text can be found in Section 1. SECTION 2.3 I suggest... OLD characters, targeting characters which mapping depends on locale or locale and context. NEW characters, targeting characters for which case mapping depends on locale or on locale and context. There is a small typo here: "if the case of Turkish" should be "in the case of Turkish". (There are also a few instances of subject-verb disagreement and such, but I assume those will be fixed during processing by the RFC Editor team.) This section says: This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping. I have been thinking about this further. The PRECIS framework says that Unicode Default Case Folding is RECOMMENDED. The framework also says that a PRECIS profile needs to specify which case mapping rule to apply. The choices are Unicode Default Case Folding, the "local case mapping" rule from this document, or something else. The nature of this "something else" is not mentioned. I think it might be simpler to say "either use Unicode Default Case Folding as recommended by the PRECIS framework, or use local case mapping as defined by the PRECIS mapping document, but never both". If we go in that direction, then I would suggest the following modified text: This local case mapping provides an alternative to Unicode Default Case Folding, which is recommended by the PRECIS framework. Because these methods are strictly alternatives, if a PRECIS profile specifies the use of local case mapping then it MUST NOT also apply Unicode Default Case Folding. APPENDIX A.1 I am not quite sure about the purpose of this table, but in any case I suggest the following clarification. OLD This table is the mapping type list for each protocol. NEW This table is the mapping type list for each protocol mentioned in the PRECIS problem statement document [RFC6885]. Thanks! Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTA/z/AAoJEOoGpJErxa2p/BkP/2+RvFAl9zTWfsQRL89YqTee jbiCTnOdBo+EF0xTkDM4XhXV+dYOgsWCsoJxdWo7a5fONJ0ARIbbRhy+WSVHLgdA XJc9wBMpMZO6zyC99nSFQMAP8ABMlgP0yTolG5Qjj1FWnHjRrBBMNQT+RXxptcbw I0+yarsRehbUW1/mvS1WobEhpEQ/wkYmSEf47aJGbyszLd8DQY3yjOCRw4o9VVRz I9sC8DlVmEnJ8zhIWIKccpcHAPbOOq5ypHetFb6i1Ydj+q6ti+7Wu3RKj0SPjQbi dCt7SpRKn20/FmgBMfTY4zdFrpKyPFKQoWpj6Ys/rEt2reX8G4bbZuaiecrOBlys hQs7uh2c08CAKmkF4gDwCx7m5LDKZAzoOKRDYC2TjNIvDsdnF21zpvDSnN2LebuI eR1l2rNnQe7oaw3lrI4+nja+IVCppBcmQcDUpuj3dTonMrOFWzYEk47FukPz1gcc H7mikM35eqAFjeUeS87cqsixTGAmzJXEiwBhqUj7RM5nO/fKd56YfmkxAsOLmkho 2NOxgm1GJDmrSimuAJ5iKc7WCTxCeF2KBvEHt6mDgFQgidYHqI1qwpI9Ftzwhvw+ JRN67kKaso+kp900FIuW6FM2sYf55Uu6qB1WQ4dUpBX2wzbNy1iyMIy6o9t1WnRV SwmezOR7CJ5VJUHWqyt2 =OLgj -----END PGP SIGNATURE----- From nobody Thu Feb 20 15:35:06 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D406E1A0296 for ; Thu, 20 Feb 2014 15:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqF0QfvKM0Xr for ; Thu, 20 Feb 2014 15:35:04 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 737CB1A0340 for ; Thu, 20 Feb 2014 15:35:04 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6671A4042D; Thu, 20 Feb 2014 16:35:00 -0700 (MST) Message-ID: <53069123.5050305@stpeter.im> Date: Thu, 20 Feb 2014 16:34:59 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "precis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/WdLu8l01DACtPA7P_lc_i18Ph6c Subject: [precis] IETF 89 agenda? X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 23:35:06 -0000 Since we're making such good progress, I'm wondering what we might talk about during the PRECIS WG session at IETF 89. :-) What open issues do we still need to work on together? I'd be curious what other folks in the working group think... Peter From nobody Mon Feb 24 22:05:15 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCB1A047C for ; Mon, 24 Feb 2014 22:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.96 X-Spam-Level: * X-Spam-Status: No, score=1.96 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEuC53-5kS3k for ; Mon, 24 Feb 2014 22:05:12 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id BCB651A046F for ; Mon, 24 Feb 2014 22:05:11 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s1P659Tl000721 for ; Tue, 25 Feb 2014 15:05:09 +0900 X-AuditID: ac120820-b7f196d00000167f-1a-530c329489b3 Received: from NOTE772 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 3C.86.05759.4923C035; Tue, 25 Feb 2014 15:05:08 +0900 (JST) Date: Tue, 25 Feb 2014 15:05:08 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20140225150508.373d2224369432b617c8f598@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsWyRoiFT3eKEU+wwcwjNha7vv9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr5TL9gLXjBWvHnxnK2B8RBjFyMnh4SAicT/tkdMELaYxIV7 69m6GLk4hASOM0q8/T8FrIhFQFXi/dS3YDabgIHEr2W/wRpEBIQlbt1eyApiCwsoS3xbcY4N xOYVcJC4cGQjM8RQC4kLTR3sXYwcQHFBib87hEHCzAJaEg9/3WKBsOUltr+dwzyBkWcWQtUs JFWzkFQtYGRexSiTn5amW5yal1Kcm25gqFdSma+XVVBUrJcMojcxgoOFQ2EH44xTBocYBTgY lXh4JxVzBwuxJpYVV+YeYpTkYFIS5b1iwBMsxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3RAQo x5uSWFmVWpQPk5LmYFES5z3+50ygkEB6YklqdmpqQWoRTFaGg0NJgjfSEKhRsCg1PbUiLTOn BCHNxMEJMpwHaDgLSA1vcUFibnFmOkT+FKOklDjvMZCLBEASGaV5cL2vGMWBXhDmZQNp4wFG PlzXK6CBTEADj0qDDSxJREhJNTBmftXevjpqm81xZnEGkdnH83fPaVa393h4pPZSXon6wnBP d6l15f8rY8rXy0xJnrOUn+EVo3VKilq7jm0tS2Tti98CM9RLfUpbE6YKfDAPmsT0LXdpvdC6 MzEbH8Xs4dhR9M1UWY55tuEhxdpXXmeSBFm4T77KsTK7+uRAuuiTje7bf6TpxyqxFGckGmox FxUnAgD3TmMVuQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/precis/WTLNwbu3lfHjpqr1Dh1Za529Gn8 Subject: [precis] IETF89 London draft agenda X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 06:05:14 -0000 Dear all, Draft agenda for IETF 89 London has uploaded to material page. Please check and give comments/additions/changes to co-chairs. Marc & Yoshiro, co-chairs From nobody Wed Feb 26 00:24:33 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E271A00A7 for ; Wed, 26 Feb 2014 00:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.761 X-Spam-Level: ** X-Spam-Status: No, score=2.761 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV5Gy-qoWz7E for ; Wed, 26 Feb 2014 00:24:23 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 68C751A0079 for ; Wed, 26 Feb 2014 00:24:23 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s1Q8OLMN020537 for ; Wed, 26 Feb 2014 17:24:21 +0900 X-AuditID: ac120820-b7f196d00000167f-95-530da4b43531 Received: from NOTE772 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 7C.9D.05759.4B4AD035; Wed, 26 Feb 2014 17:24:21 +0900 (JST) Date: Wed, 26 Feb 2014 17:24:21 +0900 From: Yoshiro YONEYA To: precis@ietf.org Message-Id: <20140226172421.231bb016c80f8f03429a6eb1@jprs.co.jp> In-Reply-To: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> References: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsWyRoiFT3frEt5gg0NL+Sx2ff/D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJvNd9kK7nNW7Hw8i7mB8RN7FyMnh4SAicSmGx/ZIGwxiQv3 1oPZQgLHGSVm9oPVsAioSvQc/M0IYrMJGEj8WvabCcQWERCWuHV7ISuILSxgK3Fx1mmwel4B B4k5WzaBxTkFHCUu/W5lhZjpIPGxuY0ZYpeFxIWmDqB6DqB6QYm/O4RBwswCWhIPf91igbDl Jba/ncM8gZFvFkLVLCRVs5BULWBkXsUok5+WplucmpdSnJtuYKhXUpmvl1VQVKyXDKI3MYJD i0NhB+OMUwaHGAU4GJV4eHO5eYOFWBPLiitzDzFKcjApifIqLwAK8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuF9XQGU401JrKxKLcqHSUlzsCiJ8x7/cyZQSCA9sSQ1OzW1ILUIJivDwaEkwZuw CKhRsCg1PbUiLTOnBCHNxMEJMpwHaHgzSA1vcUFibnFmOkT+FKOklDhv8mKghABIIqM0D673 FaM40AvCvA8WAmV5gGkCrusV0EAmoIFHpXlABpYkIqSkGhirf73x3Zt1VdHttLi+id3H3cwq m2eK8l07oP/KOOuA1pyU5v/5skKTJ99eeW3rA9E/c1sW9R3axByrWuMY/vLbwQ63t5OLgrh1 2S/tPf/R/3a12LHwajWT96tXuT7jnFM1La31F1vL5uCboR/vmEhHHvvQYTnV2H7tn0W9zTIu HrrSq91kapYpsRRnJBpqMRcVJwIATTMsINACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/precis/E72LPztqp_ficbhnlkEeUkU7hwc Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 08:24:26 -0000 Dear all, This is reminder. The WG LC will end next week. Please review the document and give your feedback. Regards, -- Marc & Yoshiro, co-chairs On Tue, 18 Feb 2014 16:14:06 +0900 Yoshiro YONEYA wrote: > Dear all, > > As discussed on the mailing list in recent months, the latest mappings > document seemed to address issues raised in Vancouver, and seemed to > have good relation with the latest framework well, so co-chairs decided > to perform WG LC again to the document. > > This message starts two weeks Working Group Last Call (WGLC) on > draft-ietf-precis-mappings-07.txt (Mapping characters for PRECIS classes). > > > Please review the document and send comments to the list (precis@ietf.org), > the co-chairs (precis-chairs@tools.ietf.org), or the authors > (draft-ietf-precis-mappings@tools.ietf.org) by the end of WGLC. > > The WGLC start at on Tuesday, Feb 18th and will end on Monday, Mar 3rd. > > Regards, > > -- Marc & Yoshiro, co-chairs > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > From nobody Wed Feb 26 09:02:56 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEE71A0132 for ; Wed, 26 Feb 2014 09:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJC3YV4j-IC8 for ; Wed, 26 Feb 2014 09:02:46 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id D59F21A0077 for ; Wed, 26 Feb 2014 09:02:45 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so2643254qaq.39 for ; Wed, 26 Feb 2014 09:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Wz/oB6sG4WaA6WAOKw2gNEYQBX16E/w7T9ETdER+TqY=; b=RMuwB2umq8yAefNYHU0T1jkesf7m2IKpqhFj6o10dkVDHKUB+HERq+Gqfo0JpqJ3G0 Xrha+CeNpQnO2L7Qg+7lSPcSrQiAz0V1ZOsHFdRY9wTtSKvOjDQuG8XSARMFsmmz8yFm hVVoEaHRM6QNk4MUHUIgDWL3SOf+X0CuOk2OBiktLAGS32yNJXjYHop8zKS6PJk80at1 1SF6oAaFVaAZUWbgLm+i1cSstyViV+kye+lwcR1SYr3MJyaTwUMZ0W26yBaEPUkT3ZAb clxqnL0LRfWsAiIUTepvhQtAmDGOT/6xXp1K07BjEA9fFWjY2MxqNjoBqRdb1twUxve1 dl2Q== MIME-Version: 1.0 X-Received: by 10.140.83.203 with SMTP id j69mr816657qgd.42.1393434164481; Wed, 26 Feb 2014 09:02:44 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Wed, 26 Feb 2014 09:02:44 -0800 (PST) In-Reply-To: <20140226172808.3a884bcdf114754dc696b032@jprs.co.jp> References: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> <20140226172808.3a884bcdf114754dc696b032@jprs.co.jp> Date: Wed, 26 Feb 2014 09:02:44 -0800 X-Google-Sender-Auth: dloSACm98h2icST375PwGh2jDLo Message-ID: From: Barry Leiba To: precis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/_1sZo22gAAKl0r3tk_PPu_XM9UA Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 17:02:47 -0000 First, thanks very much for accepting most of my earlier comments. -- General -- We use the term "codepoint" sometimes (and, in the Abstract and Introduction, "code point") to refer to a Unicode character. I suggest that we avoid the term entirely in this document, always call them "characters", and make it clear that "character" always means "Unicode character". -- Section 2.3 -- I find the last paragraph awkwardly worded and, consequently, a bit confusing. I suggest the following: OLD If a codepoint is a target, the case folding method for the codepoint is mapping into lower case as defined in SpecialCasing.txt. On the other hand, if a codepoint is not a target, the case folding method for the codepoint is the same with case mapping in PRECIS framework. This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping. The reason for this is written in the Appendix B. NEW The case folding method for a target character is to map into lower case as defined in SpecialCasing.txt. The case folding method for all other, non-target characters is as specified in Section 4.1.3 of the PRECIS framework. The local case mapping defined here is an alternative to the Unicode Default Case Folding for non-target characters. See Appendix B for more information. END If this suggestion isn't right, please take that as evidence that the existing text is unclear, and try to fix my replacement text to make it correct. Now, I don't understand why you have a short explanation in Appendix B, when you're already using the Turkish "i" example up here in the main section. Why not just edit the eszett text in Appendix B (I think it needs editing for clarity anyway) and put it here as a paragraph in Section 2.3? -- Section 3 -- Are you really saying that the three can be applied in any order, and then suggesting an order, which suggestion can be accepted or ignored as the implementation pleases? Or do you mean to say that this order is specifically recommended, and that implementations shouldn't ignore it? As it's written, it's very wishy-washy, and saying "they could be applied in any order" in one sentence, and "here's an ordering" in the next seems odd. I'd like to see this section tightened up, making the sense of your recommended order clearer. -- Section 4 -- My earlier comments noted the inadequacy of the Security Considerations section, and it hasn't changed since then. It's, therefore, still inadequate. It says it might cause confusion, without explaining why. It doesn't say anything about the security implications of that confusion, nor what anyone could do about it. I really think you need to say something more here. If you disagree, that's fine, but please explain why. -- Barry From nobody Wed Feb 26 13:45:46 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8D61A0289 for ; Wed, 26 Feb 2014 13:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFVXTYFQ9FyX for ; Wed, 26 Feb 2014 13:45:41 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB111A015E for ; Wed, 26 Feb 2014 13:45:41 -0800 (PST) Received: from mx1.yitter.info (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 358EC8A031 for ; Wed, 26 Feb 2014 21:45:39 +0000 (UTC) Date: Wed, 26 Feb 2014 16:45:34 -0500 From: Andrew Sullivan To: precis@ietf.org Message-ID: <20140226214534.GC781@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/precis/BmB1dcd6_kGuooGueW37qBxCwMo Subject: [precis] RFC 2277bis X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:45:42 -0000 Dear colleagues, For some time the IAB's internationalization program has intended to propose updates to RFC 2277. We have a first pass at that. It's at http://tools.ietf.org/html/draft-sullivan-rfc2277-bis-00. I eagerly solicit comments. As you can imagine since it's a -00, there are plenty of rough patches. You can blame me for the rough bits and my co-authors for the reasonable parts. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Feb 26 18:43:24 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE691A036F; Wed, 26 Feb 2014 18:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HZeAKZiXg1R; Wed, 26 Feb 2014 18:43:07 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 157931A071F; Wed, 26 Feb 2014 18:43:06 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id g12so1863125oah.30 for ; Wed, 26 Feb 2014 18:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28ggBlHHr405OJTWYBxva2Wu8ucIe8MnlzOwaJJuTWQ=; b=M89axJ3GJMxiL6NJrlski0QEhzKiHsySrKQJZaMwge09M9+6nGlVEXeabTUroTef8P Xpn/o0ezmoHhXXKtBcF17blSQ4bNL7CNWOnFxvGAx6IvW8od5pbutZts1+VDu3yq7Sb5 Q1UK9n42RGM4u2fG9iuXZBhgxYb9VXs+Ifoi8o1IzE6toTHjzMzFjP9HEacFbspO5HXy 0B1Dh3pB53bzjKvFEAwFgpnbfN/Z0MQkKQT50+DvbAK5rzQRYpJvJ3c21OV1QMF/uZds aPQUSRp7Pk2wkwTBgeMReW8W6vCf45dDmXejuSWnYvp6xDWjkAQdISb/SLx39WakZxH7 8mtA== MIME-Version: 1.0 X-Received: by 10.182.153.41 with SMTP id vd9mr8865obb.87.1393468984565; Wed, 26 Feb 2014 18:43:04 -0800 (PST) Received: by 10.76.190.104 with HTTP; Wed, 26 Feb 2014 18:43:04 -0800 (PST) In-Reply-To: <52FE3CB8.6050502@gmx.de> References: <52FE3CB8.6050502@gmx.de> Date: Thu, 27 Feb 2014 11:43:04 +0900 Message-ID: From: Kaoru Maeda To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013a1046d4a6e204f35a476f Archived-At: http://mailarchive.ietf.org/arch/msg/precis/_yE2yFq6Q0Ecn83vXD0u_SdvoYo Cc: http-auth@ietf.org, Bjoern Hoehrmann , precis@ietf.org Subject: Re: [precis] [http-auth] HTTP Authentication encoding test results X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 02:43:11 -0000 --089e013a1046d4a6e204f35a476f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I tested how Authorization Basic implementations handle Japanese characters= . Tests done in Japanese environment on MacOS X (10.9.2). Safari 7.0.2 (9537.74.9) * If any Japanese Characters (Kanji, Hiragana, etc) exist in either username or password, Safari does not produce any Authorization header at all, even without any error messages. It behaves as if password was incorrect, from the user's point of view. * You might want to try the same with European accented characters above U+00FF. Firefox 27.0.1 * lowest 8 bit of the Unicode code point, 1-byte for each character. Chrome 33.0.1750.117 * UTF-8 precomposed (this is what we expect). CJK characters have problems (except Chrome) in this respect. Japanese users are well familiar with avoiding non-ASCII usernames and passwords. :P Best regards, --=20 Kaoru Maeda Lepidum Co., Ltd. 2014-02-15 0:56 GMT+09:00 Julian Reschke : > On 2014-02-14 16:18, Bjoern Hoehrmann wrote: > >> Hi, >> >> On the German Apache HTTPD users mailing list someone was having >> difficulties using non-ascii characters in HTTP Basic Authentication >> and posted these test results, >> >> TortoiseSVN >> Password: "E EURO D$P=A7=E4=F6=FC123" >> Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Chrome >> Password: "E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3 1/4 123" >> Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3,83,C2,A4,C3, >> 83,C2,B6,C3,83,C2,BC,31,32,33" >> >> Internet Explorer >> Password: "E?D$P=A7=E4=F6=FC123" >> Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Firefox >> Password: "E=ACD$P=A7=E4=F6=FC123" >> Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome >> does double-UTF-8, and IE and Firefox first apply Windows-1252 and then >> UTF-8 on the result. I do recall Firefox doing something worse but could >> not find the bug report when I briefly looked for it... >> > > With my test server, the username "test" and the password "E EURO D$P=A7= =E4=F6=FC123" I > see: > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 >> Firefox/27.0 >> Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 3= 2 >> 33 >> Decoded as ISO-8859-1: test:E=ACD$P=A7=E4=F6=FC123 >> Decoded as UTF-8: test:E?D$P???? >> > > Firefox: the EURO ends up as 0xac, so it appears the lower 8 bits of 20ac > have been sent. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/32.0.1700.107 Safari/537.36 >> Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a= 4 >> c3 b6 c3 bc 31 32 33 >> Decoded as ISO-8859-1: test:E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3 1/4 123 >> Decoded as UTF-8: test:E EURO D$P=A7=E4=F6=FC123 >> > > Chrome: proper UTF-8. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko >> Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 3= 2 >> 33 >> Decoded as ISO-8859-1: test:E?D$P=A7=E4=F6=FC123 >> Decoded as UTF-8: test:E?D$P???? >> > > IE: sends the EURO as 0x80, which probably make sense from their point of > view ;-) > > Best regards, Julian > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e013a1046d4a6e204f35a476f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I tested how Authoriz= ation Basic implementations handle Japanese characters.
Tests don= e in Japanese environment on MacOS X (10.9.2).

Saf= ari 7.0.2 (9537.74.9)
 * If any Japanese Characters (Kanji, Hiragana, etc) exist in eit= her username or password, Safari does not produce any Authorization header = at all, even without any error messages.  It behaves as if password wa= s incorrect, from the user's point of view.
 * You might want to try the same with European accented characte= rs above U+00FF.

Firefox 27.0.1
 * = lowest 8 bit of the Unicode code point, 1-byte for each character.

Chrome 33.0.1750.117
 * UTF-8 precomposed (this i= s what we expect).

CJK characters have problems (e= xcept Chrome) in this respect.
Japanese users are well familiar w= ith avoiding non-ASCII usernames and passwords. :P

Best regards,

-- 
Kaoru Maeda <maeda@lepidum.co.jp>
Lepidum Co., Ltd.



2= 014-02-15 0:56 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>= :
On 2014-02-14 16:18, Bjoern = Hoehrmann wrote:
Hi,

   On the German Apache HTTPD users mailing list someone was havi= ng
difficulties using non-ascii characters in HTTP Basic Authentication
and posted these test results,

   TortoiseSVN
   Password: "E€D$P=A7=E4=F6=FC123"
   Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC= ,31,32,33"

   Chrome
   Password: "E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3¼123&qu= ot;
   Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3= ,83,C2,A4,C3,83,C2,B6,C3,83,C2,BC,31,32,33"

   Internet Explorer
   Password: "E?D$P=A7=E4=F6=FC123"
   Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31= ,32,33"

   Firefox
   Password: "E=ACD$P=A7=E4=F6=FC123"
   Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31= ,32,33"

I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome
does double-UTF-8, and IE and Firefox first apply Windows-1252 and then
UTF-8 on the result. I do recall Firefox doing something worse but could not find the bug report when I briefly looked for it...

With my test server, the username "test" and the password "E= €D$P=A7=E4=F6=FC123" I see:

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.= 0
Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM=3D
Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 32 3= 3
Decoded as ISO-8859-1: test:E=ACD$P=A7=E4=F6=FC123
Decoded as UTF-8: test:E?D$P????

Firefox: the € ends up as 0xac, so it appears the lower 8 bits of 20ac= have been sent.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gec= ko) Chrome/32.0.1700.107 Safari/537.36
Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM=3D<= br> Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a4 c= 3 b6 c3 bc 31 32 33
Decoded as ISO-8859-1: test:E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3¼123
Decoded as UTF-8: test:E€D$P=A7=E4=F6=FC123

Chrome: proper UTF-8.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM=3D
Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 32 3= 3
Decoded as ISO-8859-1: test:E?D$P=A7=E4=F6=FC123
Decoded as UTF-8: test:E?D$P????

IE: sends the € as 0x80, which probably make sense from their point of= view ;-)

Best regards, Julian



_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--089e013a1046d4a6e204f35a476f-- From nobody Fri Feb 28 08:30:56 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961851A032B for ; Fri, 28 Feb 2014 08:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rENP1i6tQ4V9 for ; Fri, 28 Feb 2014 08:30:49 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id E34641A0328 for ; Fri, 28 Feb 2014 08:30:48 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1SGUjhx023392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Feb 2014 11:30:45 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s1SGUjhx023392 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1393605045; bh=hioZnXSqyMTFc4clECIxk5JE9E4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=E3FEASRounrSgpX3f0tTIQRlgBGp2aEja8SFDICAvFbls3Wo39FWU6YVm0rc7cH18 UQV+5M+kjO3MxPnwhu1Wb9vK0s7JLaeFnGA/MuT33XxE/AXDmrD0oWi6Lw/BtG5l3t gg60nR5bVTSCVY3LKRKH006GkGaubPr0LAKdeF8s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s1SGUjhx023392 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 28 Feb 2014 11:30:35 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s1SGUYOH020544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 11:30:34 -0500 Received: from mx15a.corp.emc.com ([169.254.1.167]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Fri, 28 Feb 2014 11:30:34 -0500 From: "Black, David" To: Barry Leiba , "precis@ietf.org" Date: Fri, 28 Feb 2014 11:30:32 -0500 Thread-Topic: [precis] WGLC: draft-ietf-precis-mappings-07.txt Thread-Index: Ac8zFJpE9NKpye84TC2LQadW7dK6MABifKLQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71202729DEB9E@MX15A.corp.emc.com> References: <20140218161406.c8faea2787b1ea5292bd5211@jprs.co.jp> <20140226172808.3a884bcdf114754dc696b032@jprs.co.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/precis/CtQUufa7tMwG3ORTqB84WmP9oTE Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 16:30:52 -0000 First of all, many thanks to the authors for all of the work invested in this draft. =20 Focusing on the case mapping text, I think this sentence in 2.3 is not quite right: The target characters of local case mapping are characters defined in the SpecialCasing.txt [Specialcasing] file in section 3.13 of the Unicode Standard [Unicode]. I read that as requiring that pr=E9cis local case mapping *always use all* of the mappings in the SpecialCasing.txt file, and I don't think that's wanted. While any use of pr=E9cis needs to specify its context-dependencies (e.g., the context is the protocol to which the pr=E9cis profile applies), but locale dependencies are locale-specific [ok, that was obvious :-) ], and protocols are generally locale-independent. I'm not sure what to do about this as interoperability problems are clearly possible when LATIN CAPITAL LETTER I is locale-dependent case folded in Turkish and English locales for the same protocol, but I don't think it's right to specify that all of SpecialCasing.txt always has to be used if any of it is used (that file will change, eventually), so I'd change the above text to: The target characters of local case mapping are selected in a locale-specific manner from the characters defined in the SpecialCasing.txt [Specialcasing] file in section 3.13 of the Unicode Standard [Unicode]. and I'd like to discuss the interoperability implications of locale- dependent local case mapping in the WG meeting. I also found the same concern that Barry found in Section 2.3, namely that the nature of the relationship of "local case mapping" in this draft to the use of Unicode Default Case Folding in the framework draft is unclear. I would go further and make the relationship to Unicode Default Case Folding clear here ... OLD If a codepoint is a target, the case folding method for the codepoint is mapping into lower case as defined in SpecialCasing.txt. On the other hand, if a codepoint is not a target, the case folding method for the codepoint is the same with case mapping in PRECIS framework. This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping. The reason for this is written in the Appendix B. NEW [Barry] The case folding method for a target character is to map into lower case as defined in SpecialCasing.txt. The case folding method for all other, non-target characters is as specified in Section 4.1.3 of the PRECIS framework. The local case mapping defined here is an alternative to the Unicode Default Case Folding for non-target characters. See Appendix B for more information. NEW [David] The case folding method for a target character is to map into lower case as defined in SpecialCasing.txt. The case folding method for all other, non-target characters is as specified in Section 4.1.3 of the PRECIS framework (i.e., Unicode Default Case Folding SHOULD be used for all non-target characters). The local case mapping defined here is an alternative to use of Unicode Default Case Folding for all characters. See Appendix B for more information. END I think Barry also may be off slightly on the use of "non-target" in the last line of his new text (I changed it to "all" in my text above), but this entire area is subtle ... In turn, that leads to this sentence in the abstract (final sentence): The mappings described here are expected to be applied as an additional mapping and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework. Well, the SpecialCasing.txt file is rather small, so most characters get Unicode Default Case Folding applied independent of which case mapping approach is taken. Here's some suggested alternative text for the abstract: This document defines additional mappings for delimiters and characters requiring special protocol-specific treatment, plus a local case mapping that is an alternative to the case mapping in the PRECIS framework document.=20 I see Barry's concern on section 3 (the text in section 3 was clear to me, but I can see how it could be misread). I suggest deleting this sentence for clarity: The mappings described in this document could be applied in any order. so that the following sentence is clearer in context: This section specifies a particular order to minimize the effect of codepoint changes introduced by the mappings. Although, in the latter sentence I'd also change: "minimize the effect of" -> "provide consistent results from" Thanks, --David > -----Original Message----- > From: precis [mailto:precis-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday, February 26, 2014 12:03 PM > To: precis@ietf.org > Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt >=20 > First, thanks very much for accepting most of my earlier comments. >=20 > -- General -- > We use the term "codepoint" sometimes (and, in the Abstract and > Introduction, "code point") to refer to a Unicode character. I > suggest that we avoid the term entirely in this document, always call > them "characters", and make it clear that "character" always means > "Unicode character". >=20 > -- Section 2.3 -- > I find the last paragraph awkwardly worded and, consequently, a bit > confusing. I suggest the following: >=20 > OLD > If a codepoint is a target, the case folding method for the codepoint > is mapping into lower case as defined in SpecialCasing.txt. On the > other hand, if a codepoint is not a target, the case folding method > for the codepoint is the same with case mapping in PRECIS framework. > This local case mapping provides alternative case folding method to > Unicode Default Case Folding as case mapping in the PRECIS framework, > therefore if a PRECIS profile chooses local case mapping, it should > not choose case mapping. The reason for this is written in the > Appendix B. > NEW > The case folding method for a target character > is to map into lower case as defined in SpecialCasing.txt. The > case folding method for all other, non-target characters is as > specified in Section 4.1.3 of the PRECIS framework. > The local case mapping defined here is an alternative to the > Unicode Default Case Folding for non-target characters. > See Appendix B for more information. > END >=20 > If this suggestion isn't right, please take that as evidence that the > existing text is unclear, and try to fix my replacement text to make > it correct. >=20 > Now, I don't understand why you have a short explanation in Appendix > B, when you're already using the Turkish "i" example up here in the > main section. Why not just edit the eszett text in Appendix B (I > think it needs editing for clarity anyway) and put it here as a > paragraph in Section 2.3? >=20 > -- Section 3 -- > Are you really saying that the three can be applied in any order, and > then suggesting an order, which suggestion can be accepted or ignored > as the implementation pleases? Or do you mean to say that this order > is specifically recommended, and that implementations shouldn't ignore > it? As it's written, it's very wishy-washy, and saying "they could be > applied in any order" in one sentence, and "here's an ordering" in the > next seems odd. I'd like to see this section tightened up, making the > sense of your recommended order clearer. >=20 > -- Section 4 -- > My earlier comments noted the inadequacy of the Security > Considerations section, and it hasn't changed since then. It's, > therefore, still inadequate. It says it might cause confusion, > without explaining why. It doesn't say anything about the security > implications of that confusion, nor what anyone could do about it. I > really think you need to say something more here. If you disagree, > that's fine, but please explain why. >=20 > -- > Barry >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis