From t.nemo10@kmd.keio.ac.jp Wed May 1 08:44:59 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 8066821F9A57 for ; Wed, 1 May 2013 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 eanZoOaEibnC for ; Wed, 1 May 2013 08:44:59 -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 7E51321F9A4F for ; Wed, 1 May 2013 08:44:58 -0700 (PDT) Received: from [192.168.0.4] (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 B812580619; Thu, 2 May 2013 00:44:54 +0900 (JST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Takahiro Nemoto In-Reply-To: <5179DFC7.50103@stpeter.im> Date: Thu, 2 May 2013 00:44:57 +0900 Content-Transfer-Encoding: 7bit Message-Id: <7A8B3F9D-ACB6-4110-9777-E00B61A13BF5@kmd.keio.ac.jp> References: <20130412211809.GC18009@stpeter.im> <5179DFC7.50103@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: Wed, 01 May 2013 15:44:59 -0000 Thank you for your comments. Our comments inline. On 2013/04/26, at 11:00, Peter Saint-Andre wrote: > 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? Yes. We'll mention that. > >>> 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. OK. We will explain it 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. :-) That's good!! We think we can close open issues that we discussed at the last meeting in mapping document, too. Best Regards, Nemo > > Peter > > From david.black@emc.com Fri May 3 12:20:31 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 7584221F8A0C for ; Fri, 3 May 2013 12:20:31 -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 a7dxIHGQwE2a for ; Fri, 3 May 2013 12:20:26 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68D21F882A for ; Fri, 3 May 2013 12:20:22 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r43JKG5e005986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 May 2013 15:20:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 3 May 2013 15:19:55 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r43JJthD012805 for ; Fri, 3 May 2013 15:19:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Fri, 3 May 2013 15:19:55 -0400 From: "Black, David" To: "precis@ietf.org" Date: Fri, 3 May 2013 15:19:53 -0400 Thread-Topic: More on mappings (iSCSI perspective) Thread-Index: Ac5IMzCVJyOpmcHUSTWK+E+5ejI9qg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712940541C5@MX15A.corp.emc.com> 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-EMM-MHVC: 1 Subject: [precis] More on mappings (iSCSI perspective) 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, 03 May 2013 19:20:31 -0000 I've taken a look at the mappings draft from an iSCSI perspective. The iSCSI entities that use Unicode are iSCSI names, so I'll start with some background on them. iSCSI names are somewhat restrictive in allowed characters. For ASCII characters, only the following are allowed: - ASCII dash character ('-' =3D U+002d) - ASCII dot character ('.' =3D U+002e) - ASCII colon character (':' =3D U+003a) - ASCII lower-case characters ('a'..'z' =3D U+0061..U+007a) - ASCII digit characters ('0'..'9' =3D U+0030..U+0039) All other ASCII characters are prohibited, including U=3D0020; SPACE. The Unicode support generalizes from this. The iSCSI protocol design kept Unicode functionality outside the protocol; stringprep is used on iSCSI names *before* the protocol sees them so that the protocol can do binary comparison for equality of iSCSI names that are communicated "on the wire". Hence whatever we do here should not affect the specification of the "on the wire" iSCSI protocol. For context, the iSCSI stringprep profile stuck fairly close to stringprep (RFC 3454) with the following items of note: - whitespace is prohibited in output. Prohibition in input is probably the best approach here. - U+3002; ideographic full stop is prohibited in output. Mapping that to U+002E; FULL STOP would be user-friendly. - NFKC was used as it was the only reasonable option in RFC 3454. - Everything for which RFC 3454 suggested possible prohibition was prohibited, i.e., all of Appendix C of RFC 3454. - Bidirectional support followed RFC 3454. - Case mapping is used. The design rationale was to allow mixed case human input, mapping to lower case to obtain binary-comparable identifiers. I believe that both case mapping and local case mapping will be appropriate for iSCSI, as at least the Turkish language dependency on the mapping of upper case I appearss relevant. I would prefer to see both mapping mechanisms specified in one document to limit the possibility for confusion and mistakes (e.g., if local case mapping is not always implemented along with case mapping), so I'd prefer to move it into the framework draft to resolve the open issues listed in Section 6 of the mappings draft. I also observe that the framework draft would benefit from an appendix that summarizes potential differences in behavior from RFC 3454 - when the precis profile for iSCSI is written, I'd prefer to point to that text and describe how it applies (the alternative is to write it from scratch in the iSCSI precis profile). iSCSI will not have any on-the-wire version change to pick up precis support for Unicode, so there will probalby need to be some text that describes what happens when stringprep and precis are mixed in the same protocol session (which may well include a blunt "SHOULD NOT" about doing that). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nico@cryptonector.com Fri May 3 12:39:46 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 C165121F8F6E; Fri, 3 May 2013 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 SvmR-TYkb4lP; Fri, 3 May 2013 12:39:41 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E18C621F8EFE; Fri, 3 May 2013 12:39:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 9302C6B007B; Fri, 3 May 2013 12:39:38 -0700 (PDT) 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:content-type; s=cryptonector.com; bh=CZbB372Z7bx1VhQyyC8nOms Z18o=; b=ypa91zxSuHFqkoz+gLGp9voUv4Gn0zNaLCqsinA/6ADmdL4LUqToZ4z 99VIbFRCPglRrFc9/llHGPGX52f//UL0GG5EXk2EeVLJoHeEWDbENc6L2dN5iT8S qE/oaLKZvGOVxSPrde6wHjre0Y9cp5uUPj6Sxpu1ixCDhA3q3J7M= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 1B9016B0078; Fri, 3 May 2013 12:39:37 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u7so1622600wey.16 for ; Fri, 03 May 2013 12:39:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=6rwatdJU0ruAROM83vk93zbQAbCf/XZ5fXPfw1iRlvo=; b=blcpndlN/bQ330CDFecmKhwvL5+xrVzxLWEPAupzLhJTaZbmfuOy3UrX3EqfH6fkZG 9G/sQud528xWWgmptALJRWi5ZthjItEODsXWF8mf1yVWw1qBmwqm8u/y2Djv43VMWTms fAckQcZlV5YIfkA3nBgqRnB0RxKxHUgxu6Dl499uE6SU52wp/dZc4tkXqepb0UZjHjZp mTrgRHQ8oz//MZuEmNOo2DC0bCtrMPcSW25vCPLtfzauew3ndJoE6+uHoWMC7XQeol16 7Bd/POUTcxWU35c+EDENmee9QZgbrIa6cyZTl36v3nkjA16X0uCp9dwjUUb+TvhEvQO7 STxg== MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr15772026wjc.50.1367609976683; Fri, 03 May 2013 12:39:36 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Fri, 3 May 2013 12:39:36 -0700 (PDT) In-Reply-To: References: <20130328033951.21028.2480.idtracker@ietfa.amsl.com> <515E4D5B.5050102@stpeter.im> <51648B46.2020905@stpeter.im> Date: Fri, 3 May 2013 14:39:36 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre , precis@ietf.org, kitten@ietf.org, Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Subject: Re: [precis] [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.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, 03 May 2013 19:39:46 -0000 Please forgive my apparent apathy. I lost track of this due to business travel. I'm not sure where the case mapping requirement for usernames came from. I guess it has something to do with the Turkish I and such. I can't say I'm excited about this case mapping requirement; if anything it strikes as silly. Why would we apply mappings to usernames (which are sent on the wire) that we don't apply to passwords (which servers generally don't get the plaintext of)? We need mappings for passwords to make password entry reliable. The same does NOT apply to usernames. Also, looking at SASLprep and PRECIS, I see no mention of query strings vs. display vs. storage. These distinctions matter. But maybe I'm just failing to search for the right terms. Heck, we're not even told whether these rules should be applied by the client, the server, or both. Anyways, I'm for applying as few transformations as possible to usernames on the *client* side and leaving the server to apply RECOMMENDED, and a few REQUIRED rules for matching. I don't see room for case folding in general, but I do for specific cases (e.g., Turkish I handling). If this review is too late to make a difference, well, c'est la vie. But do give the above some thought before rejecting my comments for being late. Once more, I'm sorry I let this slip. Nico -- From t.nemo10@kmd.keio.ac.jp Fri May 17 00:30:35 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 E215321F845A for ; Fri, 17 May 2013 00:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 7hzt8VYVRxYb for ; Fri, 17 May 2013 00:30:31 -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 2EB0421F85DC for ; Fri, 17 May 2013 00:30:30 -0700 (PDT) Received: from [IPv6:2001:200:167:2ec1:e149:7c96:6a79:c52a] (unknown [IPv6:2001:200:167:2ec1:e149:7c96:6a79:c52a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kmd.keio.ac.jp (Postfix) with ESMTPSA id 0547480520; Fri, 17 May 2013 16:30:28 +0900 (JST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Takahiro Nemoto In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712940541C5@MX15A.corp.emc.com> Date: Fri, 17 May 2013 16:30:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <47CF33E7-B120-456A-A2B6-621D99D7B8AD@kmd.keio.ac.jp> References: <8D3D17ACE214DC429325B2B98F3AE712940541C5@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1503) Cc: "precis@ietf.org" Subject: Re: [precis] More on mappings (iSCSI perspective) 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, 17 May 2013 07:30:35 -0000 Hi, David-san,=20 Thank you for your comments.=20 And I'm sorry for my late reply. Yoneya-san and I are going to reflect on your comments as an open issue = in the next draft=20 and we would like to discuss it in the next meeting. We agree with your point in the last paragraph. Also, we think that it is necessary to make a guideline document for the = compatibility=20 between RFC 3454 and PRECIS as discussed in the last meeting. Best Regards, Nemo On 2013/05/04, at 4:19, "Black, David" wrote: > I've taken a look at the mappings draft from an iSCSI perspective. > The iSCSI entities that use Unicode are iSCSI names, so I'll start > with some background on them. >=20 > iSCSI names are somewhat restrictive in allowed characters. For > ASCII characters, only the following are allowed: > - ASCII dash character ('-' =3D U+002d) > - ASCII dot character ('.' =3D U+002e) > - ASCII colon character (':' =3D U+003a) > - ASCII lower-case characters ('a'..'z' =3D U+0061..U+007a) > - ASCII digit characters ('0'..'9' =3D U+0030..U+0039) > All other ASCII characters are prohibited, including U=3D0020; SPACE. > The Unicode support generalizes from this. >=20 > The iSCSI protocol design kept Unicode functionality outside the > protocol; stringprep is used on iSCSI names *before* the protocol > sees them so that the protocol can do binary comparison for equality > of iSCSI names that are communicated "on the wire". Hence whatever > we do here should not affect the specification of the "on the wire" > iSCSI protocol. >=20 > For context, the iSCSI stringprep profile stuck fairly close to > stringprep (RFC 3454) with the following items of note: >=20 > - whitespace is prohibited in output. > Prohibition in input is probably the best approach here. > - U+3002; ideographic full stop is prohibited in output. > Mapping that to U+002E; FULL STOP would be = user-friendly. > - NFKC was used as it was the only reasonable option in > RFC 3454. > - Everything for which RFC 3454 suggested possible prohibition > was prohibited, i.e., all of Appendix C of RFC 3454. > - Bidirectional support followed RFC 3454. >=20 > - Case mapping is used. The design rationale was to allow > mixed case human input, mapping to lower case to > obtain binary-comparable identifiers. >=20 > I believe that both case mapping and local case mapping will be > appropriate for iSCSI, as at least the Turkish language dependency > on the mapping of upper case I appearss relevant. I would prefer > to see both mapping mechanisms specified in one document to limit > the possibility for confusion and mistakes (e.g., if local case > mapping is not always implemented along with case mapping), so > I'd prefer to move it into the framework draft to resolve the > open issues listed in Section 6 of the mappings draft. >=20 > I also observe that the framework draft would benefit from an appendix > that summarizes potential differences in behavior from RFC 3454 - when > the precis profile for iSCSI is written, I'd prefer to point to that > text and describe how it applies (the alternative is to write it from > scratch in the iSCSI precis profile). iSCSI will not have any > on-the-wire version change to pick up precis support for Unicode, so > there will probalby need to be some text that describes what happens > when stringprep and precis are mixed in the same protocol session > (which may well include a blunt "SHOULD NOT" about doing that). >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From internet-drafts@ietf.org Fri May 24 05:59:23 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 3CCF121F9260; Fri, 24 May 2013 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 dzd79NigHYDP; Fri, 24 May 2013 05:59:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD821F90E0; Fri, 24 May 2013 05:59:22 -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.50 Message-ID: <20130524125922.536.87214.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 05:59:22 -0700 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-mappings-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, 24 May 2013 12:59:23 -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 : Mapping characters for PRECIS classes Author(s) : Yoshiro YONEYA Takahiro NEMOTO Filename : draft-ietf-precis-mappings-02.txt Pages : 9 Date : 2013-05-24 Abstract: The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. In the framework, case mapping is defined because many protocols handle case-sensitive or case-insensitive string comparison and therefore preparation of the string is mandatory. As described in the mapping for Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement, mappings for internationalized strings are not limited to case, but also width mapping and mapping of delimiters and other specials 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 Addtional 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From t.nemo10@kmd.keio.ac.jp Fri May 24 06:34:21 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 52D9521F95FD for ; Fri, 24 May 2013 06:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 dmTnO0GKx51V for ; Fri, 24 May 2013 06:34:19 -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 871BB21F92E8 for ; Fri, 24 May 2013 06:34:17 -0700 (PDT) Received: from [192.168.0.3] (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 ABC548069C for ; Fri, 24 May 2013 22:34:14 +0900 (JST) From: Takahiro Nemoto Content-Type: multipart/alternative; boundary="Apple-Mail=_CD4F9D7A-1D81-4866-A203-1201E045968A" Date: Fri, 24 May 2013 22:34:14 +0900 References: <20130524125922.536.87214.idtracker@ietfa.amsl.com> To: "precis@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-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, 24 May 2013 13:34:21 -0000 --Apple-Mail=_CD4F9D7A-1D81-4866-A203-1201E045968A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Dear all, Yoneya-san and I submitted new version of precis mappings document.=20 We added a new open issue to reflect a comment from David-san. Please read and give your comments/suggestions. Regards, Nemo Begin forwarded message: > =1B$B:9=3DP?M=1B(B: internet-drafts@ietf.org > =1B$B7oL>=1B(B: [precis] I-D Action: draft-ietf-precis-mappings-02.txt > =1B$BF|;~=1B(B: 2013=1B$BG/=1B(B5=1B$B7n=1B(B24=1B$BF|=1B(B 21:59:22 = JST > =1B$B08@h=1B(B: i-d-announce@ietf.org > Cc: precis@ietf.org >=20 >=20 > 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. >=20 > Title : Mapping characters for PRECIS classes > Author(s) : Yoshiro YONEYA > Takahiro NEMOTO > Filename : draft-ietf-precis-mappings-02.txt > Pages : 9 > Date : 2013-05-24 >=20 > Abstract: > The framework for preparation and comparison of internationalized > strings ("PRECIS") defines several classes of strings for = preparation > and comparison. In the framework, case mapping is defined because > many protocols handle case-sensitive or case-insensitive string > comparison and therefore preparation of the string is mandatory. As > described in the mapping for Internationalized Domain Names in > Applications (IDNA) and the PRECIS problem statement, mappings for > internationalized strings are not limited to case, but also width > mapping and mapping of delimiters and other specials 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 Addtional mapping in = the > PRECIS framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-mappings >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-mappings-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_CD4F9D7A-1D81-4866-A203-1201E045968A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp
=1B$B:9=3DP?M=1B(B: internet-drafts@ietf.org
<= /span>
=1B$B7oL>=1B(B: [precis] I-D = Action: draft-ietf-precis-mappings-02.txt
=1B$BF|;~=1B(B: = 2013=1B$BG/=1B(B5=1B$B7n=1B(B24=1B$BF|=1B(B 21:59:22 = JST
=1B$B08@h=1B(B: i-d-announce@ietf.org
=


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
Author(s) =       : Yoshiro YONEYA
=             &n= bsp;           &nbs= p;Takahiro NEMOTO
Filename =        : = draft-ietf-precis-mappings-02.txt
Pages =           : 9
Date =            : = 2013-05-24

Abstract:
  The framework for = preparation and comparison of internationalized
  strings = ("PRECIS") defines several classes of strings for preparation
=   and comparison.  In the framework, case mapping is = defined because
  many protocols handle case-sensitive or = case-insensitive string
  comparison and therefore = preparation of the string is mandatory.  As
=   described in the mapping for Internationalized Domain Names = in
  Applications (IDNA) and the PRECIS problem statement, = mappings for
  internationalized strings are not limited = to case, but also width
  mapping and mapping of = delimiters and other specials 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 Addtional = 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-02

A = diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-mappings-02

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

= --Apple-Mail=_CD4F9D7A-1D81-4866-A203-1201E045968A-- From presnick@qti.qualcomm.com Tue May 28 21:05:21 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 461D721F8AD8 for ; Tue, 28 May 2013 21:05:21 -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=[AWL=0.000, 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 2z9Gf8p9BaDd for ; Tue, 28 May 2013 21:05:17 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4521F8A14 for ; Tue, 28 May 2013 21:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369800315; x=1401336315; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=OTVQD5Y2vKZJoesDrO0jB6aF80QSSpGNck3BZ0UfsNE=; b=pyPyP5MBbL6TNncUxYB7ozSZqvQJShpCxEbnpsJ2mO53i76i+wUrTXPg Qwp6JJzQ72bzTm2aX4GcjgKWYr6FRsM75YBU9Nrhj1kDVnc+NLJ0uhGue ikslSVfpGOjhE07MhYeyNfpdVuOw/Eoy2tU+aRsjHNnx+Nu0Of6DvR80n 8=; X-IronPort-AV: E=Sophos;i="4.87,762,1363158000"; d="scan'208";a="42148925" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 28 May 2013 21:04:56 -0700 Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 May 2013 21:04:55 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 28 May 2013 21:04:55 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 28 May 2013 21:04:55 -0700 Message-ID: <51A57E65.9090600@qti.qualcomm.com> Date: Tue, 28 May 2013 23:04:53 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [precis] Anybody do any review of NFS documents? 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: Wed, 29 May 2013 04:05:21 -0000 Folks, The new rev of NFS (3530bis) is on the IESG agenda for this week. I saw that David Black had some hand in the discussion on the NFS WG list regarding i18n. Did anyone else here participate in the discussion with this WG on their new i18n section? I've got some concerns, but I'd like to understand who was involved in that discussion and how much review it got. Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From stpeter@stpeter.im Wed May 29 09:15: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 B297721F9289 for ; Wed, 29 May 2013 09:15:30 -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 XkVEUU-NfSDW for ; Wed, 29 May 2013 09:15:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0A21F8ED8 for ; Wed, 29 May 2013 09:15:25 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8C4B5411C6 for ; Wed, 29 May 2013 10:28:13 -0600 (MDT) Message-ID: <51A62999.8050701@stpeter.im> Date: Wed, 29 May 2013 10:15:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: precis@ietf.org References: <51A57E65.9090600@qti.qualcomm.com> In-Reply-To: <51A57E65.9090600@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [precis] Anybody do any review of NFS documents? 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: Wed, 29 May 2013 16:15:30 -0000 On 5/28/13 10:04 PM, Pete Resnick wrote: > Folks, > > The new rev of NFS (3530bis) is on the IESG agenda for this week. I saw > that David Black had some hand in the discussion on the NFS WG list > regarding i18n. Did anyone else here participate in the discussion with > this WG on their new i18n section? I've got some concerns, but I'd like > to understand who was involved in that discussion and how much review it > got. I have't looked at those specs. The size of 3530bis scared me off. Are there particular sections that it would be best for us to review? Peter -- Peter Saint-Andre https://stpeter.im/ From presnick@qti.qualcomm.com Wed May 29 11:14:03 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 D8F4421F95E9 for ; Wed, 29 May 2013 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 a0xnIAQ0bnQW for ; Wed, 29 May 2013 11:13:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 066FD21F911B for ; Wed, 29 May 2013 11:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1369851237; x=1401387237; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=CJLQHZvxWoPofPcQfk7jozV5E1cZAE/uaVutkIAGIDw=; b=U7IxO/qCk2MkD4ZY9lB3E7TckVlZektcZax9q9UPsn/UCaHJRdMcVQvP Ji6CnUl3+nce/pj6YzlAIGAawLrCowH8raaT03XUWqgxY2JtCz6KOCfbm PNiIFtDXgnDjf74MzePpvdjKkyl4qMEE/yRUOdU7widJe4mZAUjYfBfUu s=; X-IronPort-AV: E=Sophos;i="4.87,765,1363158000"; d="scan'208";a="51693712" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 29 May 2013 11:13:57 -0700 X-IronPort-AV: E=Sophos;i="4.87,765,1363158000"; d="scan'208";a="491197059" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 May 2013 11:13:57 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 29 May 2013 11:13:57 -0700 Message-ID: <51A64564.9000200@qti.qualcomm.com> Date: Wed, 29 May 2013 13:13:56 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <51A57E65.9090600@qti.qualcomm.com> <51A62999.8050701@stpeter.im> In-Reply-To: <51A62999.8050701@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: Re: [precis] Anybody do any review of NFS documents? 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: Wed, 29 May 2013 18:14:04 -0000 On 5/29/13 11:15 AM, Peter Saint-Andre wrote: > On 5/28/13 10:04 PM, Pete Resnick wrote: > >> Folks, >> >> The new rev of NFS (3530bis) is on the IESG agenda for this week. I saw >> that David Black had some hand in the discussion on the NFS WG list >> regarding i18n. Did anyone else here participate in the discussion with >> this WG on their new i18n section? I've got some concerns, but I'd like >> to understand who was involved in that discussion and how much review it >> got. >> > I have't looked at those specs. The size of 3530bis scared me off. Are > there particular sections that it would be best for us to review? > Section 12. http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-26#section-12 It is entirely new to this document and (from what I can tell from the NFSv4 WG list) entirely unimplemented to date. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From david.black@emc.com Wed May 29 11:56:57 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 7BD4B21F9673 for ; Wed, 29 May 2013 11:56:57 -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 6W2WP0cMtL0f for ; Wed, 29 May 2013 11:56:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B13CF21F94B1 for ; Wed, 29 May 2013 11:56:51 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TIucCH000614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 14:56:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 14:56:16 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TIuCOU006713; Wed, 29 May 2013 14:56:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub36.corp.emc.com ([::1]) with mapi; Wed, 29 May 2013 14:56:13 -0400 From: "Black, David" To: Pete Resnick , "precis@ietf.org" Date: Wed, 29 May 2013 14:56:12 -0400 Thread-Topic: [precis] Anybody do any review of NFS documents? Thread-Index: Ac5cmHk3itYoJ07QRry4ak/gxLnTZAAASclQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C728@MX15A.corp.emc.com> References: <51A57E65.9090600@qti.qualcomm.com> <51A62999.8050701@stpeter.im> <51A64564.9000200@qti.qualcomm.com> In-Reply-To: <51A64564.9000200@qti.qualcomm.com> 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-EMM-MHVC: 1 Subject: Re: [precis] Anybody do any review of NFS documents? 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: Wed, 29 May 2013 18:56:57 -0000 Pete, Well, the 3530bis draft is actually an update to an older NFS version, NFSv4.0. The latest version of NFS is v4.1 and work is in progress on v4.2. I had some involvement in some of the Unicode provisions of 3530bis a while back, but I have not reviewed the Unicode portion of the current 3530bis draft in detail. The history here is unfortunate: - RFC 3530 specified use of stringprep - see section 11: http://tools.ietf.org/html/rfc3530#section-11 - That didn't work, as the "running code" does "other things," some of which are "interesting" ;-). Among the more "interesting" of those "other things" is that there are apparently both NFC-based and NFD-based implementations of filename normalization in use (see 12.7.1.5.1 in 3530bis for a glimpse), and hence specifying a single normalization approach "on the wire" won't work. My general understanding of the 3530bis draft's Unicode provisions is that they're strongly influenced by compatibility with "running code" even if what they specify is new and not yet (fully) implemented. Thanks, --David p.s. Now you have some insight into why I've chosen to initially focus on iSCSI in precis ... but I guess I should start paying attention to this NFSv4 situation, as the work that Peter Saint-Andre and I have been putting into the Unicode provisions in a DIAMETER draft seems to be close to done. > -----Original Message----- > From: precis-bounces@ietf.org [mailto:precis-bounces@ietf.org] On Behalf = Of > Pete Resnick > Sent: Wednesday, May 29, 2013 2:14 PM > To: precis@ietf.org > Subject: Re: [precis] Anybody do any review of NFS documents? >=20 > On 5/29/13 11:15 AM, Peter Saint-Andre wrote: > > On 5/28/13 10:04 PM, Pete Resnick wrote: > > > >> Folks, > >> > >> The new rev of NFS (3530bis) is on the IESG agenda for this week. I sa= w > >> that David Black had some hand in the discussion on the NFS WG list > >> regarding i18n. Did anyone else here participate in the discussion wit= h > >> this WG on their new i18n section? I've got some concerns, but I'd lik= e > >> to understand who was involved in that discussion and how much review = it > >> got. > >> > > I have't looked at those specs. The size of 3530bis scared me off. Are > > there particular sections that it would be best for us to review? > > >=20 > Section 12. >=20 > http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-26#section-12 >=20 > It is entirely new to this document and (from what I can tell from the > NFSv4 WG list) entirely unimplemented to date. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis