From stpeter@stpeter.im Fri Apr 12 14:07:56 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1600821F86EA for ; Fri, 12 Apr 2013 14:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qq436-9qVlp for ; Fri, 12 Apr 2013 14:07:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D919D21F8F3A for ; Fri, 12 Apr 2013 14:07:54 -0700 (PDT) Received: by stpeter.im (Postfix, from userid 1006) id 64DD040F5D; Fri, 12 Apr 2013 15:18:09 -0600 (MDT) Date: Fri, 12 Apr 2013 15:18:09 -0600 From: Peter Saint-Andre To: precis@ietf.org Message-ID: <20130412211809.GC18009@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jabber-ID: stpeter@jabber.org User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: [precis] mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2013 21:07:56 -0000 As promised at IETF 86 (and probably IETF 85!), I've reviewed the issues raised by draft-ietf-precis-mappings. I will also send some editorial feedback directly to the authors of that document. 1. Width mapping has now been moved to the framework document, so I think Section 2 and Section 3 of the mappings document can be removed. 2. I think it would be helpful to mention some examples of delimiters other than FULL STOP. 3. This text is a bit confusing: One of the most useful case of delimiter mapping is when FULL STOP character (U+002E) is a delimiter as well as domain name. I am not a DNS expert, but my understanding is that FULL STOP is not part of the domain name but is a delimiter between the labels of a domain name. I think the sentence quoted above means that in certain protocols FULL STOP is used as a delimiter within protocol strings (such as identifiers) in addition to being used as a delimiter between domain name labels. 4. I think we can just mention RFCs 3748, 4013, 4314, and 4518 in Section 4.2 and then remove Appendix B, since it is the responsibility of other specifications to actually define the special mappings (e.g., this is done in draft-ietf-precis-saslprepbis). 5. I think Appendix C could be moved into Section 4.3. 6. The big open issue here is the order of mappings. RFC 5895 defines an order of case mapping, width mapping, NFC, and the IDNA protocol. I'm not sure why we would do width mapping before case mapping in PRECIS, because we want to do local case mapping before non-locale-specific case mapping. Therefore I suggest the following order: 1. Width mapping 2. Additional mappings (draft-ietf-precis-mappings) a. delimiter mapping b. special mapping c. local case mapping 3. Case mapping (i.e., non-local-specific) 4. Normalization 5. PRECIS protocol Does anyone see a reason to move width mapping after case mapping (as in RFC 5895)? For the record, I think we need to specify the order of operations in both draft-ietf-precis-mappings and draft-ietf-precis-framework so that there is no ambiguity. Once we have consensus, I will be happy to update the framework accordingly. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Fri Apr 12 19:32:19 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F54421F8E6D for ; Fri, 12 Apr 2013 19:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBqOLV0hWJeg for ; Fri, 12 Apr 2013 19:32:18 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B172D21F8C98 for ; Fri, 12 Apr 2013 19:32:18 -0700 (PDT) Received: from mx1.yitter.info (li440-116.members.linode.com [50.116.54.116]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 418E28A031; Sat, 13 Apr 2013 02:32:11 +0000 (UTC) Date: Fri, 12 Apr 2013 22:32:08 -0400 From: Andrew Sullivan To: Peter Saint-Andre Message-ID: <20130413023208.GA5403@mx1.yitter.info> References: <20130412211809.GC18009@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130412211809.GC18009@stpeter.im> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: precis@ietf.org Subject: Re: [precis] mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2013 02:32:19 -0000 On Fri, Apr 12, 2013 at 03:18:09PM -0600, Peter Saint-Andre wrote: > > 3. This text is a bit confusing: > > One of the most useful case of delimiter mapping is when FULL STOP > character (U+002E) is a delimiter as well as domain name. > > I am not a DNS expert, but my understanding is that FULL STOP is not > part of the domain name but is a delimiter between the labels of a > domain name. I think the sentence quoted above means that in certain > protocols FULL STOP is used as a delimiter within protocol strings (such > as identifiers) in addition to being used as a delimiter between domain > name labels. I think this feedback is right, but just so that we're clear, it's much worse than the above in DNS names. The dot in a DNS name is not part of the protocol _at all_. In the wire format, labels are delimited conceptually as follows: 3www7example3com0NULL It is only in the presentation format that we use dots as separators. Moreover, we usually but not always leave off the final dot for presentation purposes. So you _can't_ internationalize the protocol separator in the DNS, because it isn't there in the protocol. It's only there when humans look at it. (Schroedinger's separator?) This set of issues, which is quite unusual (perhaps unique to DNS), is also why DNS and IDNA are only a weak model for what should be done in other cases. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Fri Apr 12 19:59:30 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16EB21F8EE6 for ; Fri, 12 Apr 2013 19:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0nbohz1I1Ac for ; Fri, 12 Apr 2013 19:59:30 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 3B97E21F8EB7 for ; Fri, 12 Apr 2013 19:59:30 -0700 (PDT) Received: from [172.31.1.177] (unknown [61.48.217.2]) by mail.frobbit.se (Postfix) with ESMTPSA id 93AE720544; Sat, 13 Apr 2013 04:59:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130413023208.GA5403@mx1.yitter.info> Date: Sat, 13 Apr 2013 10:59:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130412211809.GC18009@stpeter.im> <20130413023208.GA5403@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1503) Cc: precis@ietf.org Subject: Re: [precis] mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2013 02:59:30 -0000 On 13 apr 2013, at 10:32, Andrew Sullivan = wrote: > I think this feedback is right, but just so that we're clear, it's > much worse than the above in DNS names. >=20 > The dot in a DNS name is not part of the protocol _at all_. In the > wire format, labels are delimited conceptually as follows: >=20 > 3www7example3com0NULL >=20 > It is only in the presentation format that we use dots as separators. > Moreover, we usually but not always leave off the final dot for > presentation purposes. So you _can't_ internationalize the protocol > separator in the DNS, because it isn't there in the protocol. It's > only there when humans look at it. (Schroedinger's separator?) >=20 > This set of issues, which is quite unusual (perhaps unique to DNS), is > also why DNS and IDNA are only a weak model for what should be done > in other cases. This is btw one of the things that is much more clear in IDNA2008 than = in IDNA2003. Patrik From t.nemo10@kmd.keio.ac.jp Thu Apr 25 18:50:40 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F221F9776 for ; Thu, 25 Apr 2013 18:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3650JCC6zpz for ; Thu, 25 Apr 2013 18:50:39 -0700 (PDT) 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 AC9DD21F975A for ; Thu, 25 Apr 2013 18:50:36 -0700 (PDT) Received: from [192.168.0.5] (i223-218-59-72.s41.a012.ap.plala.or.jp [223.218.59.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 0753A804E2; Fri, 26 Apr 2013 10:50:33 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_57B07277-FB21-4EB7-85F0-2F235C8C9C6D" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Takahiro Nemoto In-Reply-To: <20130412211809.GC18009@stpeter.im> Date: Fri, 26 Apr 2013 10:50:34 +0900 Message-Id: References: <20130412211809.GC18009@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) Cc: precis@ietf.org Subject: Re: [precis] mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2013 01:50:40 -0000 --Apple-Mail=_57B07277-FB21-4EB7-85F0-2F235C8C9C6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Peter-san, I'm so sorry for my late reply. And thank you for your review. Yoneya-san and I discussed your comments. Our comments inline. On 2013/04/13, at 6:18, Peter Saint-Andre wrote: > As promised at IETF 86 (and probably IETF 85!), I've reviewed the > issues raised by draft-ietf-precis-mappings. I will also send some > editorial feedback directly to the authors of that document. >=20 > 1. Width mapping has now been moved to the framework document, so I > think Section 2 and Section 3 of the mappings document can be removed. We agree. >=20 > 2. I think it would be helpful to mention some examples of delimiters > other than FULL STOP. We are supposing delimiter mapping for width compatible characters=20 that like '@' in mail address and ':' or '/' in URI. Even though it may = be non-existent as for now,=20 but I'm thinking that in the future there may be protocols that use '+', = '-', '<' or '>' as delimiters. >=20 > 3. This text is a bit confusing: >=20 > One of the most useful case of delimiter mapping is when FULL STOP > character (U+002E) is a delimiter as well as domain name. >=20 > I am not a DNS expert, but my understanding is that FULL STOP is not > part of the domain name but is a delimiter between the labels of a > domain name. I think the sentence quoted above means that in certain > protocols FULL STOP is used as a delimiter within protocol strings = (such > as identifiers) in addition to being used as a delimiter between = domain > name labels. That's right. There is no FULL STOP in DNS packet. But when comparing domain name strings outside of DNS protocol,=20 FULL STOPs are used as delimiters and width problem should be = considered. For example, in web browser, FULL STOPs are considered when=20 inputting words in comparing them with the page history list. >=20 > 4. I think we can just mention RFCs 3748, 4013, 4314, and 4518 in > Section 4.2 and then remove Appendix B, since it is the responsibility > of other specifications to actually define the special mappings (e.g., > this is done in draft-ietf-precis-saslprepbis). We agree. >=20 > 5. I think Appendix C could be moved into Section 4.3. Because we thought that it's not proper to move a table=20 that has a unicode version dependency in the section,=20 we place in the Appendix. >=20 > 6. The big open issue here is the order of mappings. RFC 5895 defines = an > order of case mapping, width mapping, NFC, and the IDNA protocol. I'm > not sure why we would do width mapping before case mapping in PRECIS, > because we want to do local case mapping before non-locale-specific = case > mapping. Therefore I suggest the following order: >=20 > 1. Width mapping > 2. Additional mappings (draft-ietf-precis-mappings) > a. delimiter mapping > b. special mapping > c. local case mapping > 3. Case mapping (i.e., non-local-specific) > 4. Normalization > 5. PRECIS protocol >=20 > Does anyone see a reason to move width mapping after case mapping (as = in > RFC 5895)? We agree about this order. >=20 > For the record, I think we need to specify the order of operations in > both draft-ietf-precis-mappings and draft-ietf-precis-framework so = that > there is no ambiguity. Once we have consensus, I will be happy to = update > the framework accordingly. We will, too :-) Best regards, Nemo -- Takahiro Nemoto t.nemo10@kmd.keio.ac.jp >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_57B07277-FB21-4EB7-85F0-2F235C8C9C6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii stpeter@stpeter.im> = wrote:
As promised at IETF 86 (and probably IETF 85!), I've = reviewed the
issues raised by draft-ietf-precis-mappings. I will also = send some
editorial feedback directly to the authors of that = document.

1. Width mapping has now been moved to the framework = document, so I
think Section 2 and Section 3 of the mappings document = can be removed.
We agree.


2. I think it would be helpful to mention some = examples of delimiters
other than FULL = STOP.
We are supposing delimiter mapping for = width compatible characters 
that like '@' in mail = address and ':' or '/' in URI. Even though it may be non-existent = as for now, 
but I'm thinking that in the = future there may be protocols that use '+', '-', '<' or '>' = as delimiters.


3. This text = is a bit confusing:

  One of the most useful case of = delimiter mapping is when FULL STOP
  character (U+002E) = is a delimiter as well as domain name.

I am not a DNS expert, but = my understanding is that FULL STOP is not
part of the domain name but = is a delimiter between the labels of a
domain name. I think the = sentence quoted above means that in certain
protocols FULL STOP is = used as a delimiter within protocol strings (such
as identifiers) in = addition to being used as a delimiter between domain
name = labels.
That's right. There is no FULL STOP in = DNS packet.
But when comparing domain name strings outside of = DNS protocol, 
FULL STOPs are used as delimiters and = width problem should be considered.

For = example, in web browser, FULL STOPs are considered = when 
inputting words in comparing them with = the page history list.


4. I think we can just mention RFCs 3748, 4013, 4314, = and 4518 in
Section 4.2 and then remove Appendix B, since it is the = responsibility
of other specifications to actually define the special = mappings (e.g.,
this is done in = draft-ietf-precis-saslprepbis).
We = agree.


5. I think Appendix C = could be moved into Section 4.3.
Because = we thought that it's not proper to move a = table 
that has a unicode version dependency in the = section, 
we place in the = Appendix.


6. The big open = issue here is the order of mappings. RFC 5895 defines an
order of = case mapping, width mapping, NFC, and the IDNA protocol. I'm
not sure = why we would do width mapping before case mapping in PRECIS,
because = we want to do local case mapping before non-locale-specific = case
mapping. Therefore I suggest the following order:

=   1. Width mapping
  2. Additional mappings = (draft-ietf-precis-mappings)
     a. = delimiter mapping
     b. special = mapping
     c. local case mapping
=   3. Case mapping (i.e., non-local-specific)
=   4. Normalization
  5. PRECIS = protocol

Does anyone see a reason to move width mapping after = case mapping (as in
RFC 5895)?
We agree about = this order.


For the record, I = think we need to specify the order of operations in
both = draft-ietf-precis-mappings and draft-ietf-precis-framework so = that
there is no ambiguity. Once we have consensus, I will be happy = to update
the framework accordingly.
We = will, too :-)

Best = regards,
Nemo

--
Takahir= o Nemoto
<= /div>



Peter

--
Peter Saint-Andre
https://stpeter.im/

______________= _________________________________
precis mailing = list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_57B07277-FB21-4EB7-85F0-2F235C8C9C6D-- From stpeter@stpeter.im Thu Apr 25 19:00:38 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67A221F9798 for ; Thu, 25 Apr 2013 19:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrLUmrFkPefP for ; Thu, 25 Apr 2013 19:00:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5546A21F9765 for ; Thu, 25 Apr 2013 19:00:38 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB3204004E; Thu, 25 Apr 2013 20:11:35 -0600 (MDT) Message-ID: <5179DFC7.50103@stpeter.im> Date: Thu, 25 Apr 2013 20:00:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Takahiro Nemoto References: <20130412211809.GC18009@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: precis@ietf.org Subject: Re: [precis] mappings X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2013 02:00:38 -0000 Thanks for your reply. I provide a few more comments inline (removing areas where we have agreement). On 4/25/13 7:50 PM, Takahiro Nemoto wrote: > > On 2013/04/13, at 6:18, Peter Saint-Andre > wrote: >> 2. I think it would be helpful to mention some examples of delimiters >> other than FULL STOP. > We are supposing delimiter mapping for width compatible characters > that like '@' in mail address and ':' or '/' in URI. Even though it may > be non-existent as for now, > but I'm thinking that in the future there may be protocols that use '+', > '-', '<' or '>' as delimiters. OK. Do you think it would be helpful to mention examples other than FULL STOP? >> 3. This text is a bit confusing: >> >> One of the most useful case of delimiter mapping is when FULL STOP >> character (U+002E) is a delimiter as well as domain name. >> >> I am not a DNS expert, but my understanding is that FULL STOP is not >> part of the domain name but is a delimiter between the labels of a >> domain name. I think the sentence quoted above means that in certain >> protocols FULL STOP is used as a delimiter within protocol strings (such >> as identifiers) in addition to being used as a delimiter between domain >> name labels. > That's right. There is no FULL STOP in DNS packet. > But when comparing domain name strings outside of DNS protocol, > FULL STOPs are used as delimiters and width problem should be considered. > > For example, in web browser, FULL STOPs are considered when > inputting words in comparing them with the page history list. Agreed. I think it would be good to mention that example in the text. >> 5. I think Appendix C could be moved into Section 4.3. > Because we thought that it's not proper to move a table > that has a unicode version dependency in the section, > we place in the Appendix. That seems reasonable. >> 6. The big open issue here is the order of mappings. RFC 5895 defines an >> order of case mapping, width mapping, NFC, and the IDNA protocol. I'm >> not sure why we would do width mapping before case mapping in PRECIS, >> because we want to do local case mapping before non-locale-specific case >> mapping. Therefore I suggest the following order: >> >> 1. Width mapping >> 2. Additional mappings (draft-ietf-precis-mappings) >> a. delimiter mapping >> b. special mapping >> c. local case mapping >> 3. Case mapping (i.e., non-local-specific) >> 4. Normalization >> 5. PRECIS protocol >> >> Does anyone see a reason to move width mapping after case mapping (as in >> RFC 5895)? > We agree about this order. Great! I'll update the framework specification accordingly. >> For the record, I think we need to specify the order of operations in >> both draft-ietf-precis-mappings and draft-ietf-precis-framework so that >> there is no ambiguity. Once we have consensus, I will be happy to update >> the framework accordingly. > We will, too :-) Excellent. That will enable us to close one of the only open issues with the framework. :-) Peter From internet-drafts@ietf.org Thu Apr 25 19:54:24 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5D621F975F; Thu, 25 Apr 2013 19:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4CFSEd1TNt2; Thu, 25 Apr 2013 19:54:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0421F93F1; Thu, 25 Apr 2013 19:54:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426025424.7105.30736.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 19:54:24 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2013 02:54:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internat= ionalized Strings in Application Protocols Author(s) : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-08.txt Pages : 70 Date : 2013-04-25 Abstract: Application protocols using Unicode code points 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 (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points 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). A specification that reuses this framework can either directly use the PRECIS string classes or subclass the PRECIS string classes as needed. This framework takes an approach similar to the revised internationalized domain names (IDNs) in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in the IAB's recommendations regarding IDNs (RFC 4690), albeit for application technologies other than the Domain Name System (DNS). 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-framework-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Apr 25 20:06:55 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68A321F97B6; Thu, 25 Apr 2013 20:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k66Red3EkvjK; Thu, 25 Apr 2013 20:06:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22221F97B3; Thu, 25 Apr 2013 20:06:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426030654.5024.86443.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 20:06:54 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2013 03:06:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings = Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-02.txt Pages : 13 Date : 2013-04-25 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-saslprepbis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/