From nobody Tue May 20 19:16:11 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958DD1A0429; Tue, 20 May 2014 19:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Miz1YYI3w29H; Tue, 20 May 2014 19:16:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA51A040F; Tue, 20 May 2014 19:16:08 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29B0D4032A; Tue, 20 May 2014 20:16:01 -0600 (MDT) Message-ID: <537C0C61.8090404@stpeter.im> Date: Tue, 20 May 2014 20:16:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> <5359204A.90100@stpeter.im> <53592266.2060509@cs.tcd.ie> In-Reply-To: <53592266.2060509@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/1rX0zbNO5f5Omwo1L-_EGZLVyAE Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 02:16:10 -0000 Hi Stephen, sorry about the delayed reply - I'm just not getting back to processing feedback on this I-D. On 4/24/14, 8:40 AM, Stephen Farrell wrote: > > Hi Peter, > > On 04/24/2014 03:31 PM, Peter Saint-Andre wrote: >> On 4/24/14, 7:20 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-precis-framework-16: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - I agree with Bary's discuss - it seems weird to not >>> have the initial registries in hand when the RFC is >>> being issued. People will, I guess, implement from >>> Appendix A here anyway, so why not either delete this >>> and get the registry in place, or else make Appendix A >>> be the initial registry content. >> >> Appendix A has been checked using two implementations. The question is >> whether we want to base the initial registration on a third. >> >> But yes, the *initial* registration *could* use Appendix A once it has >> been reviewed by the designated expert (who might find errors, despite >> the fact that Takahiro Nemoto and I checked our independent results and >> came to agreement on the derived properties). >> >> This was discussed on the WG list, see for instance: >> >> http://www.ietf.org/mail-archive/web/precis/current/msg00605.html > > I'm fine that you've discussed this with Barry. The exact disposition of the appendix and the registration process remains to be clarified, in part based on Pete's work in finding a designated expert. >>> 7.7: This uses the empty set, which is puzzling. I think >>> you mean that this set is to be populated by the DE in >>> the IANA registries but if so, saying so would be good. >> >> We are simply referencing RFC 5892 here: >> >> http://tools.ietf.org/html/rfc5892#section-2.7 >> >> Further, the PRECIS Derived Property Value Registry will specify only >> the derived properties (e.g., UNASSIGNED or PVALID), not the interim >> steps used to calculate the derived properties (e.g., HasCompat or >> BackwardCompatible). So the latter values are never populated into the >> registry. > > The bit that I found odd (no more) was: "G: cp is in {}" > > I think that's just saying there are no code points in this > category at the moment, which is fine, but that wasn't > (clearly) stated, instead it says "This category includes..." > which is a bit confusing since its the empty set. > > If you wanted, s/This category includes/This currently > empty category will include/ would be clearer for me. > (Assuming I read it right:-) That part is quoted from RFC 5892. However, in the note that precedes the quoted text, I suggest that we add the following sentence: At the time of this writing (and also at the time that RFC 5892 was published), this category consisted of the empty set; however, that is subject to change as described in RFC 5892. >>> 10.5: This says that a) its all too hard but also b) >>> "Nevertheless, specifications for application protocols >>> that use this framework MUST describe how confusable >>> characters can be abused to compromise the security of >>> systems that use the protocol in question, along with any >>> protocol-specific suggestions for overcoming those >>> threats." That seems like a 6919 MUST (but we know you >>> won't) to me. Is that a good plan? >> >> s/MUST/are strongly encouraged to/ ? > > Yes, I think that's better. Will fix. >> One example of what an application protocol spec could say is here: >> >> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-7.3.2 > > Right. I note that that's over a page of text. Seems like > a pity it can't be much shorter, but I guess that's just > life;-) Sorry, internationalization is messy. >>> 10.6: Prompted by the secdir review, it might be worth a >>> few words on password hashing, which is very common. E.g. >>> say that the canonical form is input to hashing and >>> therefore just can't be mucked about with. (But say that >>> nicely:-) >> >> Well, draft-ietf-precis-saslprepbis currently says: >> >> In protocols that provide usernames as input to a cryptographic >> algorithm such as a hash function, the client will need to perform >> proper preparation of the username before applying the algorithm. >> >> and: >> >> In protocols that provide passwords as input to a cryptographic >> algorithm such as a hash function, the client will need to perform >> proper preparation of the password before applying the algorithm, >> since the password is not available to the server in plaintext form. >> >> Would some text along those lines in the security considerations of this >> document meet your needs? > > You already reference that draft from here so its probably > ok, but I guess the point is generic and not sasl-specific Actually, despite its title, draft-ietf-precis-saslprepbis is not really SASL-specific. > so it could (also) be mentioned here. Your call though, as > its a fairly minor and pretty obvious thing. Nothing is obvious. :-) We'll add some text here (I think I'll just copy and paste that paragraph from draft-ietf-precis-saslprepbis). Thanks again for your feedback. Peter From nobody Tue May 20 19:27:25 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B841A0442; Tue, 20 May 2014 19:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oUUZkXsW_Tk; Tue, 20 May 2014 19:27:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C41A042F; Tue, 20 May 2014 19:27:22 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D16F14032A; Tue, 20 May 2014 20:27:17 -0600 (MDT) Message-ID: <537C0F05.1050701@stpeter.im> Date: Tue, 20 May 2014 20:27:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pete Resnick , Barry Leiba References: <20140423224227.12329.68404.idtracker@ietfa.amsl.com> <5358512A.1040706@qti.qualcomm.com> <53592B13.3060707@qti.qualcomm.com> In-Reply-To: <53592B13.3060707@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/RilHzOEY19CSnKwj_q4p1iYhLW4 Cc: The IESG , precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Barry Leiba's Discuss on draft-ietf-precis-framework-16: (with DISCUSS) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 02:27:23 -0000 On 4/24/14, 9:17 AM, Pete Resnick wrote: > On 4/24/14 9:19 AM, Barry Leiba wrote: >> It's good to hear that it won't be burdensome, but it still seems that >> the working group produced an incomplete document. > > Sort of. The problem is that it really isn't the IETF's expertise or > responsibility to create that sort of document. In fact what would be > ideal is to point to a document or registry controlled by the Unicode > Consortium. But the conclusion of the community during IDNA was that we > would not be provided such a stable reference. Given that, IDNA did a > de-reference; we'd create an IANA registry, run by a Unicode expert, but > that tracked the state of the properties that we needed for our > purposes. Not pretty or ideal, but practical. This WG followed that > lead, I think equally pragmatically. > > As you say, water under the bridge. I got email back and Patrik has > agreed to be the expert; I'll add a management item during agenda bash. > He'll prepare the contents of the registry and we should be good to go. Pete, with regard to the issue raised in the ops-dir review and elsewhere, how would you prefer to handle the 30-page codepoint table? Make it the initial registration (subject, of course, to designated expert review) or discard it as the scaffolding it is? Peter From nobody Wed May 21 15:08:19 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6F1A03BC; Wed, 21 May 2014 15:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kApl8UehTIMz; Wed, 21 May 2014 15:08:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4231A0389; Wed, 21 May 2014 15:08:06 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 38FB74032A; Wed, 21 May 2014 16:08:03 -0600 (MDT) Message-ID: <537D23C2.10709@stpeter.im> Date: Wed, 21 May 2014 16:08:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John C Klensin References: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> In-Reply-To: <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/KDED-dwA_2tqXSTRp3YDIj-KWJI Cc: precis@ietf.org, The IESG Subject: Re: [precis] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 22:08:13 -0000 My previous reply to this message was sent in a hurry right before the relevant IESG telechat. This reply provides, I hope, a more measured response. On 4/23/14, 10:17 PM, John C Klensin wrote: > Recommendation: Hold this document until the various categories > are exercised by at least a sampling of applicable profiles. As mentioned, we have 5 such profiles in somewhat advanced states: 1. draft-ietf-xmpp-6122bis (defines two profiles to replace two stringprep profiles) - completed WGLC in the XMPP WG 2. draft-ietf-precis-nickname (defines one profile for use by both MSRP and XMPP) - completed WGLC in the PRECIS WG 3. draft-ietf-precis-saslprepbis (defines one profile for usernames and one for passwords) - awaiting WGLC but widely discussed in the PRECIS and KITTEN working groups, IMHO it could undergo WGLC fairly soon > Make the problems with excessive profiles explicit; Would the following text help? ### If input strings that appear "the same" to users are programmatically considered to be distinct in different systems, or if input strings that appear distinct to users are programmatically considered to be "the same" in different systems, then users can be confused. Such confusion can have security implications, such as the false positives and false negatieves discussed in [RFC6943]. One starting goal of work on the PRECIS framework was to limit the number of times that users are confused (consistent with the "principle of least astonishment"). Unfortunately, this goal has been difficult to achieve given the large number of application protocols already in existence, each with its own conventions regarding allowable characters (see for example [I-D.saintandre-username-interop] with regard to various username constructs). Despite these difficulties, profiles should not be multiplied beyond necessity. In particular, application protocol designers should think long and hard before defining a new profile instead of using one that has already been defined, and if they decide to define a new profile then they should clearly explain their reasons for doing so. ### Suggestions for improvement are welcome. Right now I'm of the opinion that such text belongs in the security considerations, but perhaps it makes sense to place it much farther up in the document, even in the introduction. While thinking about this further in the middle of the night, I began to wonder if anyone has done usability studies on user astonishment in relation to internationalized strings. Do you know of any research we can reference here? > impose > requirements on additional profiles that include an explanation > of why they are needed given the user-level interoperability and > astonishment problems that can result from even three of them Do you think we need text beyond that quoted above? > and require a higher level of review and consensus for creating > new ones than "expert review". In RFC 5226 terms, are you suggesting specification required, RFC required, or IETF review? I get the sense that you'd prefer the latter. > Modify the Security > Considerations section to identify user astonishment and > consequent confusion about what rules are being applied in a > given PRECIS-User protocol as a risk and possible attack vector. Again, would the text quoted above suffice or do we need a more detailed description of the security implications? > [3] Not only should multiple profiles be discouraged for this > type of case by the Law of Least Astonishment, but general IETF > experience indicates that profiles are a bad idea and that > protocols that depend on them (and use a significant variety) > tend to be less successful than those that do not. I continue to have difficulty imagining how we can do without something like profiles, given the large number of identifiers already in the field. One possible way to overcome part of that problem would be to work on something like draft-saintandre-username-interop in the PRECIS WG and to strongly encourage (force?) applications to use that, at least for usernamey constructs. > [5] There are issues with the two classes that are defined in > this document that have not, I believe, been carefully addressed > in the WG. At a minimum, they need to be considered more > carefully in context with specific examples without preempting > the choices to be made for those examples. The following are > examples, not an exclusive list: > > (i) The "Contextual Rule" categories of IDNA2008 have proven to > be extremely problematic, confusing, and controversial enough to > be one of the key issues in the UTR 46 battles that have impeded > IDNA2008 adoption in some important communities. While I still > believe that the IDNA2008 decision was the right one, inclusion > of those characters as Valid for both classes [4] should, given > those bad experiences, require significantly more explanation > and/or justification than this draft appears to provide. If the > intent of incorporating this list in PRECIS is to provide for > compatibility with IDNA2008, the list should be incorporated by > reference (either to RFC 5892 and its successors or to a > separate documents that updates and replaces the list in RFC > 5892 as well as being used for PRECIS), not be provided as a > list of code points that could cause the two definitions to > diverge if changes are made to one or the other. The issue may > apply more generally to the other characters listed in Section > 7.6 and to other IDNA-derived elements of Section 7. As mentioned right before Section 7.1: The first ten categories (A-J) shown below were previously defined for IDNA2008 and are copied directly from [RFC5892]. Those are merely referenced here. Some of them are used here and some are not. Would it help to say that these definitions might change in the future if RFC 5892 is updated? > (ii) Characters with compatibility equivalents are problematic, > in large measure because of a Unicode issue that has been > extensively discussed in the past. Basically the compatibility > equivalency category mixes several unrelated and incompatible > (sic) groups of things under a single label. One extreme is > occupied by characters used with East Asian scripts that are > distinguished only by their widths. If the Unicode design > principles of "characters, not glyphs" and "plain text" had been > followed, these different-width variations would never have been > assigned different code points. As a contrasting example, the > relevance of, and distinctions among, special mathematical code > points distinguished by mathematical use and specific type > styles is less clear: treating them as separate characters may > be justified under some circumstances. A more extreme example > occurs with some Chinese characters that Unicode treats as > compatibility equivalents for other characters. That treatment > is usually (and perhaps always) appropriate when the "meaning" > of the characters is intended. But some of those characters > are, or historically have been, used in personal names. To the > extent to which those names are used as identifiers, e.g., for a > person thus named, treating them as invalid is inappropriate and > applying a compatibility mapping to them only slightly less bad. The many issues with compatibility equivalents provide strong reasons to exclude them from the IdentifierClass, which is what the WG did in Section 3.2.3. They are allowed in the FreeformClass, but we provide warnings about that in Section 10.3. I'll add a forward reference to 10.3 from 3.1 and 3.3. Suggestions are welcome if you feel that the warnings are not strong enough. > (iii) Experience with IDNA strongly suggests that > "DefaultIgnorable" is a bad idea. I don't recall discussion about this in the PRECIS WG, so thanks for raising the issue now. > Forbidding some (or perhaps > all) of these characters may be reasonable; treating them as if > they were not present impedes possibly-reasonable future > extensions and provides an attack vector for phishing and other > types of unpleasant behavior that do not appear to be called out > in Security Considerations. These characters are DISALLOWED, thus forbidden rather than treated as not present. > It is also worth noting that one > difference between IDNA2008 and this specification is that the > former is not profiled (except by registries providing their own > subsetting rules) while the latter is intended as a base for > profiling. While the order in which categorization rules is > applied in Section 8 provides some protection (perhaps > sufficient protection if the spec is never updated or used as > the basis for a different profile), Profiles are not allowed to override the order of rule-checking in the algorithm used to determine derived properties. > it is worth noting that some > code points appear in more than one category (e.g., the > notorious ZWJ and ZWNJ in both JoinControl (Section 7.8) and > PrecisIgnorableProperties (Section 7.13)) and that this should > at least be called out explicitly. There's no harm in doing so, for sure. Peter From nobody Wed May 21 18:02:02 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1D61A02D7; Wed, 21 May 2014 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNKmnD2-L_Sf; Wed, 21 May 2014 12:27:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061EE1A01A5; Wed, 21 May 2014 12:27:21 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WnCA1-000Cb5-EF; Wed, 21 May 2014 15:26:45 -0400 Date: Wed, 21 May 2014 15:27:15 -0400 From: John C Klensin To: Peter Saint-Andre , Stephen Farrell , The IESG Message-ID: <611230DBDCA1D832AE5C6E9A@[192.168.1.102]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john+xml@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/up90ZOhfYYB0vaIijRQfpv3lUb8 X-Mailman-Approved-At: Wed, 21 May 2014 18:02:01 -0700 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:27:22 -0000 (sorry -- bad address-- resending) --On Tuesday, 20 May, 2014 20:16 -0600 Peter Saint-Andre wrote: >... >> If you wanted, s/This category includes/This currently >> empty category will include/ would be clearer for me. >> (Assuming I read it right:-) > > That part is quoted from RFC 5892. However, in the note that > precedes the quoted text, I suggest that we add the following > sentence: > > At the time of this writing (and also at the time that > RFC 5892 was published), this category consisted of the > empty set; however, that is subject to change as described > in RFC 5892. Unless I misunderstand, if the kinds of exceptions that would justify using that category were to arise, we'd need separate review and evaluation systems and approvals for IDNA and PRECIS, even if they were largely performed by the same people. Moreover, if PRECIS stays with the profile model it is using now, we have no basis on which to judge whether this category (exceptions apply to all protocols and profiles) is adequate or whether each new version of Unicode requires per-protocol or per-profile reviews. That is another reason why a system that allows or encourages a growing family of profiles gives me the creeps. Six months ago, it would have been sensible to treat the above comment as largely theoretical: the category was reserved as a placeholder that we never expected to use. At this point, unless an apparent problem that was spotted in Unicode 7.0.0 beta is addressed in a serious way by UTC, the possibility of having to use the category is very real. It is also important to note that the problem was spotted by inspection by a moderately skilled human after it had successfully gotten through the usual testing implementations and preliminary review by the relevant expert. best, john From nobody Wed May 21 18:02:10 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02C01A0027; Wed, 21 May 2014 18:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwHaEmyEIGoY; Wed, 21 May 2014 18:02:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF81A0007; Wed, 21 May 2014 18:02:06 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CBFA64032A; Wed, 21 May 2014 19:01:51 -0600 (MDT) Message-ID: <537D4C7F.4070103@stpeter.im> Date: Wed, 21 May 2014 19:01:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John C Klensin , Stephen Farrell , The IESG References: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> <5359204A.90100@stpeter.im> <53592266.2060509@cs.tcd.ie> <537C0C61.8090404@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/jRwXWbiPO7NIF-_sp99Cv2B4azk Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:02:08 -0000 On 5/21/14, 1:26 PM, John C Klensin wrote: > > > --On Tuesday, 20 May, 2014 20:16 -0600 Peter Saint-Andre > wrote: > >> ... >>> If you wanted, s/This category includes/This currently >>> empty category will include/ would be clearer for me. >>> (Assuming I read it right:-) >> >> That part is quoted from RFC 5892. However, in the note that >> precedes the quoted text, I suggest that we add the following >> sentence: >> >> At the time of this writing (and also at the time that >> RFC 5892 was published), this category consisted of the >> empty set; however, that is subject to change as described >> in RFC 5892. > > Unless I misunderstand, if the kinds of exceptions that would > justify using that category were to arise, we'd need separate > review and evaluation systems and approvals for IDNA and PRECIS, > even if they were largely performed by the same people. Unless *I* misunderstand, the kinds of exceptions that would lead to populating the BackwardCompatible category specified in RFC 5892 are limited to adding characters to or removing characters from the LetterDigits category. If indeed one of our goals is to reduce the possibility of user astonishment, it seems preferable for the PRECIS classes (and profiles thereof) to track the BackwardCompatible category itself, rather than to define a PrecisBackwardCompatible category. This will also simplify implementations. Peter From nobody Wed May 21 18:02:21 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64011A02D7; Wed, 21 May 2014 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN6kNKsPohRv; Wed, 21 May 2014 12:26:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7F71A01A5; Wed, 21 May 2014 12:26:23 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WnC92-000Cap-7N; Wed, 21 May 2014 15:25:44 -0400 Date: Wed, 21 May 2014 15:26:13 -0400 From: John C Klensin To: Peter Saint-Andre , Stephen Farrell , The IESG Message-ID: In-Reply-To: <537C0C61.8090404@stpeter.im> References: <20140424132059.12242.13096.idtracker@ietfa.amsl.com> <5359204A.90100@stpeter.im> <53592266.2060509@cs.tcd.ie> <537C0C61.8090404@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/precis/L7Y0U4je31YFnDnnQimj1oYfM_c X-Mailman-Approved-At: Wed, 21 May 2014 18:02:16 -0700 Cc: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org Subject: Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-framework-16: (with COMMENT) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:26:24 -0000 --On Tuesday, 20 May, 2014 20:16 -0600 Peter Saint-Andre wrote: >... >> If you wanted, s/This category includes/This currently >> empty category will include/ would be clearer for me. >> (Assuming I read it right:-) > > That part is quoted from RFC 5892. However, in the note that > precedes the quoted text, I suggest that we add the following > sentence: > > At the time of this writing (and also at the time that > RFC 5892 was published), this category consisted of the > empty set; however, that is subject to change as described > in RFC 5892. Unless I misunderstand, if the kinds of exceptions that would justify using that category were to arise, we'd need separate review and evaluation systems and approvals for IDNA and PRECIS, even if they were largely performed by the same people. Moreover, if PRECIS stays with the profile model it is using now, we have no basis on which to judge whether this category (exceptions apply to all protocols and profiles) is adequate or whether each new version of Unicode requires per-protocol or per-profile reviews. That is another reason why a system that allows or encourages a growing family of profiles gives me the creeps. Six months ago, it would have been sensible to treat the above comment as largely theoretical: the category was reserved as a placeholder that we never expected to use. At this point, unless an apparent problem that was spotted in Unicode 7.0.0 beta is addressed in a serious way by UTC, the possibility of having to use the category is very real. It is also important to note that the problem was spotted by inspection by a moderately skilled human after it had successfully gotten through the usual testing implementations and preliminary review by the relevant expert. best, john From nobody Wed May 21 19:09:40 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420F51A0045; Wed, 21 May 2014 19:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.553 X-Spam-Level: X-Spam-Status: No, score=-4.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuE6ApHqaio5; Wed, 21 May 2014 19:09:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2C6E1A0043; Wed, 21 May 2014 19:09:34 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9428F4032A; Wed, 21 May 2014 20:09:33 -0600 (MDT) Message-ID: <537D5C5D.2060207@stpeter.im> Date: Wed, 21 May 2014 20:09:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140409190744.15518.7195.idtracker@ietfa.amsl.com> <6C520F47E0BA6CEF00EF649B@JcK-HP8200.jck.com> <537D23C2.10709@stpeter.im> In-Reply-To: <537D23C2.10709@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/TdJdb1xoTmdL_wM7LrSr1Sl5Ysk Cc: The IESG Subject: Re: [precis] Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 02:09:37 -0000 On 5/21/14, 4:08 PM, Peter Saint-Andre wrote: > My previous reply to this message was sent in a hurry right before the > relevant IESG telechat. This reply provides, I hope, a more measured > response. > > On 4/23/14, 10:17 PM, John C Klensin wrote: > >> Recommendation: Hold this document until the various categories >> are exercised by at least a sampling of applicable profiles. > > As mentioned, we have 5 such profiles in somewhat advanced states: > > 1. draft-ietf-xmpp-6122bis (defines two profiles to replace two > stringprep profiles) - completed WGLC in the XMPP WG > > 2. draft-ietf-precis-nickname (defines one profile for use by both MSRP > and XMPP) - completed WGLC in the PRECIS WG > > 3. draft-ietf-precis-saslprepbis (defines one profile for usernames and > one for passwords) - awaiting WGLC but widely discussed in the PRECIS > and KITTEN working groups, IMHO it could undergo WGLC fairly soon > >> Make the problems with excessive profiles explicit; > > Would the following text help? > > ### > > If input strings that appear "the same" to users are programmatically > considered to be distinct in different systems, or if input strings > that appear distinct to users are programmatically considered to be > "the same" in different systems, then users can be confused. Such > confusion can have security implications, such as the false positives > and false negatieves discussed in [RFC6943]. One starting goal of > work on the PRECIS framework was to limit the number of times that > users are confused (consistent with the "principle of least > astonishment"). Unfortunately, this goal has been difficult to > achieve given the large number of application protocols already in > existence, each with its own conventions regarding allowable > characters (see for example [I-D.saintandre-username-interop] with > regard to various username constructs). Despite these difficulties, > profiles should not be multiplied beyond necessity. In particular, > application protocol designers should think long and hard before > defining a new profile instead of using one that has already been > defined, and if they decide to define a new profile then they should > clearly explain their reasons for doing so. > > ### > > Suggestions for improvement are welcome. Right now I'm of the opinion > that such text belongs in the security considerations, but perhaps it > makes sense to place it much farther up in the document, even in the > introduction. > > While thinking about this further in the middle of the night, I began to > wonder if anyone has done usability studies on user astonishment in > relation to internationalized strings. Do you know of any research we > can reference here? > >> impose >> requirements on additional profiles that include an explanation >> of why they are needed given the user-level interoperability and >> astonishment problems that can result from even three of them > > Do you think we need text beyond that quoted above? > >> and require a higher level of review and consensus for creating >> new ones than "expert review". > > In RFC 5226 terms, are you suggesting specification required, RFC > required, or IETF review? I get the sense that you'd prefer the latter. > >> Modify the Security >> Considerations section to identify user astonishment and >> consequent confusion about what rules are being applied in a >> given PRECIS-User protocol as a risk and possible attack vector. > > Again, would the text quoted above suffice or do we need a more detailed > description of the security implications? > > >> [3] Not only should multiple profiles be discouraged for this >> type of case by the Law of Least Astonishment, but general IETF >> experience indicates that profiles are a bad idea and that >> protocols that depend on them (and use a significant variety) >> tend to be less successful than those that do not. > > I continue to have difficulty imagining how we can do without something > like profiles, given the large number of identifiers already in the > field. One possible way to overcome part of that problem would be to > work on something like draft-saintandre-username-interop in the PRECIS > WG and to strongly encourage (force?) applications to use that, at least > for usernamey constructs. In a thread that diverged from this one and went offlist, John brought up a point that I had not understood until just now. In the interest of bringing it to wider attention, with his permission I shall try to summarize John's point here and then reply to it in a more public way. As I understand it, John suggests that the profile mechanism currently specified in the PRECIS framework document is a less than ideal way to handle exceptional characters. For example, consider the characters that are disallowed in the localpart of a Jabber ID in XMPP: U+0022 (QUOTATION MARK), i.e., " U+0026 (AMPERSAND), i.e., & U+0027 (APOSTROPHE), i.e., ' U+002F (SOLIDUS), i.e., / U+003A (COLON), i.e., : U+003C (LESS-THAN SIGN), i.e., < U+003E (GREATER-THAN SIGN), i.e., > U+0040 (COMMERCIAL AT), i.e., @ (See http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.3 for further discussion.) It's merely an historical accident that XMPP disallows these characters, so he wonders why would define an entirely separate profile just to accommodate this usage. Better, he suggests, to do something like define a core subset of characters for usernamey things, then note in passing that some protocols do silly things with some of these characters (this might be similar to what I've started to do in draft-saintandre-username-interop, although there I was trying to find a least common denominator for all the silliness). As I see it, that might enable us to unify the UsernameIdentifierClass from draft-ietf-precis-saslprepbis and the JIDlocalIdentifierClass from draft-ietf-xmpp-6122bis: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.1 http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.3 Passwords, though, would still be a separate construct, using the PasswordFreeformClass from draft-ietf-precis-saslprepbis: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-5.1 I have some sympathy with John's argument. However, it seems to me that exceptional characters are not the only reason we have a multitude of profiles. Consider, for example, the JIDresourceFreeformClass from draft-ietf-xmpp-6122bis and the NicknameFreeformClass from draft-ietf-precis-nickname: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.4 http://tools.ietf.org/html/draft-ietf-precis-nickname-09#section-2 From the XMPP perspective (but not the MSRP perspective), a nickname is simply a reduced subset and different handling (e.g., NFKC instead of NFC) of the resourcepart profile because some further restrictions are appropriate for chatroom nicknames. Mostly we have defined these restrictions to prevent user confusion in chatroom user interfaces - basically, in chatrooms we want to prevent people from mimicking nicknames of other users, so we forbid trailing and leading whitespace as well as multiple spaces in a row inside a nickname, we want to be more aggressive about finding matches so that, for instance, U+2163 ROMAN NUMERAL FOUR would match the combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V), etc. These restrictions are discussed in http://tools.ietf.org/html/draft-ietf-precis-nickname so please see that document for details. Perhaps I'm too close to the matter at this point, but I think there are legitimate reasons for defining at least some of these different profiles. Maybe we could handle the differences between the underlying strings and the contexts in which they're used (e.g., chatrooms) in another way, i.e., by not specifying additional profiles. However, it seems to me that users would still have the experience of similar strings being treated in different ways (e.g., "why can't my chatroom nickname contain multiple internal spaces like my password can?"). To my mind, a nickname is quite a different thing (used in quite a different context) from a password, even though at the PRECIS level they're both based on the FreeformClass. As I see it, John would like us to reduce the complexity of all these different strings and identifiers (including IDNAs) into one or two classes. I'm simply not optimistic that such a monism or dualism will really serve our needs because we already have a plethora of strings out there in the world (usernames, passwords, domain names, file names, chatroom names, etc.). I would indeed like to at least unify username/localpart constructs (thus draft-saintandre-username-interop), but I am not sure if we can progress much farther than that (although it's worth investigating in any case). Peter From nobody Tue May 27 10:22:54 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079E1A04F6; Tue, 27 May 2014 10:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fThu0rZsJk2t; Tue, 27 May 2014 10:22:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A011A0515; Tue, 27 May 2014 10:22:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140527172249.8681.9991.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 10:22:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/J3t4jJ0wQOlCnx-T4UR-g25Z-uI Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-framework-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:22:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-framework-17.txt Pages : 67 Date : 2014-05-27 Abstract: Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-framework-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-17 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 Tue May 27 10:23:00 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFBF1A04F6 for ; Tue, 27 May 2014 10:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WoBQEPAAyXz; Tue, 27 May 2014 10:22:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FBC1A052E; Tue, 27 May 2014 10:22:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140527172249.8681.50589.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 10:22:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/precis/DMflqoyMk4Q01RrXoZkizTH8h10 Subject: [precis] New Version Notification - draft-ietf-precis-framework-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:22:55 -0000 A new version (-17) has been submitted for draft-ietf-precis-framework: http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-17 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. IETF Secretariat. From nobody Tue May 27 10:24:21 2014 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CCD1A01D5 for ; Tue, 27 May 2014 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrNEnQOJ_vQe for ; Tue, 27 May 2014 10:24:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0422C1A04FA for ; Tue, 27 May 2014 10:24:15 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E712A40C58; Tue, 27 May 2014 11:24:11 -0600 (MDT) Message-ID: <5384CA3B.4070907@stpeter.im> Date: Tue, 27 May 2014 11:24:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: precis@ietf.org References: <20140527172249.8681.50589.idtracker@ietfa.amsl.com> In-Reply-To: <20140527172249.8681.50589.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/precis/ub9Wu3AxoUYi9bBuuKdjdMlyDd4 Subject: Re: [precis] New Version Notification - draft-ietf-precis-framework-17.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:24:17 -0000 This version attempts to address IESG review as well as feedback from John Klensin. Peter On 5/27/14, 11:22 AM, internet-drafts@ietf.org wrote: > > A new version (-17) has been submitted for draft-ietf-precis-framework: > http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-17.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-framework-17 > > 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. > > IETF Secretariat. > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis >