From nobody Sat Sep 3 14:22:00 2016 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 9E72212B10C for ; Sat, 3 Sep 2016 14:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VPF_JwRSzfvx for ; Sat, 3 Sep 2016 14:21:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67712B0FB for ; Sat, 3 Sep 2016 14:21:57 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC475416B6; Sat, 3 Sep 2016 15:22:03 -0600 (MDT) To: Sam Whited , peter@filament.com References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: Date: Sat, 3 Sep 2016 15:21:56 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 03 Sep 2016 21:21:58 -0000 Hi Sam, My apologies to you and to the working group for my seriously delayed processing of your feedback. I'll work to reply to all threads shortly. Comments inline. On 5/16/16 3:52 PM, Sam Whited wrote: > Hi Peter et al. > > A few quick notes regarding your draft to replace RFC 7700: > > * Nit: §1.1 ¶3 uses the term "display name" several times, but the > document otherwise uses the term "nickname" Primarily that's because RFC 5322 calls it a display name (e.g., in the string "Sam Whited " the substring "Sam Whited" is a display-name, but it's not necessarily what we'd typically refer to as a nickname). > * §2.1: "May any instances of non-ASCII space be mapped…" sounds odd, > should this just say "Instances of non-ASCII space should be mapped…" Typo: s/May/Map/ > * §2.2 Specifies that UTF-8 MUST be used as the encoding; do we really > want to limit this to UTF-8 only? Is this for comparison purposes? > Then again, 99.99% of the time UTF-8 is what you should be using > anyways, so I'm not sure that it matters. UTF-8 is your friend, and everything in PRECIS is UTF-8. > * §2.3: "Normalization Rule" is listed twice for enforcement The second bullet point should be "Case Mapping Rule". Thanks! Peter From nobody Sat Sep 3 14:33:51 2016 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 9CC8C12B109 for ; Sat, 3 Sep 2016 14:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ax9ysGMgCyk9 for ; Sat, 3 Sep 2016 14:33:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5BB12B106 for ; Sat, 3 Sep 2016 14:33:48 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD1D1416B6; Sat, 3 Sep 2016 15:33:54 -0600 (MDT) To: Sam Whited References: <20151223045826.9CED018000D@rfc-editor.org> From: Peter Saint-Andre Message-ID: <60013276-c8d2-bbeb-f941-7e98d50e950b@stpeter.im> Date: Sat, 3 Sep 2016 15:33:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] [Technical Errata Reported] RFC7700 (4570) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 03 Sep 2016 21:33:49 -0000 On 12/23/15 8:09 AM, Sam Whited wrote: > Hi all, > > After submitting this yesterday I had a discussion with Christian > Schudt about it and he pointed out that you probably want to be able > to display the text output by the enforce operation, and therefore > this was most likely a deliberate change. With that in mind, I'd like > to ammend my suggestions somewhat: > > The directionality rule should still be removed from the list of rules > in section 2.3 as well as the list in section 2.4 (there is no > directionality rule, so having it in the order of operations is just > confusing), and section 2 item 3 should be updated to clarify that > Unicode default case folding only needs to be applied during the > comparison step (right now it states that it "MUST be applied" which > is ambiguous since it doesn't list what step (or steps) need to apply > it and makes it seem like it should be part of the enforcement step). Agreed. I plan to add the following text: Section 2.1 OLD 3. Case Mapping Rule: Apply Unicode Default Case Folding, as defined in the Unicode Standard [Unicode] (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0]). In applications that prohibit conflicting nicknames, this rule helps to reduce the possibility of confusion by ensuring that nicknames differing only by case (e.g., "stpeter" vs. "StPeter") would not be presented to a human user at the same time. NEW 3. Case Mapping Rule: Apply Unicode Default Case Folding, as defined in the Unicode Standard [Unicode] (at the time of this writing, the algorithm is specified in Chapter 3 of [Unicode7.0]). In applications that prohibit conflicting nicknames, this rule helps to reduce the possibility of confusion by ensuring that nicknames differing only by case (e.g., "stpeter" vs. "StPeter") would not be presented to a human user at the same time. (As explained below, this is typically appropriate only for comparison, not for enforcement.) Section 2.3 OLD 1. Additional Mapping Rule 2. Normalization Rule 3. Normalization Rule NEW 1. Additional Mapping Rule 2. Normalization Rule Note: An entity SHOULD NOT apply the Case Mapping Rule during enforcement, because typically it is appropriate only during comparison. Peter > Best, > Sam > > > On Tue, Dec 22, 2015 at 10:58 PM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC7700, >> "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7700&eid=4570 >> >> -------------------------------------- >> Type: Technical >> Reported by: Sam Whited >> >> Section: 2.3 >> >> Original Text >> ------------- >> An entity that performs enforcement according to this profile MUST >> prepare a string as described in Section 2.2 and MUST also apply the >> following rules specified in Section 2.1 in the order shown: >> >> 1. Additional Mapping Rule >> 2. Normalization Rule >> 3. Directionality Rule >> >> After all of the foregoing rules have been enforced, the entity MUST >> ensure that the nickname is not zero bytes in length (this is done >> after enforcing the rules to prevent applications from mistakenly >> omitting a nickname entirely, because when internationalized >> characters are accepted, a non-empty sequence of characters can >> result in a zero-length nickname after canonicalization). >> >> >> Corrected Text >> -------------- >> An entity that performs enforcement according to this profile MUST >> prepare a string as described in Section 2.2 and MUST also apply the >> following rules specified in Section 2.1 in the order shown: >> >> 1. Additional Mapping Rule >> 2. Case Mapping Rule >> 3. Normalization Rule >> >> After all of the foregoing rules have been enforced, the entity MUST >> ensure that the nickname is not zero bytes in length (this is done >> after enforcing the rules to prevent applications from mistakenly >> omitting a nickname entirely, because when internationalized >> characters are accepted, a non-empty sequence of characters can >> result in a zero-length nickname after canonicalization). >> >> >> Notes >> ----- >> There is no directionality rule to be applied during enforcement as the directionality rule is part of NFKC, the case mapping rule (as mentioned in section 2.1). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7700 (draft-ietf-precis-nickname-19) >> -------------------------------------- >> Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames >> Publication Date : December 2015 >> Author(s) : P. Saint-Andre >> Category : PROPOSED STANDARD >> Source : Preparation and Comparison of Internationalized Strings >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG >> > > > From nobody Sat Sep 3 15:23:53 2016 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 F240E12B11B for ; Sat, 3 Sep 2016 15:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Z8_Htid4drLR for ; Sat, 3 Sep 2016 15:23:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7433B12B109 for ; Sat, 3 Sep 2016 15:23:49 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2BF6AF0793; Sat, 3 Sep 2016 16:23:55 -0600 (MDT) To: Sam Whited , peter@filament.com References: <20160505174244.20612.16872.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <7b0721fe-bd00-d523-daa9-ddf56f0a823b@stpeter.im> Date: Sat, 3 Sep 2016 16:23:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7613bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 03 Sep 2016 22:23:51 -0000 Hi Sam, Thanks for the feedback. Comments inline. On 5/17/16 8:43 AM, Sam Whited wrote: > Hi Peter et al. > > Here are some notes I took while reading through the 7613 draft last > night; a few of them are actual issues, and others are probably just > me misunderstanding something: > > - §3 defines Usernames, but since I was expecting a PRECIS profile > that defined a username it was confusing and I didn't really > understand it at first (until I got to §3.5 which explained the > difference between user parts and usernames). I'm not sure if this > could be made clearer or not, or if it was just me. Few people talk about "user parts" whereas the term "username" is familiar. Also RFC 4013 uses the term "user name". > - Nit: §3.2.4 reads "An entity that performs comparison of two strings > according to this profile MUST prepare each string as specified in > Section 3.2.2 and then enforce the rules specified in Section 3.2.3". > Though redundant, it might make sense to modify it to read "and then > MUST enforce the rules" as well. Not sure that it matters, but it was > unclear to me on first reading (though I figured it out pretty > quickly; others probably wouldn't have been tripped up by this). The additional clarity can't hurt. > - §3.3.3 says that the Case-mapping rule should be performed as the > third step of Enforcement, but there is no case mapping rule for the > profile. This step should probably be removed or clarified (eg. is > case mapping optional, or is it required that you don't do it? I'm not > clear on how the absense of a rule works in a profile in general). Let's remove it. > - Table 2 says "A localpart of BLACK CHESS KING". Localpart is an XMPP > term and should read "Userpart" in this context Noted. > - Nit: §4.2.2 lists the Case mapping rule as "Uppercase and titlecase > characters MUST NOT be mapped…", but other profiles just say there is > no case mapping rule. Similar to the above, if there's a difference > (especially within a single document), I think it could use some > clarification. Although I'm not sure that it matters, as > implementations are likely to just leave off case mapping either way, > which I think is the expected behavior in both cases? I think this would be good: 3. Case-Mapping Rule: There is no case mapping rule (because mapping uppercase and titlecase characters to their lowercase equivalents would lead to false positives and thus to reduced security). > - §6.1 references Unicode 7.0, if an update to the RFC is being > proposed, this could be changed to read 8.0.0 (or removed if the issue > is no longer a problem), or it could be left alone, probably doesn't > really matter. In all of these documents we pointed to specific chapters of the Unicode 7.0.0 version in a few cases, but I now think that's unnecessary so I'd prefer to remove it (and the note about MONGOLIAN TODO SOFT HYPHEN (U+1806) is very much an edge case, so I think it's fine to remove that, too). And we're up to 9.0.0 now! > - §6.1 also says "these code points would have been "mapped to > nothing" in stringprep, in practice a user would not notice the > difference if, upon migration to PRECIS, the code points are > removed.". Is this correct? Would this not make the username invalid > because the code points aren't allowed in the identifier class, > locking them out of their account? I'm probably missing something > here. First, these are some pretty obscure characters (SOFT HYPHEN, COMBINING GRAPHEME JOINER, MONGOLIAN TODO SOFT HYPHEN, ZERO WIDTH SPACE, etc.) that are extremely rare or nonexistent in usernames because I'd guess that very few input method editors even allow users to input these into a username registration flow (in general, they are invisible): https://tools.ietf.org/html/rfc3454#appendix-B.1 Second, before migration, the characters would have been mapped to nothing, so that a username "StU+00ADPeter" if you will would have been registered as "StPeter" and not "StU+00ADPeter" (again, these are invisible characters), so that even if the user's client saved the username as "StU+00ADPeter" the service at which stringprep was applied would not have stored the username that way. Third, after migration the username would be "StPeter" (not "StU+00ADPeter"), leading to the same behavior as before. So I think we're safe here. > - §6.2 Another possible place to update a Unicode 7 reference to 8.0.0 Or delete it. :-) Thanks! Peter From nobody Sat Sep 3 15:53:49 2016 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 E45E412B12D for ; Sat, 3 Sep 2016 15:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 R9Exipg9WAO3 for ; Sat, 3 Sep 2016 15:53:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2B46F12B12C for ; Sat, 3 Sep 2016 15:53:45 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3E470F0793; Sat, 3 Sep 2016 16:53:52 -0600 (MDT) To: John C Klensin , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , precis@ietf.org References: <6F0075DBF071EB43A3F97F73@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: Date: Sat, 3 Sep 2016 16:53:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6F0075DBF071EB43A3F97F73@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] toLower() vs. toCaseFold() X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 03 Sep 2016 22:53:47 -0000 On 5/6/16 8:40 PM, John C Klensin wrote: > (sorry... earlier copy sent from wrong address) I'm sorry that it has taken me 4 months to reply to this message! :( > --On Friday, May 06, 2016 15:54 +0900 "Martin J. Dürst" > wrote: > >> Hello Peter, >> >> On 2016/05/05 07:43, Peter Saint-Andre wrote: >> >>> I suggested that we add some text about this to 7564bis. Here >>> is a proposed paragraph for insertion in §5.2.3 >>> ("Case-Mapping Rule"): >>> >>> The Unicode toCaseFold() operation defined by the Unicode >>> Default Case Folding algorithm is most appropriate when an >>> application needs to compare two strings. When an >>> application merely wishes to convert uppercase and >>> titlecase code points to the lowercase equivalents while >>> preserving lowercase code points, the Unicode toLower() >>> operation is more appropriate and is less likely to >>> violate the "Principle of Least Astonishment". Therefore, >>> application developers are advised to carefully consider >>> whether they truly need to use the toCaseFold() operation >>> in a given situation, or whether the toLower() operation >>> would be more appropriate than the toCaseFold() operation. >>> >>> Suggestions for improvement are welcome, especially from >>> John. (E.g., we might want to more explicitly call out >>> comparison vs. other contexts in the normative text elsewhere >>> in §5.2.3). >> >> I think 'compare' should be changed to 'search'. That's the >> prototypical use case for CaseFold. > > Hmm. If we have to choose, I think I prefer "compare". I just > looked at the subsections on "Default Case Folding" and "Default > Caseless Matching" in Section 3.13 of TUS 8.0 and it says a lot > about comparison and nothing about search. Recommended > compromise: Make the relevant sentence fragment read "most > appropriate when an application needs to compare two strings > such as in search operations." +1 > I'd still prefer to denounce toCaseFold completely, especially > where identifiers are concerned. It just has far too much > potential for being destructive and creating false results > (either positive or negative) when the language context is > unknown. People/designers/implementers who are not prepared to > understand those issues and their implications should really not > be using the thing. > >> Also, the language in the "Therefore" sentence is somewhat >> convoluted. It's unclear which alternative this text prefers. >> I suggest that if we want to put the two alternatives on an >> equal footing (i.e. make sure the application designer thinks >> carefully), then a more parallel sentence structure, avoiding >> words such as "carefully", "truly", and "would", would be more >> appropriate. What about: >> >> Therefore, application >> developers >> are advised to carefully consider whether toCaseFold() or >> toLower() is more appropriate. > > For the reasons above, I'm not sure that an even footing is > appropriate. I'd rather have the guidance be closer to "use > toLowerCase, which your users are likely to understand, unless > you need CaseFolding for some particular reason and understand > its implications" That is indeed more consistent with the concerns you have expressed within the working group. Going in that direction will require some adjustments to 7613bis and 7700bis, but the changes should be straightforward. I will do that before publishing the -02 versions (hopefully today). Peter From nobody Sat Sep 3 16:29:05 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B10127735; Sat, 3 Sep 2016 16:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147294534358.2272.4334888787498528025.idtracker@ietfa.amsl.com> Date: Sat, 03 Sep 2016 16:29:03 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7564bis-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 23:29:03 -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 of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-02.txt Pages : 40 Date : 2016-09-03 Abstract: Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and 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, enforcement, 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 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-02 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 nobody Sat Sep 3 16:29:26 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624CC12B134; Sat, 3 Sep 2016 16:29:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147294535039.2336.9628918410725275972.idtracker@ietfa.amsl.com> Date: Sat, 03 Sep 2016 16:29:10 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7613bis-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 23:29:10 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-02.txt Pages : 24 Date : 2016-09-03 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-02 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 nobody Sat Sep 3 16:29:39 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C5F12B140; Sat, 3 Sep 2016 16:29:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147294536312.2343.11072753237996448433.idtracker@ietfa.amsl.com> Date: Sat, 03 Sep 2016 16:29:23 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7700bis-02.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 23:29:23 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-02.txt Pages : 11 Date : 2016-09-03 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-02 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 nobody Sun Sep 4 07:29:35 2016 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 3FEDF12B241 for ; Sun, 4 Sep 2016 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samwhited.com 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 4ZT2MtIH-9AL for ; Sun, 4 Sep 2016 07:29:31 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EA212B017 for ; Sun, 4 Sep 2016 07:29:31 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 38so43178521qte.1 for ; Sun, 04 Sep 2016 07:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qu52A33tQzAP8q+qH1t99UNqLh11huz4iJNG/lGKa98=; b=CIL6yoU/1WiBk8RWU5ltwWkYgXQdRc3hrxc+WOdZ/KouvhTkcxL4/IaYpYV7Pg7JOc FxTaXUn+MeQjAyxbUf38iDNkFPEPpV0vDifgacPmNlRn4lq09eVBBxajjcsGCSfAD9++ 7igpWsRzhO+jUoq9v+dlxvOZxB/Y6o+QH2QRE= 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-transfer-encoding; bh=Qu52A33tQzAP8q+qH1t99UNqLh11huz4iJNG/lGKa98=; b=ikNfhNf5dn27jRdEYRex81fADQ0yDSMu6mPCEUoTatK+CftiozMSQqy38ga8ZddTAQ wlxV5TX0S+J8qcATw80O/MuB0f2wj4pdCTscQ8AuvO4EyMdsFfJa4NdGN48OoWMa+8lU JMWKmY8lamRuhKFwZNOCSJaTFqsz3fROBBRuus7jvoEJlqcjJYs85JqRUQLfoJBxvgP3 LDJm3QMUS1sc0akbWFR5QMfe5JNPN33H6qeabH3fbWsiXIhjDz5E55oYO5VihpDaHlIY 5eC6Hw81hk2Tqc/jI97zQPJx60GxPgC2yB51FIGZ3Krghjc9gEzmhLxeofQaZRrF4Oz5 E/Rg== X-Gm-Message-State: AE9vXwM1Seg3KljHFAqueJZOi4Yz4rKUkqxxxDTtzhU6/R8OcQZM9tgqtytwImkvhtANSxyRW5qXLl46QT2Ivg== X-Received: by 10.237.55.225 with SMTP id j88mr34389010qtb.131.1472999370813; Sun, 04 Sep 2016 07:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.7.136 with HTTP; Sun, 4 Sep 2016 07:28:50 -0700 (PDT) X-Originating-IP: [2605:a601:1166:8b00:b774:1488:5007:efa9] In-Reply-To: References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> From: Sam Whited Date: Sun, 4 Sep 2016 09:28:50 -0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: peter@filament.com, precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 14:29:33 -0000 On Sat, Sep 3, 2016 at 4:21 PM, Peter Saint-Andre wrot= e: >> * =C2=A72.1: "May any instances of non-ASCII space be mapped=E2=80=A6" s= ounds odd, >> should this just say "Instances of non-ASCII space should be mapped=E2= =80=A6" > > Typo: s/May/Map/ That makes the document read: "Map any instances of non-ASCII space be mapped to ASCII space"; the "be mapped" still needs to be removed in the current draft. >> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; do we rea= lly >> want to limit this to UTF-8 only? Is this for comparison purposes? >> Then again, 99.99% of the time UTF-8 is what you should be using >> anyways, so I'm not sure that it matters. > > UTF-8 is your friend, and everything in PRECIS is UTF-8. PRECIS is mostly encoding agnostic; implementations might favor a specific encoding, but I don't think anything in the spec specifically *needs* UTF-8. That being said, there are so few reasons to use anything other than UTF-8 that I don't think it really matters, it was just curious to me that some of the PRECIS related specs called out UTF-8 and some didn't. =E2=80=94Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 From nobody Sun Sep 4 11:54:37 2016 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 7755412B0C3 for ; Sun, 4 Sep 2016 11:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OWPS_D44HAIL for ; Sun, 4 Sep 2016 11:54:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E012B0C1 for ; Sun, 4 Sep 2016 11:54:34 -0700 (PDT) Received: from [10.66.239.125] (unknown [166.177.123.46]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6BB854003C; Sun, 4 Sep 2016 12:54:44 -0600 (MDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Sun, 4 Sep 2016 12:54:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> To: Sam Whited Archived-At: Cc: peter@filament.com, precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 18:54:36 -0000 > On Sep 4, 2016, at 8:28 AM, Sam Whited wrote: >=20 > On Sat, Sep 3, 2016 at 4:21 PM, Peter Saint-Andre wro= te: >>> * =C2=A72.1: "May any instances of non-ASCII space be mapped=E2=80=A6" s= ounds odd, >>> should this just say "Instances of non-ASCII space should be mapped=E2=80= =A6" >>=20 >> Typo: s/May/Map/ >=20 > That makes the document read: "Map any instances of non-ASCII space be > mapped to ASCII space"; the "be mapped" still needs to be removed in > the current draft. Oops. Easy enough to fix, though! >=20 >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; do we rea= lly >>> want to limit this to UTF-8 only? Is this for comparison purposes? >>> Then again, 99.99% of the time UTF-8 is what you should be using >>> anyways, so I'm not sure that it matters. >>=20 >> UTF-8 is your friend, and everything in PRECIS is UTF-8. >=20 > PRECIS is mostly encoding agnostic; implementations might favor a > specific encoding, but I don't think anything in the spec specifically > *needs* UTF-8. That being said, there are so few reasons to use > anything other than UTF-8 that I don't think it really matters, it was > just curious to me that some of the PRECIS related specs called out > UTF-8 and some didn't. I thought they all did, but will double-check. Thanks! Peter= From emwebdev@gmail.com Sun Sep 4 16:30:55 2016 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 86DAE12B0EF for ; Sun, 4 Sep 2016 16:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8E7cbViHLUqW for ; Sun, 4 Sep 2016 16:30:53 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387F212B097 for ; Sun, 4 Sep 2016 16:30:53 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j189so55591135vkc.2 for ; Sun, 04 Sep 2016 16:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=q3KoFhCrihNYZeO8uC9eL50iZWguFQwt/XPaRzMUkW8=; b=YBKnfNaZ6Hqbg1pYci0voM9xIMsVjvOX05+DsghBGikqVJZdNAzUV1DRyygQOF/lZm FDlsUgm7v/tKbT85Jnq8JMstByF7xwqPuHJHlIWj7caK2DaUAV9R/ZMdDHKgwVq57lMk LxKriW6cIbbYG2FmLAPXJmnR8nUFQNFyDyQaxwrDGcrr4y/DPqkuqWEmxVWeqS75m4xb cGISY9gWlAWehBqyq2rIZfvME+gqBCQWp+h3IklcMttF09yjOng69FrxsPlv6BotUujF IunOSvSuSoRdLmmfOvX7dA8123EnBvY7kSGHhFDAv657s5t3uXFaqFX/cXscj3LFgVSC m9CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=q3KoFhCrihNYZeO8uC9eL50iZWguFQwt/XPaRzMUkW8=; b=CMmBgS34bj10IONWPg1xtArCbNTC6YEqg8AyhzJaU3BslqM+tgiADmW4ga8jd9Oil+ Doptbzy03whs28Wo5EeQs/9b6CO0gWxZOoJU9Dj2z6kL1UR2O7hFjf+NIBPbH8kHoafG +Z/CYgux5Om7GTjn9Pwz6Af2WzEftW3RmL14PLtn5oAhkUYaxY1DmNyriZbSYYiney6S pwoN3QlbYluBImK/+LQ42wJc7bX0U1TbONR93WZhZ7CkNPmqQJEOKP+xLhD0mwv/+Rpv yOTBvCVEbSUzw7NYpeuAVlMAWKEt8PZE1BSz09SzOaAoOjwzeDZ5ocvr/Kelz0TMyjZS 84Cw== X-Gm-Message-State: AE9vXwP6XbMs0jL1QfebbXOU/lRBf1d9SOVs/sGdAd/eza4XfT2dAFVtv5+2tapU4XZ5gCv3gOV9LCurs2t4UQ== X-Received: by 10.31.76.2 with SMTP id z2mr14377479vka.105.1473031833883; Sun, 04 Sep 2016 16:30:33 -0700 (PDT) MIME-Version: 1.0 Sender: emwebdev@gmail.com Received: by 10.159.55.200 with HTTP; Sun, 4 Sep 2016 16:30:33 -0700 (PDT) In-Reply-To: <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> From: Erin Millard Date: Mon, 5 Sep 2016 09:30:33 +1000 X-Google-Sender-Auth: Tlwn2iMIjWW8PuNpMsmC4RXvBzE Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a114db7d2339ca6053bb6f3ee Archived-At: Cc: peter@filament.com, precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 23:31:56 -0000 --001a114db7d2339ca6053bb6f3ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; do we = really > >>> want to limit this to UTF-8 only? Is this for comparison purposes? > >>> Then again, 99.99% of the time UTF-8 is what you should be using > >>> anyways, so I'm not sure that it matters. > >> > >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > > > > PRECIS is mostly encoding agnostic; implementations might favor a > > specific encoding, but I don't think anything in the spec specifically > > *needs* UTF-8. That being said, there are so few reasons to use > > anything other than UTF-8 that I don't think it really matters, it was > > just curious to me that some of the PRECIS related specs called out > > UTF-8 and some didn't. > > I thought they all did, but will double-check. This actually became a bigger issue when attempting to implement PRECIS prepare in JavaScript for the browser. JavaScript doesn't have native UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 library. It didn't make a lot of sense to me either, since all the encoding affects is how you go from string to code points, and vice versa. It had no effect on the rest of my implementation. I could absolutely be missing something, but compared to how focused the rest of the spec is, the UTF-8 requirement seemed like an afterthought. Can anyone explain which parts of PRECIS are actually predicated on the original string being encoded in UTF-8? On 5 September 2016 at 04:54, Peter Saint-Andre wrote: > > > > On Sep 4, 2016, at 8:28 AM, Sam Whited wrote: > > > > On Sat, Sep 3, 2016 at 4:21 PM, Peter Saint-Andre > wrote: > >>> * =C2=A72.1: "May any instances of non-ASCII space be mapped=E2=80=A6= " sounds odd, > >>> should this just say "Instances of non-ASCII space should be mapped= =E2=80=A6" > >> > >> Typo: s/May/Map/ > > > > That makes the document read: "Map any instances of non-ASCII space be > > mapped to ASCII space"; the "be mapped" still needs to be removed in > > the current draft. > > Oops. Easy enough to fix, though! > > > >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; do we = really > >>> want to limit this to UTF-8 only? Is this for comparison purposes? > >>> Then again, 99.99% of the time UTF-8 is what you should be using > >>> anyways, so I'm not sure that it matters. > >> > >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > > > > PRECIS is mostly encoding agnostic; implementations might favor a > > specific encoding, but I don't think anything in the spec specifically > > *needs* UTF-8. That being said, there are so few reasons to use > > anything other than UTF-8 that I don't think it really matters, it was > > just curious to me that some of the PRECIS related specs called out > > UTF-8 and some didn't. > > I thought they all did, but will double-check. > > Thanks! > > Peter > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > --001a114db7d2339ca6053bb6f3ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>> * =C2=A72.2 Specif= ies that UTF-8 MUST be used as the encoding; do we really
>>> w= ant to limit this to UTF-8 only? Is this for comparison purposes?
>&g= t;> Then again, 99.99% of the time UTF-8 is what you should be using
= >>> anyways, so I'm not sure that it matters.
>>
&= gt;> UTF-8 is your friend, and everything in PRECIS is UTF-8.
>> PRECIS is mostly encoding agnostic; implementations might favor a
= > specific encoding, but I don't think anything in the spec specific= ally
> *needs* UTF-8. That being said, there are so few reasons to us= e
> anything other than UTF-8 that I don't think it really matter= s, it was
> just curious to me that some of the PRECIS related specs = called out
> UTF-8 and some didn't.

I thought they all did, but will double-check.

This actually became a bigger issue when attem= pting to implement PRECIS prepare in JavaScript for the browser. JavaScript= doesn't have native UTF-8 support, so this meant the extra bloat of br= inging in a UTF-8 library.

It didn't make a lo= t of sense to me either, since all the encoding affects is how you go from = string to code points, and vice versa. It had no effect on the rest of my i= mplementation. I could absolutely be missing something, but compared to how= focused the rest of the spec is, the UTF-8 requirement seemed like an afte= rthought.

Can anyone explain which parts of PRECIS= are actually predicated on the original string being encoded in UTF-8?


On 5 September 2016 at 04:54, Peter Saint-Andre <= ;stpeter@stpeter.im= > wrote:
<= br>
> On Sep 4, 2016, at 8:28 AM, Sam Whited <sam@samwhited.com> wrote:
>
> On Sat, Sep 3, 2016 at 4:21 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>>> * =C2=A72.1: "May any instances of non-ASCII space be map= ped=E2=80=A6" sounds odd,
>>> should this just say "Instances of non-ASCII space should= be mapped=E2=80=A6"
>>
>> Typo: s/May/Map/
>
> That makes the document read: "Map any instances of non-ASCII spa= ce be
> mapped to ASCII space"; the "be mapped" still needs to = be removed in
> the current draft.

Oops. Easy enough to fix, though!
>
>>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding;= do we really
>>> want to limit this to UTF-8 only? Is this for comparison purpo= ses?
>>> Then again, 99.99% of the time UTF-8 is what you should be usi= ng
>>> anyways, so I'm not sure that it matters.
>>
>> UTF-8 is your friend, and everything in PRECIS is UTF-8.
>
> PRECIS is mostly encoding agnostic; implementations might favor a
> specific encoding, but I don't think anything in the spec specific= ally
> *needs* UTF-8. That being said, there are so few reasons to use
> anything other than UTF-8 that I don't think it really matters, it= was
> just curious to me that some of the PRECIS related specs called out > UTF-8 and some didn't.

I thought they all did, but will double-check.

Thanks!

Peter
_____________________= __________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

--001a114db7d2339ca6053bb6f3ee-- From nobody Sun Sep 4 17:34:52 2016 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 0114712B0CA for ; Sun, 4 Sep 2016 17:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oBY_5fN14gSi for ; Sun, 4 Sep 2016 17:34:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6AAC12B00D for ; Sun, 4 Sep 2016 17:34:49 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 75051F0793; Sun, 4 Sep 2016 18:35:00 -0600 (MDT) To: Erin Millard References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> From: Peter Saint-Andre Message-ID: <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> Date: Sun, 4 Sep 2016 18:34:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 Sep 2016 00:34:51 -0000 On 9/4/16 5:30 PM, Erin Millard wrote: > >>> * §2.2 Specifies that UTF-8 MUST be used as the encoding; do we really > >>> want to limit this to UTF-8 only? Is this for comparison purposes? > >>> Then again, 99.99% of the time UTF-8 is what you should be using > >>> anyways, so I'm not sure that it matters. > >> > >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > > > > PRECIS is mostly encoding agnostic; implementations might favor a > > specific encoding, but I don't think anything in the spec specifically > > *needs* UTF-8. That being said, there are so few reasons to use > > anything other than UTF-8 that I don't think it really matters, it was > > just curious to me that some of the PRECIS related specs called out > > UTF-8 and some didn't. > > I thought they all did, but will double-check. > > > This actually became a bigger issue when attempting to implement PRECIS > prepare in JavaScript for the browser. JavaScript doesn't have native > UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 library. > > It didn't make a lot of sense to me either, since all the encoding > affects is how you go from string to code points, and vice versa. It had > no effect on the rest of my implementation. I could absolutely be > missing something, but compared to how focused the rest of the spec is, > the UTF-8 requirement seemed like an afterthought. > > Can anyone explain which parts of PRECIS are actually predicated on the > original string being encoded in UTF-8? Are we perhaps getting confused between the encoding that is sent over the wire and the encoding that is used within the processing application? In general, we in the IETF prefer to send UTF-8 over the wire. However, it's true that this is a matter for the "using protocol" (e.g., I distinctly recall an extremely long thread in the XMPP WG years ago about whether to support only UTF-8 or to give clients and servers the ability to also use UTF-16 - and "UTF-8 only" won that debate). Given that some protocols or other technologies that use PRECIS might use UTF-16 or give applications the ability to choose an encoding, you're probably right that it makes sense to relax the rule for PRECIS itself. I'll think about this some more and propose some text. Peter From nobody Sun Sep 4 17:50:16 2016 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 5CCED12B109 for ; Sun, 4 Sep 2016 17:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EvCLg5eRYfQv for ; Sun, 4 Sep 2016 17:50:13 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBDA12B107 for ; Sun, 4 Sep 2016 17:50:13 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q42so161556854uaq.1 for ; Sun, 04 Sep 2016 17:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5z6drAFwWQ6Eyf83UHOGqgYzD8x0U9tmnTWkp2HY3lk=; b=AHOJAxRXLE/fuYewEbZ7GlQe/dQFDSBSR/o8yApXoIV9SPNxRETLsL9lSHk6zuyVeW DZBsPj1lU5o3CVlU+wSquHj6mqkwdr/Kp3YyN1ClFdpwaXhv+Pu8yWoFHo9Q0rls9zOx FjhEYtF2IPvcB2YYq4w+l6pB4S+Q2FYQmphWT7foL08VFNCTB6RoOtKP4z9k/Gj7W4NP NB0FPPP5lUA4x28lSLBFhWdlE1QIXfX2SU7RcitwLRm9n/4MbIuZir0jQK53CwtSz39W KWGDuypExZ5ameGAILirRsZiBjlXzje9dlai/bqE7bwxrKwk9+CoYgFeTKGvlRUNTXKT QmLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5z6drAFwWQ6Eyf83UHOGqgYzD8x0U9tmnTWkp2HY3lk=; b=ODlkI8bWoiWm6XCnv9RzEH8105lAeP/dKfpxKvoobODxpw5syH+UC7ENTBU2HyDsNF 2fLgac1N1gswVviUM6pcrRldqJ9eMxG5mf7jqfa9M2dfxvBWikIXNThSSfioaVlDX19D Y1yCA/Q0JdvdNOi/nsuQt2NkcKV3tPUf6yEnu7Yz2jyc5fujRye8xI1pPa3y2WkNEqTj bU8zaAFdr7H9wzaC6qguyVRCk7OblPYzGcOY5o4hsmIY+FxQxG6MIo7v11f7QGGc4Ub6 iBCuoJFudsYUSuQPmHMmOEmAZ+T9EB/sNxg2QnvFH3T/ZPhZgiJ9tXQWtgVddGetw2un SS8g== X-Gm-Message-State: AE9vXwNXq+D/dEaNmhOKkDQ7CxF76Dd/JkaEeuu82XSTNJBn2PWc5bfmlyEzM+dsInN3rrNYAoUDwTIDET6fUw== X-Received: by 10.176.0.108 with SMTP id 99mr12191253uai.43.1473036612538; Sun, 04 Sep 2016 17:50:12 -0700 (PDT) MIME-Version: 1.0 Sender: emwebdev@gmail.com Received: by 10.159.55.200 with HTTP; Sun, 4 Sep 2016 17:50:12 -0700 (PDT) In-Reply-To: <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> From: Erin Millard Date: Mon, 5 Sep 2016 10:50:12 +1000 X-Google-Sender-Auth: I6CMWdQi8f4lXepS9HTsnLImTMI Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a113f2ba008154d053bb8109b Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 Sep 2016 00:50:15 -0000 --001a113f2ba008154d053bb8109b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're probably right. I was not referring to over-the-wire encoding, just the preparation, enforcement, and comparison algorithms themselves. The use-case I have in mind is just to give users some immediate feedback about invalid characters in the browser, before any over-the-wire transmission takes place. On 5 September 2016 at 10:34, Peter Saint-Andre wrote: > On 9/4/16 5:30 PM, Erin Millard wrote: > >> >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding; d= o we >> really >> >>> want to limit this to UTF-8 only? Is this for comparison purpose= s? >> >>> Then again, 99.99% of the time UTF-8 is what you should be using >> >>> anyways, so I'm not sure that it matters. >> >> >> >> UTF-8 is your friend, and everything in PRECIS is UTF-8. >> > >> > PRECIS is mostly encoding agnostic; implementations might favor a >> > specific encoding, but I don't think anything in the spec >> specifically >> > *needs* UTF-8. That being said, there are so few reasons to use >> > anything other than UTF-8 that I don't think it really matters, it >> was >> > just curious to me that some of the PRECIS related specs called ou= t >> > UTF-8 and some didn't. >> >> I thought they all did, but will double-check. >> >> >> This actually became a bigger issue when attempting to implement PRECIS >> prepare in JavaScript for the browser. JavaScript doesn't have native >> UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 >> library. >> >> It didn't make a lot of sense to me either, since all the encoding >> affects is how you go from string to code points, and vice versa. It had >> no effect on the rest of my implementation. I could absolutely be >> missing something, but compared to how focused the rest of the spec is, >> the UTF-8 requirement seemed like an afterthought. >> >> Can anyone explain which parts of PRECIS are actually predicated on the >> original string being encoded in UTF-8? >> > > Are we perhaps getting confused between the encoding that is sent over th= e > wire and the encoding that is used within the processing application? > > In general, we in the IETF prefer to send UTF-8 over the wire. However, > it's true that this is a matter for the "using protocol" (e.g., I > distinctly recall an extremely long thread in the XMPP WG years ago about > whether to support only UTF-8 or to give clients and servers the ability = to > also use UTF-16 - and "UTF-8 only" won that debate). Given that some > protocols or other technologies that use PRECIS might use UTF-16 or give > applications the ability to choose an encoding, you're probably right tha= t > it makes sense to relax the rule for PRECIS itself. > > I'll think about this some more and propose some text. > > Peter > > --001a113f2ba008154d053bb8109b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're probably right. I was not referring to=C2=A0ove= r-the-wire=C2=A0encoding, just the preparation, enforcement, and comparison= algorithms themselves.

The use-case I have in mind is j= ust to give users some immediate feedback about invalid characters in the b= rowser, before any over-the-wire transmission takes place.

On 5 September 2016 at= 10:34, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 9/4/16 5:30 PM, Erin Milla= rd wrote:
=C2=A0 =C2=A0 >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as= the encoding; do we really
=C2=A0 =C2=A0 >>> want to limit this to UTF-8 only? Is this for co= mparison purposes?
=C2=A0 =C2=A0 >>> Then again, 99.99% of the time UTF-8 is what you= should be using
=C2=A0 =C2=A0 >>> anyways, so I'm not sure that it matters. =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> UTF-8 is your friend, and everything in PRECIS is UT= F-8.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > PRECIS is mostly encoding agnostic; implementations migh= t favor a
=C2=A0 =C2=A0 > specific encoding, but I don't think anything in the= spec specifically
=C2=A0 =C2=A0 > *needs* UTF-8. That being said, there are so few reasons= to use
=C2=A0 =C2=A0 > anything other than UTF-8 that I don't think it real= ly matters, it was
=C2=A0 =C2=A0 > just curious to me that some of the PRECIS related specs= called out
=C2=A0 =C2=A0 > UTF-8 and some didn't.

=C2=A0 =C2=A0 I thought they all did, but will double-check.


This actually became a bigger issue when attempting to implement PRECIS
prepare in JavaScript for the browser. JavaScript doesn't have native UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 library= .

It didn't make a lot of sense to me either, since all the encoding
affects is how you go from string to code points, and vice versa. It had no effect on the rest of my implementation. I could absolutely be
missing something, but compared to how focused the rest of the spec is,
the UTF-8 requirement seemed like an afterthought.

Can anyone explain which parts of PRECIS are actually predicated on the
original string being encoded in UTF-8?

 Are we perhaps getting confused between the encoding that is sent over the = wire and the encoding that is used within the processing application?

In general, we in the IETF prefer to send UTF-8 over the wire. However, it&= #39;s true that this is a matter for the "using protocol" (e.g., = I distinctly recall an extremely long thread in the XMPP WG years ago about= whether to support only UTF-8 or to give clients and servers the ability t= o also use UTF-16 - and "UTF-8 only" won that debate). Given that= some protocols or other technologies that use PRECIS might use UTF-16 or g= ive applications the ability to choose an encoding, you're probably rig= ht that it makes sense to relax the rule for PRECIS itself.

I'll think about this some more and propose some text.

Peter


--001a113f2ba008154d053bb8109b-- From nobody Mon Sep 5 14:47:24 2016 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 9AF7412B46D for ; Mon, 5 Sep 2016 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0aIh9SKtgtKr for ; Mon, 5 Sep 2016 14:47:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5868D12B445 for ; Mon, 5 Sep 2016 14:47:21 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EECA4F0793; Mon, 5 Sep 2016 15:47:35 -0600 (MDT) To: Erin Millard References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> From: Peter Saint-Andre Message-ID: <8436c38d-c652-1268-2b0a-deb75b5ecdd4@stpeter.im> Date: Mon, 5 Sep 2016 15:46:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 05 Sep 2016 21:47:22 -0000 On 9/4/16 6:34 PM, Peter Saint-Andre wrote: > On 9/4/16 5:30 PM, Erin Millard wrote: >> >>> * §2.2 Specifies that UTF-8 MUST be used as the encoding; do >> we really >> >>> want to limit this to UTF-8 only? Is this for comparison >> purposes? >> >>> Then again, 99.99% of the time UTF-8 is what you should be using >> >>> anyways, so I'm not sure that it matters. >> >> >> >> UTF-8 is your friend, and everything in PRECIS is UTF-8. >> > >> > PRECIS is mostly encoding agnostic; implementations might favor a >> > specific encoding, but I don't think anything in the spec >> specifically >> > *needs* UTF-8. That being said, there are so few reasons to use >> > anything other than UTF-8 that I don't think it really matters, >> it was >> > just curious to me that some of the PRECIS related specs called out >> > UTF-8 and some didn't. >> >> I thought they all did, but will double-check. >> >> >> This actually became a bigger issue when attempting to implement PRECIS >> prepare in JavaScript for the browser. JavaScript doesn't have native >> UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 >> library. >> >> It didn't make a lot of sense to me either, since all the encoding >> affects is how you go from string to code points, and vice versa. It had >> no effect on the rest of my implementation. I could absolutely be >> missing something, but compared to how focused the rest of the spec is, >> the UTF-8 requirement seemed like an afterthought. >> >> Can anyone explain which parts of PRECIS are actually predicated on the >> original string being encoded in UTF-8? > > Are we perhaps getting confused between the encoding that is sent over > the wire and the encoding that is used within the processing application? > > In general, we in the IETF prefer to send UTF-8 over the wire. However, > it's true that this is a matter for the "using protocol" (e.g., I > distinctly recall an extremely long thread in the XMPP WG years ago > about whether to support only UTF-8 or to give clients and servers the > ability to also use UTF-16 - and "UTF-8 only" won that debate). Given > that some protocols or other technologies that use PRECIS might use > UTF-16 or give applications the ability to choose an encoding, you're > probably right that it makes sense to relax the rule for PRECIS itself. > > I'll think about this some more and propose some text. As promised, I've thought about it further and I agree that specifying an encoding of UTF-8 is not really appropriate in 7613bis and 7700bis. In fact, RFC 7564 (the PRECIS framework) states the following in §13.1: Although strings that are consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629], the exact encoding is a matter for the application protocol that uses PRECIS, not for the PRECIS framework. Thus, for instance, it's fine for RFC 7622, which defines the address format in XMPP, to specify an encoding of UTF-8, but not for 7613bis or 7700bis to do so. I notice that RFC 5890 (for IDNA) has text like this o A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). Text similar to that might be best for 7613bis and 7700bis. Peter From nobody Mon Sep 5 15:15:48 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3486A12B0C2; Mon, 5 Sep 2016 15:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147311374720.3045.1854267689527222698.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 15:15:47 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7564bis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:15:47 -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 of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-03.txt Pages : 40 Date : 2016-09-05 Abstract: Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and 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, enforcement, 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 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-03 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 nobody Mon Sep 5 15:16:07 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B70012B472; Mon, 5 Sep 2016 15:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147311376110.3079.9023321305467604409.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 15:16:01 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7613bis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:16:06 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-03.txt Pages : 24 Date : 2016-09-05 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-03 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 nobody Mon Sep 5 15:16:18 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA26A12B481; Mon, 5 Sep 2016 15:16:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147311377075.3022.17451160553872194933.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 15:16:10 -0700 Archived-At: Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-7700bis-03.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:16:11 -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 of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-03.txt Pages : 11 Date : 2016-09-05 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-03 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 nobody Mon Sep 5 21:36:05 2016 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 D579F12B096 for ; Mon, 5 Sep 2016 21:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WF0RZvjk7yRQ for ; Mon, 5 Sep 2016 21:36:03 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD9412B04C for ; Mon, 5 Sep 2016 21:36:02 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id j189so81087315vkc.2 for ; Mon, 05 Sep 2016 21:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HX9N+PlP2LSFE6Sd4MxJPzuh25ePlIo2x+pKWHpaDv4=; b=ulPaTQa6sicqguyDnmZp9eVqBT0sfBFsOsLS4cKPmQL8GaeI+3rsZCwHZvuCUVviAc tMSXisjkd+2nmqghGkSL8VGqTAK+kH/RsBusTuSUAQJ7H7HZxrh6Oc+qRyziXSIYym28 yv8bBe1pG2GE9xomAVu+HCHneoAoDNKc7oXHmcT259dCqistOReF8kR8ERM8tN6mfZR7 lhJXSmGAAwl+BOx3XBnrYFX2XmYXPMXqztPfmKFMSONwZ8qa2NKbFpCgqO7pDCvyTLpd riiqwdCqFPT04Jbo9p8hRhptZYPU/GMoGvZNeOvBTrNWdUO/+lh61b8zgV5UQH2I6eyA LJ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HX9N+PlP2LSFE6Sd4MxJPzuh25ePlIo2x+pKWHpaDv4=; b=G8PPiF7GlmjHWnTEErSXNwM8O7QItwLAH2jwGjsKjKNMFEFrztvFJXVLM1LAEC46yT ZyiMk7jievC5cAogbCHmmcP1NSguE3fkgVnMsVmP99JkDBa8wcqufhNGKyAet2Xm1WbC 183JZdyieJ31Pncj3RfY5iwQ5SPHSBYos80On0XerwYl0n0hxB36tYnqyrM35ZrOhhER 0PY8/1yW7a1878LQ4bLowFxFC1giv/zpfSwYNmSEzj2JqB+/9pp9Rhxro96uJfSkiH2g qINvJktcmi+e81eRaVbC+4d4S3VJ04fW6Y7AhH/4phfKLJnHLuFGf13tDUjshsbgUCz1 FtHw== X-Gm-Message-State: AE9vXwN6iq0fxHSBSEza/HXMW51dQLxE7VDGpow/kfPqPFCNaoPv8XWr0MTFxgIDbYWCUvGCBkxL0x2aAe7QtQ== X-Received: by 10.31.16.205 with SMTP id 74mr11396363vkq.17.1473136561768; Mon, 05 Sep 2016 21:36:01 -0700 (PDT) MIME-Version: 1.0 References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> <8436c38d-c652-1268-2b0a-deb75b5ecdd4@stpeter.im> In-Reply-To: <8436c38d-c652-1268-2b0a-deb75b5ecdd4@stpeter.im> From: Erin Millard Date: Tue, 06 Sep 2016 04:35:51 +0000 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a114360d2784fe2053bcf55ac Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 06 Sep 2016 04:36:05 -0000 --001a114360d2784fe2053bcf55ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do remember now, seeing that section in RFC 7564, and thinking that the other profiles contradicted it. Seems like a good change to me! On Tue, 6 Sep 2016 at 07:47 Peter Saint-Andre wrote: > On 9/4/16 6:34 PM, Peter Saint-Andre wrote: > > On 9/4/16 5:30 PM, Erin Millard wrote: > >> >>> * =C2=A72.2 Specifies that UTF-8 MUST be used as the encoding;= do > >> we really > >> >>> want to limit this to UTF-8 only? Is this for comparison > >> purposes? > >> >>> Then again, 99.99% of the time UTF-8 is what you should be usi= ng > >> >>> anyways, so I'm not sure that it matters. > >> >> > >> >> UTF-8 is your friend, and everything in PRECIS is UTF-8. > >> > > >> > PRECIS is mostly encoding agnostic; implementations might favor = a > >> > specific encoding, but I don't think anything in the spec > >> specifically > >> > *needs* UTF-8. That being said, there are so few reasons to use > >> > anything other than UTF-8 that I don't think it really matters, > >> it was > >> > just curious to me that some of the PRECIS related specs called > out > >> > UTF-8 and some didn't. > >> > >> I thought they all did, but will double-check. > >> > >> > >> This actually became a bigger issue when attempting to implement PRECI= S > >> prepare in JavaScript for the browser. JavaScript doesn't have native > >> UTF-8 support, so this meant the extra bloat of bringing in a UTF-8 > >> library. > >> > >> It didn't make a lot of sense to me either, since all the encoding > >> affects is how you go from string to code points, and vice versa. It h= ad > >> no effect on the rest of my implementation. I could absolutely be > >> missing something, but compared to how focused the rest of the spec is= , > >> the UTF-8 requirement seemed like an afterthought. > >> > >> Can anyone explain which parts of PRECIS are actually predicated on th= e > >> original string being encoded in UTF-8? > > > > Are we perhaps getting confused between the encoding that is sent over > > the wire and the encoding that is used within the processing applicatio= n? > > > > In general, we in the IETF prefer to send UTF-8 over the wire. However, > > it's true that this is a matter for the "using protocol" (e.g., I > > distinctly recall an extremely long thread in the XMPP WG years ago > > about whether to support only UTF-8 or to give clients and servers the > > ability to also use UTF-16 - and "UTF-8 only" won that debate). Given > > that some protocols or other technologies that use PRECIS might use > > UTF-16 or give applications the ability to choose an encoding, you're > > probably right that it makes sense to relax the rule for PRECIS itself. > > > > I'll think about this some more and propose some text. > > As promised, I've thought about it further and I agree that specifying > an encoding of UTF-8 is not really appropriate in 7613bis and 7700bis. > In fact, RFC 7564 (the PRECIS framework) states the following in =C2=A713= .1: > > Although strings that are consumed in PRECIS-based application > protocols are often encoded using UTF-8 [RFC3629], the exact encoding > is a matter for the application protocol that uses PRECIS, not for > the PRECIS framework. > > Thus, for instance, it's fine for RFC 7622, which defines the address > format in XMPP, to specify an encoding of UTF-8, but not for 7613bis or > 7700bis to do so. > > I notice that RFC 5890 (for IDNA) has text like this > > o A "U-label" is an IDNA-valid string of Unicode characters, in > Normalization Form C (NFC) and including at least one non-ASCII > character, expressed in a standard Unicode Encoding Form (such as > UTF-8). > > Text similar to that might be best for 7613bis and 7700bis. > > Peter > > --001a114360d2784fe2053bcf55ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do remember now, seeing that section in=C2=A0RFC 7564, and thinking that the other profiles contradicted= it.=C2=A0Seems like a go= od change to me!

On Tue, 6 Sep 2016 at 07:47 Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 9/4/16 6:34 PM, Peter Saint-Andre wrote:
> On 9/4/16 5:30 PM, Erin Millard wrote:
>>=C2=A0 =C2=A0 =C2=A0>>> * =C2=A72.2 Specifies that UTF-8 M= UST be used as the encoding; do
>> we really
>>=C2=A0 =C2=A0 =C2=A0>>> want to limit this to UTF-8 only? = Is this for comparison
>> purposes?
>>=C2=A0 =C2=A0 =C2=A0>>> Then again, 99.99% of the time UTF= -8 is what you should be using
>>=C2=A0 =C2=A0 =C2=A0>>> anyways, so I'm not sure that = it matters.
>>=C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0>> UTF-8 is your friend, and everything i= n PRECIS is UTF-8.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> PRECIS is mostly encoding agnostic; implem= entations might favor a
>>=C2=A0 =C2=A0 =C2=A0> specific encoding, but I don't think a= nything in the spec
>> specifically
>>=C2=A0 =C2=A0 =C2=A0> *needs* UTF-8. That being said, there are = so few reasons to use
>>=C2=A0 =C2=A0 =C2=A0> anything other than UTF-8 that I don't= think it really matters,
>> it was
>>=C2=A0 =C2=A0 =C2=A0> just curious to me that some of the PRECIS= related specs called out
>>=C2=A0 =C2=A0 =C2=A0> UTF-8 and some didn't.
>>
>>=C2=A0 =C2=A0 =C2=A0I thought they all did, but will double-check.<= br> >>
>>
>> This actually became a bigger issue when attempting to implement P= RECIS
>> prepare in JavaScript for the browser. JavaScript doesn't have= native
>> UTF-8 support, so this meant the extra bloat of bringing in a UTF-= 8
>> library.
>>
>> It didn't make a lot of sense to me either, since all the enco= ding
>> affects is how you go from string to code points, and vice versa. = It had
>> no effect on the rest of my implementation. I could absolutely be<= br> >> missing something, but compared to how focused the rest of the spe= c is,
>> the UTF-8 requirement seemed like an afterthought.
>>
>> Can anyone explain which parts of PRECIS are actually predicated o= n the
>> original string being encoded in UTF-8?
>
> Are we perhaps getting confused between the encoding that is sent over=
> the wire and the encoding that is used within the processing applicati= on?
>
> In general, we in the IETF prefer to send UTF-8 over the wire. However= ,
> it's true that this is a matter for the "using protocol"= (e.g., I
> distinctly recall an extremely long thread in the XMPP WG years ago > about whether to support only UTF-8 or to give clients and servers the=
> ability to also use UTF-16 - and "UTF-8 only" won that debat= e). Given
> that some protocols or other technologies that use PRECIS might use > UTF-16 or give applications the ability to choose an encoding, you'= ;re
> probably right that it makes sense to relax the rule for PRECIS itself= .
>
> I'll think about this some more and propose some text.

As promised, I've thought about it further and I agree that specifying<= br> an encoding of UTF-8 is not really appropriate in 7613bis and 7700bis.
In fact, RFC 7564 (the PRECIS framework) states the following in =C2=A713.1= :

=C2=A0 =C2=A0 Although strings that are consumed in PRECIS-based applicatio= n
=C2=A0 =C2=A0 protocols are often encoded using UTF-8 [RFC3629], the exact = encoding
=C2=A0 =C2=A0 is a matter for the application protocol that uses PRECIS, no= t for
=C2=A0 =C2=A0 the PRECIS framework.

Thus, for instance, it's fine for RFC 7622, which defines the address format in XMPP, to specify an encoding of UTF-8, but not for 7613bis or
7700bis to do so.

I notice that RFC 5890 (for IDNA) has text like this

=C2=A0 =C2=A0 o=C2=A0 A "U-label" is an IDNA-valid string of Unic= ode characters, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Normalization Form C (NFC) and including at leas= t one non-ASCII
=C2=A0 =C2=A0 =C2=A0 =C2=A0character, expressed in a standard Unicode Encod= ing Form (such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0UTF-8).

Text similar to that might be best for 7613bis and 7700bis.

Peter

--001a114360d2784fe2053bcf55ac-- From nobody Tue Sep 6 07:47:12 2016 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 B9B1912B209 for ; Tue, 6 Sep 2016 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samwhited.com 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 Jfy16FW8_AcJ for ; Tue, 6 Sep 2016 07:47:10 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF6712B200 for ; Tue, 6 Sep 2016 07:47:10 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id t7so219864270qkh.1 for ; Tue, 06 Sep 2016 07:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GFUevMJWHGzDmS4GeM/INkqgeUWvTVG2FL1Y7krdI84=; b=wW3mKkXjCrG0R05uh8OpBMKqG2O90LsO6+CELUWr8YZlCEbG1lYqZXuuq3aOsYaw7o 3dkeCvQuIjs8WBTK+LUgBjgzM09QKR/SgeOPLt0npAsudwEqfwxfKJLKGtVsH1NnCqtZ XbPoA3nsXI8sFtgt1uJrY//xoeBA5OdVeKaKI= 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-transfer-encoding; bh=GFUevMJWHGzDmS4GeM/INkqgeUWvTVG2FL1Y7krdI84=; b=eNA/RPqtn7aCdL/P6bnJSHqgYcdq9IGJ33rLN176SIllgPnpyFn+8JTNTy1rbu48vL 1qkfLxBYI6dqHnLcCCYgb/0DZe0vOYW9+e06nkxqDWkh0bBa6ACSo8wFS5lVoziMd5Oh bHlsP7hx5H6LKvusCMukthq24KIJyc1PSEi30p3+NKgP+IQlKtowMJAujfh+oNDilg+C AlbQJEvwVO99/UbMIuqgrMdImqsegj7aDgF0P2SOK5hJrokkQAhfYSMDU/FtFaVPXAzh qQoUKb2O3DG7/4ntx8mHmm8HPFAgO1xB/s3rvgQVN1TkvzRC0GeAAshK4EWoHPxZjNS8 58sA== X-Gm-Message-State: AE9vXwOEOqZ+vS9aT+eF2GqYUjs36tkqie3thCDb2Wqe+C1PNaia64ydXXy89W+Z8cLsabqprGyJQPW/7mfoVg== X-Received: by 10.55.44.134 with SMTP id s128mr43292367qkh.177.1473173229468; Tue, 06 Sep 2016 07:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.7.136 with HTTP; Tue, 6 Sep 2016 07:46:29 -0700 (PDT) X-Originating-IP: [72.48.156.244] In-Reply-To: <8436c38d-c652-1268-2b0a-deb75b5ecdd4@stpeter.im> References: <20160505174255.20595.13753.idtracker@ietfa.amsl.com> <4A1BEC5B-4514-4BF3-AA81-412B94436591@stpeter.im> <1818edcd-efdd-4f3e-35a4-c347d8077851@stpeter.im> <8436c38d-c652-1268-2b0a-deb75b5ecdd4@stpeter.im> From: Sam Whited Date: Tue, 6 Sep 2016 09:46:29 -0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: precis@ietf.org Subject: Re: [precis] I-D Action: draft-ietf-precis-7700bis-01.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 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, 06 Sep 2016 14:47:11 -0000 On Mon, Sep 5, 2016 at 4:46 PM, Peter Saint-Andre wrot= e: > As promised, I've thought about it further and I agree that specifying an > encoding of UTF-8 is not really appropriate in 7613bis and 7700bis. Thanks Peter, I'm glad we came to the same conclusion; the new language sounds good to me= . =E2=80=94Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 From nobody Fri Sep 23 05:51:46 2016 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 014DD12BE11; Fri, 23 Sep 2016 05:51:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147463510498.344.3056236029839980551.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 05:51:44 -0700 Archived-At: Cc: precis-chairs@ietf.org, aamelnikov@fastmail.fm, precis@ietf.org Subject: [precis] precis - Not having a session at IETF 97 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.17 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 12:51:45 -0000 Marc Blanchet, a chair of the precis working group, indicated that the precis working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool.