From florob@babelmonkeys.de Sat Aug 4 15:51:37 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242321F8723 for ; Sat, 4 Aug 2012 15:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo9paJygTH8h for ; Sat, 4 Aug 2012 15:51:36 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id B10DC21F86EC for ; Sat, 4 Aug 2012 15:51:36 -0700 (PDT) Received: from xdsl-213-196-240-83.netcologne.de ([213.196.240.83] helo=[192.168.0.134]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SxnC2-0006g4-0B for xmpp@ietf.org; Sun, 05 Aug 2012 00:51:34 +0200 Message-ID: <501DA76F.2000109@babelmonkeys.de> Date: Sun, 05 Aug 2012 00:51:27 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: xmpp@ietf.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 22:51:37 -0000 Hello everyone, I reread the 6122bis draft in preparation for the WG meeting this week and based on that have some comment that have not yet been brought up on the list as far as I can remember. =General= For the three parts of a JID we still say «The *part of a JID MUST be treated as follows». I think this sounds somewhat vague (when?, why?, by whom?). We might want to change this text to "For normalization of a *part the following steps MUST be performed" and include a forward reference to Section 3. It would likely also be appropriate for Section 3 to explicitly state that: a) "preparation" refers of this normalization steps b) "enforcing the rules" means normalization, followed by validation =Section 2.2= The current text says «A domainpart consisting of a fully-qualified domain name MUST be an "internationalized domain name" as defined in [RFC5890]». RFC 5890 in turn says «An "internationalized domain name" (IDN) is a domain name that contains at least one A-label or U-label». However, a domainpart can consist solely of NR-LDH labels. Considering the normalizations we enforce I think it would be better for us to instead say that a domainpart «MUST only contain NR-LDH labels, and U-labels». Concerning the normalization steps described in this section I have two concerns. The first thing I noticed was that conversion from A-labels to U-labels is last. However, this could produce Unicode characters from the punycoded version that would have changed under steps 1 to 3. Thinking about this some more I started wondering whether an A-label could actually contain punycoded characters that would change under the first 3 normalization steps. What struck me about this is that we are specifying a normalization of something that already has normalization rules. E.g. IDNA2008 defines a U-label as a «IDNA-valid string of Unicode characters, in Normalization Form C (NFC)», so there is no need to ever perform NFC on it. We also point people to the PRECIS mappings when a mapping document for IDNs already exists. I think it is likely preferable to just defer to IDNA2008 on this and only mandate the conversion of A-labels to U-labels. Thoughts? =Section 3= The list of elements and attributes that a server should consider as JID slots includes items like data form fields, which also exist from client to client. I think it would be appropriate to clarify that normalization/verification of these JIDs is only required when the server is responsible for handling the containing stanza (i.e. is not just acting as a "dumb" router for that stanza). =Section 4= The second paragraph starting «For backward compatibility» might be more appropriate as a Interoperability Note. Regards, Florian Zeitz From stpeter@stpeter.im Wed Aug 8 13:44:44 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B069521F86E4 for ; Wed, 8 Aug 2012 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV6MTFnw5X27 for ; Wed, 8 Aug 2012 13:44:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E398021F86E0 for ; Wed, 8 Aug 2012 13:44:42 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D5904013D; Wed, 8 Aug 2012 14:44:48 -0600 (MDT) Message-ID: <5022CFB4.9060906@stpeter.im> Date: Wed, 08 Aug 2012 14:44:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Florian Zeitz References: <501DA76F.2000109@babelmonkeys.de> In-Reply-To: <501DA76F.2000109@babelmonkeys.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 20:44:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Florian, thanks for the feedback. I also need to update 6122bis to track changes to the PRECIS framework spec, so your comments are timely. Replies inline. On 8/4/12 4:51 PM, Florian Zeitz wrote: > Hello everyone, > > I reread the 6122bis draft in preparation for the WG meeting this > week and based on that have some comment that have not yet been > brought up on the list as far as I can remember. > > =General= For the three parts of a JID we still say «The *part of a > JID MUST be treated as follows». I think this sounds somewhat vague > (when?, why?, by whom?). The "why" probably seems obvious to me, so I haven't provided much justification for doing something other than ASCII addresses. Or do you mean providing justification for each rule? The "when" and "by whom" are covered in Section 3. > We might want to change this text to "For normalization of a *part > the following steps MUST be performed" and include a forward > reference to Section 3. Normalization refers to Unicode normalization, so I think your proposed text would be confusing. We could say something like this: OLD The localpart of a JID MUST be treated as follows, where the operations specified MUST be completed in the order shown: NEW The normalization and mapping rules for the localpart of a JID are as follows, where the operations MUST be completed in the order shown: That seems better to me. > It would likely also be appropriate for Section 3 to explicitly > state that: a) "preparation" refers of this normalization steps b) > "enforcing the rules" means normalization, followed by validation I think that "preparation" means generating JIDs and JID-parts that are in conformance with the rules, whereas "enforcement" means actively checking that JIDs and JID-parts are in conformance and returning an appropriate error if they are not. Thus I propose the following modification. OLD Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with these rules before including them in protocol slots within XMPP streams, XMPP servers MUST enforce the rules wherever possible. NEW Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with the rules before including them in protocol slots within XML streams (such that JIDs and parts of JIDs are in conformance), XMPP servers MUST enforce the rules wherever possible and reject stanzas and other XML elements that violate the rules (for stanzas, by returning a error to the sender as described in Section 8.3.3.8 of [RFC6120]). > =Section 2.2= The current text says «A domainpart consisting of a > fully-qualified domain name MUST be an "internationalized domain > name" as defined in [RFC5890]». RFC 5890 in turn says «An > "internationalized domain name" (IDN) is a domain name that > contains at least one A-label or U-label». However, a domainpart > can consist solely of NR-LDH labels. Considering the normalizations > we enforce I think it would be better for us to instead say that a > domainpart «MUST only contain NR-LDH labels, and U-labels». That is indeed more accurate. Thanks for the suggested text. OLD A domainpart consisting of a fully-qualified domain name MUST be an "internationalized domain name" as defined in [RFC5890] and MUST consist only of Unicode code points that conform to the rules specified in [RFC5892]. NEW A domainpart consisting of a fully-qualified domain name MUST contain only NR-LDH labels and U-labels as defined in [RFC5890] and MUST consist only of Unicode code points that conform to the rules specified in [RFC5892]. > Concerning the normalization steps described in this section I have > two concerns. > > The first thing I noticed was that conversion from A-labels to > U-labels is last. However, this could produce Unicode characters > from the punycoded version that would have changed under steps 1 to > 3. > > Thinking about this some more I started wondering whether an > A-label could actually contain punycoded characters that would > change under the first 3 normalization steps. What struck me about > this is that we are specifying a normalization of something that > already has normalization rules. E.g. IDNA2008 defines a U-label as > a «IDNA-valid string of Unicode characters, in Normalization Form C > (NFC)», so there is no need to ever perform NFC on it. Right, by specifying things in that way, IDNA2008 assumes that normalization occurs first. > We also point people to the PRECIS mappings when a mapping document > for IDNs already exists. I think it is likely preferable to just > defer to IDNA2008 on this and only mandate the conversion of > A-labels to U-labels. Thoughts? You raise a very good point. I think we're all in agreement that we want to say as little as possible here above what's in the IDNA2008 specifications. Currently we say: ### The domainpart of a JID MUST be treated as follows, where the operations specified MUST be completed in the order shown: 1. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. 2. Additional mappings MAY be applied, such as those defined in [MAPPINGS]. 3. All characters MUST be mapped using Unicode Normalization Form C (NFC). 4. Each A-label MUST be converted to a U-label. With regard to directionality, applications MUST apply the "Bidi Rule" defined in [RFC5893] (i.e., each of the six conditions of the Bidi Rule must be satisfied). ### Let's take these one at a time. 1. Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. IDNA2008 does not specify casemapping, so EXAMPLE.org is the same as example.org. That's because the DNS has this (to me, strange) property of preserving case on output but ignoring it during comparison. It seems to me that we have two options here: (a) Preserve case in domainparts but ignore it during comparison. (b) Map uppercase and title case code points to their lowercase equivalents. I realize that (a) follows DNS, but (b) seems safer to me since in XMPP we do that mapping for localparts (whereas for resourceparts we preserve case but don't ignore it during comparison). 2. Additional mappings MAY be applied, such as those defined in [MAPPINGS]. The topic of "additional mappings" is opened by RFC 5895. However, I think it would be better to point to draft-yoneya-precis-mappings (and its WG version once published) because it is more specific. However, such additional mappings would be purely optional in any case. 3. All characters MUST be mapped using Unicode Normalization Form C (NFC). The normalization rule (NFC) is covered by IDNA2008, so we don't need to include it here. 4. Each A-label MUST be converted to a U-label. This is something we want (so that we're not dealing with Punycode). With regard to directionality, applications MUST apply the "Bidi Rule" defined in [RFC5893] (i.e., each of the six conditions of the Bidi Rule must be satisfied). The directionality rule (BiDi) is covered by IDNA2008, so we don't need to include it here. As a result of the foregoing analysis, I suggest the following text: ### In general, the content of a domainpart is an Internationalized Domain Name ("IDN") as described in the specifications for Internationalized Domain Names in Applications (commonly called "IDNA2008") [RFC5890], and a domainpart is an "IDNA-aware domain name slot". The following rules apply to a domainpart that consists of a fully-qualified domain name: o The domainpart MUST contain only NR-LDH labels and U-labels as defined in [RFC5890] and MUST consist only of Unicode code points that conform to the rules specified in [RFC5892]. o The domainpart MUST NOT include A-labels as defined in [RFC5890]; each A-label MUST be converted to a U-label during preparation of a domainpart and comparison MUST be performed using U-labels, not A-labels. o After conversion of A-labels to U-labels if necessary, all uppercase and titlecase code points within the domainpart MUST be mapped to their lowercase equivalents. o After (and in addition to) casemapping, other mappings MAY be applied to the domainpart, such as those defined in [MAPPINGS] or [RFC5895]. After any and all conversion, normalization, and mapping of code points, a domainpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. (Naturally, the length limits of [RFC1034] apply, and nothing in this document is to be interpreted as overriding those more fundamental limits.) ### > =Section 3= The list of elements and attributes that a server > should consider as JID slots includes items like data form fields, > which also exist from client to client. I think it would be > appropriate to clarify that normalization/verification of these > JIDs is only required when the server is responsible for handling > the containing stanza (i.e. is not just acting as a "dumb" router > for that stanza). Section 3 already says: In general, servers are responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to process or act on such elements .... However, servers are not responsible for enforcing the rules when the protocol elements are intended for communication among other entities .... .... in such cases, clients SHOULD enforce the rules, and client implementers need to understand that not enforcing the rules can lead to a degraded user experience or security vulnerabilities. Do you think that we need to make clear in each instance whether a given element or attribute can appear in both situations (handled by the server or routed to another entity)? Note also the following statement in RFC 6120: "Each server implementation will contain its own logic for processing stanzas it receives. Such logic determines whether the server needs to route a given stanza to another domain, deliver it to a local entity (typically a connected client associated with a local account), or handle it directly within the server itself." Thus I suggest... OLD In general, servers are responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to process or act on such elements; two examples from [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot used by XMPP servers for routing of outbound stanzas) and the child of the element (which is a resourcepart slot used by XMPP servers for binding of a resource to an account for routing of stanzas between the server and a particular client). However, servers are not responsible for enforcing the rules when the protocol elements are intended for communication among other entities; two examples are the 'initiator' attribute in the Jingle extension [XEP-0166] (which is a JID slot used for client-to-client coordination of multimedia sessions) and the 'nick' attribute in the Multi-User Chat extension [XEP-0045] (which is a resourcepart slot used for administrative purposes in the context of XMPP chatrooms); in such cases, clients SHOULD enforce the rules, and client implementers need to understand that not enforcing the rules can lead to a degraded user experience or security vulnerabilities. NEW In general, a server is responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to handle such elements directly or to use them for purposes of routing a stanza to another domain or delivering a stanza to a local entity; two examples from [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot used by XMPP servers for routing of outbound stanzas) and the child of the element (which is a resourcepart slot used by XMPP servers for binding of a resource to an account for routing of stanzas between the server and a particular client). However, a server is not responsible for enforcing the rules when the protocol elements are intended for communication among other entities, typically within the payload of a stanza that the server is merely routing to another domain or delivering to a local entity; two examples are the 'initiator' attribute in the Jingle extension [XEP-0166] (which is a JID slot used for client-to-client coordination of multimedia sessions) and the 'nick' attribute in the Multi-User Chat extension [XEP-0045] (which is a resourcepart slot used for administrative purposes in the context of XMPP chatrooms); in such cases, clients SHOULD enforce the rules themselves and not depend on the server to do so, and client implementers need to understand that not enforcing the rules can lead to a degraded user experience or security vulnerabilities. > =Section 4= The second paragraph starting «For backward > compatibility» might be more appropriate as a Interoperability > Note. Agreed. I will immediately submit -03 of draft-ietf-xmpp-6122bis so the changes are easier to track. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAiz7QACgkQNL8k5A2w/vxbNgCgvRdrh3sFdqggN3LHNctVlL4U xmgAn1l/0LPrXaiBD+1RZPBgB88ZlcZj =lzVi -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Aug 8 13:54:31 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5F21F8648; Wed, 8 Aug 2012 13:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f02+QOkfwIXo; Wed, 8 Aug 2012 13:54:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816DB21F861D; Wed, 8 Aug 2012 13:54:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808205430.2268.65410.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 13:54:30 -0700 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 20:54:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Extensible Messaging and Presence Protoco= l Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Addre= ss Format Author(s) : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-03.txt Pages : 20 Date : 2012-08-08 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the US-ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-6122bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From florob@babelmonkeys.de Wed Aug 8 19:38:54 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB59A11E80A5 for ; Wed, 8 Aug 2012 19:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33CZ2+PrDRLE for ; Wed, 8 Aug 2012 19:38:51 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id D8D2A21F84FB for ; Wed, 8 Aug 2012 19:38:50 -0700 (PDT) Received: from xdsl-78-34-98-189.netcologne.de ([78.34.98.189] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SzIe7-0005pl-V7; Thu, 09 Aug 2012 04:38:48 +0200 Message-ID: <502322B1.6030609@babelmonkeys.de> Date: Thu, 09 Aug 2012 04:38:41 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> In-Reply-To: <5022CFB4.9060906@stpeter.im> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:38:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 08.08.2012 22:44, schrieb Peter Saint-Andre: > Hi Florian, thanks for the feedback. I also need to update 6122bis > to track changes to the PRECIS framework spec, so your comments are > timely. Replies inline. > > On 8/4/12 4:51 PM, Florian Zeitz wrote: >> Hello everyone, > >> I reread the 6122bis draft in preparation for the WG meeting this >> week and based on that have some comment that have not yet been >> brought up on the list as far as I can remember. > >> =General= For the three parts of a JID we still say «The *part >> of a JID MUST be treated as follows». I think this sounds >> somewhat vague (when?, why?, by whom?). > > The "why" probably seems obvious to me, so I haven't provided much > justification for doing something other than ASCII addresses. Or > do you mean providing justification for each rule? > > The "when" and "by whom" are covered in Section 3. > Agreed, my point was basically that a forward reference to Section 3 would be good here, to improve readability. >> We might want to change this text to "For normalization of a >> *part the following steps MUST be performed" and include a >> forward reference to Section 3. > > Normalization refers to Unicode normalization, so I think your > proposed text would be confusing. > Right, the intention here was to avoid the overly general "treated". > We could say something like this: > > OLD The localpart of a JID MUST be treated as follows, where the > operations specified MUST be completed in the order shown: > > NEW The normalization and mapping rules for the localpart of a JID > are as follows, where the operations MUST be completed in the > order shown: > > That seems better to me. > That seems fine to me. >> It would likely also be appropriate for Section 3 to explicitly >> state that: a) "preparation" refers of this normalization steps >> b) "enforcing the rules" means normalization, followed by >> validation > > I think that "preparation" means generating JIDs and JID-parts that > are in conformance with the rules, whereas "enforcement" means > actively checking that JIDs and JID-parts are in conformance and > returning an appropriate error if they are not. > I tend to disagree. I might of course be mistaken, but my current understanding is that even after performing all "normalization and mapping" steps we might still end up with something that is not NAME_PVAL. So we can act according to the rules for preparation, but still end up with something that does not conform the rules for a localpart. (I.e. what are "the rules" exactly) Also, as long as clients are not required to perform preparation, a server must IMHO always do a combination of preparation and enforcement. I think returning to someone who sent U+006F LATIN SMALL LETTER O + U+0308 COMBINING DIAERESIS instead of U+00F6 LATIN SMALL LETTER O WITH DIAERESIS is something we want to avoid by all means. It might be worthwhile to make that abundantly clear. >> =Section 2.2= The current text says «A domainpart consisting of a >> fully-qualified domain name MUST be an "internationalized domain >> name" as defined in [RFC5890]». RFC 5890 in turn says «An >> "internationalized domain name" (IDN) is a domain name that >> contains at least one A-label or U-label». However, a domainpart >> can consist solely of NR-LDH labels. Considering the >> normalizations we enforce I think it would be better for us to >> instead say that a domainpart «MUST only contain NR-LDH labels, >> and U-labels». > > That is indeed more accurate. Thanks for the suggested text. > > OLD A domainpart consisting of a fully-qualified domain name MUST > be an "internationalized domain name" as defined in [RFC5890] and > MUST consist only of Unicode code points that conform to the rules > specified in [RFC5892]. > > NEW A domainpart consisting of a fully-qualified domain name MUST > contain only NR-LDH labels and U-labels as defined in [RFC5890] > and MUST consist only of Unicode code points that conform to the > rules specified in [RFC5892]. > Looks good. >> Concerning the normalization steps described in this section I >> have two concerns. > > [...] Let's take these one at a time. > > 1. Uppercase and titlecase characters MUST be mapped to their > lowercase equivalents. > > IDNA2008 does not specify casemapping, so EXAMPLE.org is the same > as example.org. That's because the DNS has this (to me, strange) > property of preserving case on output but ignoring it during > comparison. It seems to me that we have two options here: > > (a) Preserve case in domainparts but ignore it during comparison. > > (b) Map uppercase and title case code points to their lowercase > equivalents. > > I realize that (a) follows DNS, but (b) seems safer to me since in > XMPP we do that mapping for localparts (whereas for resourceparts > we preserve case but don't ignore it during comparison). > That might be me misunderstanding IDNA2008/DNS, but: What ends up in DNS are always only A-labels and NR-LDH labels. DNS is not aware of Unicode characters as such, everything in there is ASCII. RFC 5895 talks specifically about mapping uppercase characters to their lowercase equivalent in Section 2. My understanding is that uppercase letters (which can be mapped to lowercase) are not PVALID in IDNA2008 U-labels, which is archived by exclusion of the Unstable (B) category. As such I don't think we need to care about this one. (Disclaimer: This is from my somewhat limited understanding of IDNA2008, I'll gladly bow to anyone with a better understanding) > 2. Additional mappings MAY be applied, such as those defined in > [MAPPINGS]. > > The topic of "additional mappings" is opened by RFC 5895. However, > I think it would be better to point to > draft-yoneya-precis-mappings (and its WG version once published) > because it is more specific. However, such additional mappings > would be purely optional in any case. > I couldn't find anything about additional mappings in RFC 5895, could you point me to some specific text? The reason I'm very uncomfortable with even making this OPTIONAL is the following: We do DNS lookup based on the domainpart. That means we prepare it according to these rules, perform punycode it, prepend "_xmpp-server._tcp." and do a SRV lookup based on that. If we map certain characters (other than what is specified for IDNA2008) to other ones, or nothing, what we look up in DNS changes. I don't think that is the case for anything currently in draft-yoneya-precis-mappings, but I think it is dangerous terrain to tread on. > 3. All characters MUST be mapped using Unicode Normalization Form > C (NFC). > > The normalization rule (NFC) is covered by IDNA2008, so we don't > need to include it here. > > 4. Each A-label MUST be converted to a U-label. > > This is something we want (so that we're not dealing with > Punycode). > > With regard to directionality, applications MUST apply the "Bidi > Rule" defined in [RFC5893] (i.e., each of the six conditions of the > Bidi Rule must be satisfied). > > The directionality rule (BiDi) is covered by IDNA2008, so we don't > need to include it here. > I agree with all of these. >> =Section 3= The list of elements and attributes that a server >> should consider as JID slots includes items like data form >> fields, which also exist from client to client. I think it would >> be appropriate to clarify that normalization/verification of >> these JIDs is only required when the server is responsible for >> handling the containing stanza (i.e. is not just acting as a >> "dumb" router for that stanza). > > Section 3 already says: > > In general, servers are responsible for enforcing the address > format rules when receiving protocol elements from clients where > the server is expected to process or act on such elements .... > > However, servers are not responsible for enforcing the rules when > the protocol elements are intended for communication among other > entities .... .... in such cases, clients SHOULD enforce the > rules, and client implementers need to understand that not > enforcing the rules can lead to a degraded user experience or > security vulnerabilities. > > Do you think that we need to make clear in each instance whether a > given element or attribute can appear in both situations (handled > by the server or routed to another entity)? > I had seen this text, I just feel that it addresses a marginally different issue. The misunderstanding I foresee (partially due to the Jingle example) is that there are protocols that servers don't ever care about (e.g. Jingle) and some that they need to parse anyway (e.g. dataforms for ad-hoc commands directed at the server). Thus, someone could conclude that dataforms always need to be checked, because servers needs to "handle *such* elements", even though it will never handle this specific element. I don't think we need to say which slots can occur in what contexts. However, I do think we might be better off if we add some text that makes it very clear that whether validation needs to be performed is dependent on the context and not the type of slot. Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQIyKxAAoJELv//CFWsbyxhrsQANNm8CWTBIi9h7A0RRoUjCZU 4DOMnrikrYexUe1ekcFFkv3Ze8SLRzWtSTvTgdnxkW5zUsttlylIUaHiOogbpz2i v7LB/zP0jcCFsZB6+Y11iBCDgQRtpo+qMyXp7/8N1DBzxWyBEKZH+u3pmuUR0gpG 2g8522zA58DSSgvCyvl+lCsZhN0p0wU9g+wcrvVGJsvWMLpMN6QmlGOP3bQdv7Ql Y/wfvmFIHVeM//68DaXMC+d8GQ0uKQFTUlNQeDgnj1OH4qW+LtdY6mOXhQPXIPtS waSw37irU19BD+f9DSCeB+kNpKqqyuMK0EuJEZSFpRoSxSd8i2maPTglGFdiuAjt 9dwqlZ0WNfFO/m9Wibz5hzxnDZIB+kwz9bkV95Ampkk6Mi+aL5TIOiRZ78y1TLCP GDinvFCpljt72hRbvUX18ImmLLz3r4E+bJEsk/0MtsedJAxCuHF5Duzc9+gjrxRo ORGFewxfNFnga55331CYm0ri0n66Av/P+LNAqPrzwVG5+5LMJKMlEzHuDwvM8g6o 0a259aWesHZy1HZv2LFRlS/mrWz4h9UYez7kLELIKdStVaeIhWmsHrl9+JQl+pBG uOAhfreI9+sHjaoLphMprCiS7915kaNWizu8F5wf5df/6xQRnawObWEbgwWdtO1c 7w+TL7in27stnKjDPVdV =Z9k+ -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Aug 9 08:42:03 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7421F87AE for ; Thu, 9 Aug 2012 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.707 X-Spam-Level: X-Spam-Status: No, score=-103.707 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1VqURpIC9H2 for ; Thu, 9 Aug 2012 08:42:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 605AB21F87A3 for ; Thu, 9 Aug 2012 08:42:01 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42FD1404EA; Thu, 9 Aug 2012 09:42:09 -0600 (MDT) Message-ID: <5023DA48.3080707@stpeter.im> Date: Thu, 09 Aug 2012 09:42:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Florian Zeitz References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> In-Reply-To: <502322B1.6030609@babelmonkeys.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:42:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline, areas of agreement snipped... On 8/8/12 8:38 PM, Florian Zeitz wrote: > Am 08.08.2012 22:44, schrieb Peter Saint-Andre: > >> On 8/4/12 4:51 PM, Florian Zeitz wrote: >>> It would likely also be appropriate for Section 3 to explicitly >>> state that: a) "preparation" refers of this normalization >>> steps b) "enforcing the rules" means normalization, followed by >>> validation > >> I think that "preparation" means generating JIDs and JID-parts >> that are in conformance with the rules, whereas "enforcement" >> means actively checking that JIDs and JID-parts are in >> conformance and returning an appropriate error if they are not. > > I tend to disagree. I might of course be mistaken, but my current > understanding is that even after performing all "normalization and > mapping" steps we might still end up with something that is not > NAME_PVAL. So we can act according to the rules for preparation, > but still end up with something that does not conform the rules for > a localpart. (I.e. what are "the rules" exactly) If a client receives an input string, prepares it according to the rules, and the output doesn't conform to the rules (e.g., a localpart contains a code point not allowed by NAME_PVAL), then IMHO it needs to bounce it back to the user (if any) for correction. However, I see your point that such behavior is, de facto, enforcement. :) > Also, as long as clients are not required to perform preparation, > a server must IMHO always do a combination of preparation and > enforcement. I think returning to someone who > sent U+006F LATIN SMALL LETTER O + U+0308 COMBINING DIAERESIS > instead of U+00F6 LATIN SMALL LETTER O WITH DIAERESIS is something > we want to avoid by all means. It might be worthwhile to make that > abundantly clear. Yes, precisely so. I'll try to work on proposed text. >>> Concerning the normalization steps described in this section I >>> have two concerns. > >> [...] Let's take these one at a time. > >> 1. Uppercase and titlecase characters MUST be mapped to their >> lowercase equivalents. > >> IDNA2008 does not specify casemapping, so EXAMPLE.org is the same >> as example.org. That's because the DNS has this (to me, strange) >> property of preserving case on output but ignoring it during >> comparison. It seems to me that we have two options here: > >> (a) Preserve case in domainparts but ignore it during >> comparison. > >> (b) Map uppercase and title case code points to their lowercase >> equivalents. > >> I realize that (a) follows DNS, but (b) seems safer to me since >> in XMPP we do that mapping for localparts (whereas for >> resourceparts we preserve case but don't ignore it during >> comparison). > > That might be me misunderstanding IDNA2008/DNS, but: What ends up > in DNS are always only A-labels and NR-LDH labels. DNS is not aware > of Unicode characters as such, everything in there is ASCII. Correct. > RFC 5895 talks specifically about mapping uppercase characters to > their lowercase equivalent in Section 2. My understanding is that > uppercase letters (which can be mapped to lowercase) are not PVALID > in IDNA2008 U-labels, which is archived by exclusion of the > Unstable (B) category. Yes, that is the IDNA2008 workaround. Personally I find that a bit of an odd way to solve the problem, but that's what the IDNA2008 design team chose. > As such I don't think we need to care about this one. (Disclaimer: > This is from my somewhat limited understanding of IDNA2008, I'll > gladly bow to anyone with a better understanding) > >> 2. Additional mappings MAY be applied, such as those defined in >> [MAPPINGS]. > >> The topic of "additional mappings" is opened by RFC 5895. >> However, I think it would be better to point to >> draft-yoneya-precis-mappings (and its WG version once published) >> because it is more specific. However, such additional mappings >> would be purely optional in any case. > > I couldn't find anything about additional mappings in RFC 5895, > could you point me to some specific text? Section 2 of RFC 5895 talks about mapping uppercase characters (but not titlecase characters(?)) to lowercase, mapping fullwidth and halfwidth characters to their decomposition mappings, etc. Strangely, RFC 5895 notes that the steps are ordered and application of NFC is not the first step. This seems to be inconsistent with the advice in the other IDNA2008 RFCs. I'll need to investigate further and think about it some more. > The reason I'm very uncomfortable with even making this OPTIONAL > is the following: We do DNS lookup based on the domainpart. That > means we prepare it according to these rules, perform punycode it, > prepend "_xmpp-server._tcp." and do a SRV lookup based on that. If > we map certain characters (other than what is specified for > IDNA2008) to other ones, or nothing, what we look up in DNS > changes. I don't think that is the case for anything currently in > draft-yoneya-precis-mappings, but I think it is dangerous terrain > to tread on. So, let's get down to cases (see draft-yoneya-precis-mappings, Section 4). Are you worried about mapping of uppercase and titlecase characters to lowercase? It certainly seems that *not* mapping Example.Com to example.com would violate the principle of least user surprise. The fullwidth and halfwidth characters are less familiar to most people on this list, but they are common in certain East Asian scripts. Mapping them to their decomposition mappings would, I think, make sense to most users of those scripts. For domainparts, mapping of whitespace characters to SP (U+0020) does not apply. The local case mappings in Section 4.3 of draft-yoneya-precis-mappings essentially capture the exceptions from the SpecialCasing.txt file in the Unicode character database. Applying those rules also makes sense to me (e.g., to handle "dotless i" in certain Turkic locales). >> 3. All characters MUST be mapped using Unicode Normalization >> Form C (NFC). > >> The normalization rule (NFC) is covered by IDNA2008, so we don't >> need to include it here. > >> 4. Each A-label MUST be converted to a U-label. > >> This is something we want (so that we're not dealing with >> Punycode). > >> With regard to directionality, applications MUST apply the "Bidi >> Rule" defined in [RFC5893] (i.e., each of the six conditions of >> the Bidi Rule must be satisfied). > >> The directionality rule (BiDi) is covered by IDNA2008, so we >> don't need to include it here. > > I agree with all of these. > >>> =Section 3= The list of elements and attributes that a server >>> should consider as JID slots includes items like data form >>> fields, which also exist from client to client. I think it >>> would be appropriate to clarify that normalization/verification >>> of these JIDs is only required when the server is responsible >>> for handling the containing stanza (i.e. is not just acting as >>> a "dumb" router for that stanza). > >> Section 3 already says: > >> In general, servers are responsible for enforcing the address >> format rules when receiving protocol elements from clients where >> the server is expected to process or act on such elements .... > >> However, servers are not responsible for enforcing the rules when >> the protocol elements are intended for communication among other >> entities .... .... in such cases, clients SHOULD enforce the >> rules, and client implementers need to understand that not >> enforcing the rules can lead to a degraded user experience or >> security vulnerabilities. > >> Do you think that we need to make clear in each instance whether >> a given element or attribute can appear in both situations >> (handled by the server or routed to another entity)? > > I had seen this text, I just feel that it addresses a marginally > different issue. The misunderstanding I foresee (partially due to > the Jingle example) is that there are protocols that servers don't > ever care about (e.g. Jingle) and some that they need to parse > anyway (e.g. dataforms for ad-hoc commands directed at the server). > Thus, someone could conclude that dataforms always need to be > checked, because servers needs to "handle *such* elements", even > though it will never handle this specific element. BTW, see 6122bis-03 -- it now reads: o The element for Data Forms [XEP-0004] communicated to the server, when the 'type' attribute is "jid-single" or "jid-multi". I could add further clarification, such as: o The element for Data Forms [XEP-0004] communicated to the server itself (e.g., as in [XEP-0133]), when the 'type' attribute is "jid-single" or "jid-multi". > I don't think we need to say which slots can occur in what > contexts. However, I do think we might be better off if we add some > text that makes it very clear that whether validation needs to be > performed is dependent on the context and not the type of slot. I might be missing something, but I'm not completely clear on what you mean by the constrast between context and type of slot. In any case, do you find the text in -03 to be a bit clearer? Can you make suggested improvements to that text? I'll look at it again, as well. Thanks again for your close review of this document! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAj2kgACgkQNL8k5A2w/vy7tQCfR82HetL6VqAu7NCA3D/Lyu6U Y10An1RzKSFdPqSBOMoLRJ1IR5hOu+QB =n4Ch -----END PGP SIGNATURE----- From florob@babelmonkeys.de Thu Aug 9 13:06:42 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BB621F8733 for ; Thu, 9 Aug 2012 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj4otiN2ShSO for ; Thu, 9 Aug 2012 13:06:41 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC3721F869D for ; Thu, 9 Aug 2012 13:06:41 -0700 (PDT) Received: from [2001:4dd0:ff04:0:2501:d17:6ad8:1b8e] by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SzZ0B-0005Pl-MB; Thu, 09 Aug 2012 22:06:39 +0200 Message-ID: <5024184E.6010206@babelmonkeys.de> Date: Thu, 09 Aug 2012 22:06:38 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> <5023DA48.3080707@stpeter.im> In-Reply-To: <5023DA48.3080707@stpeter.im> X-Enigmail-Version: 1.4.3 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:06:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 09.08.2012 17:42, schrieb Peter Saint-Andre: > Comments inline, areas of agreement snipped... > Same :) > On 8/8/12 8:38 PM, Florian Zeitz wrote: >> Am 08.08.2012 22:44, schrieb Peter Saint-Andre: > >>> On 8/4/12 4:51 PM, Florian Zeitz wrote: > >>>> Concerning the normalization steps described in this section >>>> I have two concerns. > >>> [...] Let's take these one at a time. > >>> 1. Uppercase and titlecase characters MUST be mapped to their >>> lowercase equivalents. > [...] >> RFC 5895 talks specifically about mapping uppercase characters to >> their lowercase equivalent in Section 2. My understanding is >> that uppercase letters (which can be mapped to lowercase) are not >> PVALID in IDNA2008 U-labels, which is archived by exclusion of >> the Unstable (B) category. > > Yes, that is the IDNA2008 workaround. Personally I find that a bit > of an odd way to solve the problem, but that's what the IDNA2008 > design team chose. > >> As such I don't think we need to care about this one. >> (Disclaimer: This is from my somewhat limited understanding of >> IDNA2008, I'll gladly bow to anyone with a better understanding) > >>> 2. Additional mappings MAY be applied, such as those defined >>> in [MAPPINGS]. > >>> The topic of "additional mappings" is opened by RFC 5895. >>> However, I think it would be better to point to >>> draft-yoneya-precis-mappings (and its WG version once >>> published) because it is more specific. However, such >>> additional mappings would be purely optional in any case. > >> I couldn't find anything about additional mappings in RFC 5895, >> could you point me to some specific text? > > Section 2 of RFC 5895 talks about mapping uppercase characters > (but not titlecase characters(?)) to lowercase, mapping fullwidth > and halfwidth characters to their decomposition mappings, etc. > Strangely, RFC 5895 notes that the steps are ordered and > application of NFC is not the first step. This seems to be > inconsistent with the advice in the other IDNA2008 RFCs. I'll need > to investigate further and think about it some more. > I think the fact that titlecase characters are not mentioned is just an oversight. The mapping process further described a bit down would also catch titlecase characters. Also note that while IDNA2008 mandates normalization before validation what we have here is mapping before normalization. That is appropriate since mappings could cause the string to no longer be in NFC. >> The reason I'm very uncomfortable with even making this OPTIONAL >> is the following: We do DNS lookup based on the domainpart. That >> means we prepare it according to these rules, perform punycode >> it, prepend "_xmpp-server._tcp." and do a SRV lookup based on >> that. If we map certain characters (other than what is specified >> for IDNA2008) to other ones, or nothing, what we look up in DNS >> changes. I don't think that is the case for anything currently in >> draft-yoneya-precis-mappings, but I think it is dangerous >> terrain to tread on. > > So, let's get down to cases (see draft-yoneya-precis-mappings, > Section 4). > > Are you worried about mapping of uppercase and titlecase characters > to lowercase? It certainly seems that *not* mapping Example.Com to > example.com would violate the principle of least user surprise. > > The fullwidth and halfwidth characters are less familiar to most > people on this list, but they are common in certain East Asian > scripts. Mapping them to their decomposition mappings would, I > think, make sense to most users of those scripts. > > For domainparts, mapping of whitespace characters to SP (U+0020) > does not apply. > > The local case mappings in Section 4.3 of > draft-yoneya-precis-mappings essentially capture the exceptions > from the SpecialCasing.txt file in the Unicode character database. > Applying those rules also makes sense to me (e.g., to handle > "dotless i" in certain Turkic locales). > As I said it does not seem that draft-yoneya-precis-mappings in it's current state would cause any problem. In fact all mappings you listed above are already specified by RFC 5895 (including the ones from SpecialCasing.txt as part of the case folding). So this is at best redundant. My worry however is that we say you MAY perform any mappings. I'm not sure what the motivation for that is. If any mappings that are not in line with what IDNA2008 specifies are performed DNS lookup *will* fail. Either that or I'm completely missing something. > [...] > > BTW, see 6122bis-03 -- it now reads: > > o The element for Data Forms [XEP-0004] communicated to > the server, when the 'type' attribute is "jid-single" or > "jid-multi". > > I could add further clarification, such as: > > o The element for Data Forms [XEP-0004] communicated to > the server itself (e.g., as in [XEP-0133]), when the 'type' > attribute is "jid-single" or "jid-multi". > That is better, but we'd need that all over the place. E.g. also for disco. I'd think a general statement up front would be better, see below. >> I don't think we need to say which slots can occur in what >> contexts. However, I do think we might be better off if we add >> some text that makes it very clear that whether validation needs >> to be performed is dependent on the context and not the type of >> slot. > > I might be missing something, but I'm not completely clear on what > you mean by the constrast between context and type of slot. > Okay, I had feared that this might be unclear, so let me try to rephrase that as proposed text: "Note that while a server might be capable of detecting a certain element or attribute is a JID slot, enforcing the rules on the contained JID is only REQUIRED if the server needs to perform further operations based on the value of the JID". It may however be possible to integrate the same information within the existing text. > In any case, do you find the text in -03 to be a bit clearer? Can > you make suggested improvements to that text? I'll look at it > again, as well. > Yes, I do find the text in -03 is definitely an improvement. Thank you for working on this. - -- Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQJBhOAAoJELv//CFWsbyxUDgP/jeQbobX++VqX3rznnAk7hl1 to0v+Nr9s5k2GvJriNef2H4neSGr3BUZg6Nut4fGuDOE57RZ/mAI0co2cIXBnxgh Qbx0O1CTPf47NqXYsoaL1o/eJIPNCfHXSj1KJsJcPVciogGARDQO1PL/MQXcvXfw 0rhHIrSSoh/a/6WU/NvE4IrkwMJtlJRaxSog5KeihnUGrv5MXD3jkRVV7ENUdSjm OWSSucKTXNrJg7MyY8WoTx4EygCq/t9lLlE0gU9RgxfNQIyLx1h/7pzgJ7562Roo 5NIE9yQoMCMR4NhCL2OQOYLfyEZP3DnDIWjE7PtT5wQp8gUtkssv7NqsnSbpYEUy fi51q5RVL7iuxR7w/hBuYhWK3DUhj91wYAdwYIM2hClfvgT8XlAe5uDgbJxDl2+N V0HDxfWE58Q6ndClkMNdU2KqQBu6jAp+RbyH674U0/25/jWlK12XFxGB2qo8pisQ RRySDau0yUPROZ3NuKlWHz91OMRIRsPA/IMLAYit8Pug1L0oqBBEy1LwaCQZWzwe WpCYIjwad/AjjqjsCp0pkaSI0kf6B2gEE8wKJXevkmQHnj9DFvfWPvxUL0XuGT0i vTJnAUUWKyTuoOQ5JUQtKVJDTyMBDSP3Qy8PguUUBOFChU9MD8xZvFMQF8sQKcsW +aHMw2E0gCeTlOfPgCov =F2ag -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Aug 9 15:24:23 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437ED21F8700 for ; Thu, 9 Aug 2012 15:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.743 X-Spam-Level: X-Spam-Status: No, score=-103.743 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqJ8P91dKh7E for ; Thu, 9 Aug 2012 15:24:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3505321F86D3 for ; Thu, 9 Aug 2012 15:24:22 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5328D404EA; Thu, 9 Aug 2012 16:24:31 -0600 (MDT) Message-ID: <50243892.9020404@stpeter.im> Date: Thu, 09 Aug 2012 16:24:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Florian Zeitz References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> <5023DA48.3080707@stpeter.im> <5024184E.6010206@babelmonkeys.de> In-Reply-To: <5024184E.6010206@babelmonkeys.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:24:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/9/12 2:06 PM, Florian Zeitz wrote: > Am 09.08.2012 17:42, schrieb Peter Saint-Andre: >> Comments inline, areas of agreement snipped... > > Same :) Ditto. :) >> On 8/8/12 8:38 PM, Florian Zeitz wrote: >>> Am 08.08.2012 22:44, schrieb Peter Saint-Andre: > >>>> On 8/4/12 4:51 PM, Florian Zeitz wrote: > >>>>> Concerning the normalization steps described in this >>>>> section I have two concerns. > >>>> [...] Let's take these one at a time. > >>>> 1. Uppercase and titlecase characters MUST be mapped to >>>> their lowercase equivalents. >> [...] >>> RFC 5895 talks specifically about mapping uppercase characters >>> to their lowercase equivalent in Section 2. My understanding >>> is that uppercase letters (which can be mapped to lowercase) >>> are not PVALID in IDNA2008 U-labels, which is archived by >>> exclusion of the Unstable (B) category. > >> Yes, that is the IDNA2008 workaround. Personally I find that a >> bit of an odd way to solve the problem, but that's what the >> IDNA2008 design team chose. > >>> As such I don't think we need to care about this one. >>> (Disclaimer: This is from my somewhat limited understanding of >>> IDNA2008, I'll gladly bow to anyone with a better >>> understanding) > >>>> 2. Additional mappings MAY be applied, such as those >>>> defined in [MAPPINGS]. > >>>> The topic of "additional mappings" is opened by RFC 5895. >>>> However, I think it would be better to point to >>>> draft-yoneya-precis-mappings (and its WG version once >>>> published) because it is more specific. However, such >>>> additional mappings would be purely optional in any case. > >>> I couldn't find anything about additional mappings in RFC 5895, >>> could you point me to some specific text? > >> Section 2 of RFC 5895 talks about mapping uppercase characters >> (but not titlecase characters(?)) to lowercase, mapping >> fullwidth and halfwidth characters to their decomposition >> mappings, etc. Strangely, RFC 5895 notes that the steps are >> ordered and application of NFC is not the first step. This seems >> to be inconsistent with the advice in the other IDNA2008 RFCs. >> I'll need to investigate further and think about it some more. > > I think the fact that titlecase characters are not mentioned is > just an oversight. The mapping process further described a bit down > would also catch titlecase characters. Also note that while > IDNA2008 mandates normalization before validation what we have here > is mapping before normalization. That is appropriate since mappings > could cause the string to no longer be in NFC. > >>> The reason I'm very uncomfortable with even making this >>> OPTIONAL is the following: We do DNS lookup based on the >>> domainpart. That means we prepare it according to these rules, >>> perform punycode it, prepend "_xmpp-server._tcp." and do a SRV >>> lookup based on that. If we map certain characters (other than >>> what is specified for IDNA2008) to other ones, or nothing, what >>> we look up in DNS changes. I don't think that is the case for >>> anything currently in draft-yoneya-precis-mappings, but I think >>> it is dangerous terrain to tread on. > >> So, let's get down to cases (see draft-yoneya-precis-mappings, >> Section 4). > >> Are you worried about mapping of uppercase and titlecase >> characters to lowercase? It certainly seems that *not* mapping >> Example.Com to example.com would violate the principle of least >> user surprise. > >> The fullwidth and halfwidth characters are less familiar to most >> people on this list, but they are common in certain East Asian >> scripts. Mapping them to their decomposition mappings would, I >> think, make sense to most users of those scripts. > >> For domainparts, mapping of whitespace characters to SP (U+0020) >> does not apply. > >> The local case mappings in Section 4.3 of >> draft-yoneya-precis-mappings essentially capture the exceptions >> from the SpecialCasing.txt file in the Unicode character >> database. Applying those rules also makes sense to me (e.g., to >> handle "dotless i" in certain Turkic locales). > > As I said it does not seem that draft-yoneya-precis-mappings in > it's current state would cause any problem. In fact all mappings > you listed above are already specified by RFC 5895 (including the > ones from SpecialCasing.txt as part of the case folding). So this > is at best redundant. My worry however is that we say you MAY > perform any mappings. I'm not sure what the motivation for that is. > If any mappings that are not in line with what IDNA2008 specifies > are performed DNS lookup *will* fail. Either that or I'm > completely missing something. OK. So, one approach would simply be to say that a domainpart needs to conform to IDNA2008 and all A-labels need to be represented as U-labels. Full stop. Would that allay your concerns? >> [...] > >> BTW, see 6122bis-03 -- it now reads: > >> o The element for Data Forms [XEP-0004] communicated >> to the server, when the 'type' attribute is "jid-single" or >> "jid-multi". > >> I could add further clarification, such as: > >> o The element for Data Forms [XEP-0004] communicated >> to the server itself (e.g., as in [XEP-0133]), when the 'type' >> attribute is "jid-single" or "jid-multi". > > That is better, but we'd need that all over the place. E.g. also > for disco. I'd think a general statement up front would be better, > see below. > >>> I don't think we need to say which slots can occur in what >>> contexts. However, I do think we might be better off if we add >>> some text that makes it very clear that whether validation >>> needs to be performed is dependent on the context and not the >>> type of slot. > >> I might be missing something, but I'm not completely clear on >> what you mean by the constrast between context and type of slot. > > Okay, I had feared that this might be unclear, so let me try to > rephrase that as proposed text: > > "Note that while a server might be capable of detecting a certain > element or attribute is a JID slot, enforcing the rules on the > contained JID is only REQUIRED if the server needs to perform > further operations based on the value of the JID". Yes, that sums it up nicely. Thanks for the proposed text. > It may however be possible to integrate the same information > within the existing text. Right, I think it belongs in the section we're referring to. I'll do so in -04. >> In any case, do you find the text in -03 to be a bit clearer? >> Can you make suggested improvements to that text? I'll look at >> it again, as well. > > Yes, I do find the text in -03 is definitely an improvement. Thank > you for working on this. And thank you for the continued feedback. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAkOJIACgkQNL8k5A2w/vx8TACfYHiSM2Q8/ziPsXM9aiPcWOqn Y5cAoOeE2OkMKuLIIDP5+pyJciNktjF3 =ZLOI -----END PGP SIGNATURE----- From florob@babelmonkeys.de Thu Aug 9 16:49:54 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CFF21F8690 for ; Thu, 9 Aug 2012 16:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXxLviK4T91u for ; Thu, 9 Aug 2012 16:49:54 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 01A3E21F8681 for ; Thu, 9 Aug 2012 16:49:54 -0700 (PDT) Received: from xdsl-78-34-242-84.netcologne.de ([78.34.242.84] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SzcUC-0001Mr-Mo; Fri, 10 Aug 2012 01:49:52 +0200 Message-ID: <50244C9A.7080801@babelmonkeys.de> Date: Fri, 10 Aug 2012 01:49:46 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> <5023DA48.3080707@stpeter.im> <5024184E.6010206@babelmonkeys.de> <50243892.9020404@stpeter.im> In-Reply-To: <50243892.9020404@stpeter.im> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:49:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.08.2012 00:24, schrieb Peter Saint-Andre: > On 8/9/12 2:06 PM, Florian Zeitz wrote: >> Am 09.08.2012 17:42, schrieb Peter Saint-Andre: >>> Comments inline, areas of agreement snipped... > >> Same :) > > Ditto. :) > Idem. >>> On 8/8/12 8:38 PM, Florian Zeitz wrote: >>>> Am 08.08.2012 22:44, schrieb Peter Saint-Andre: > >>>>> On 8/4/12 4:51 PM, Florian Zeitz wrote: > [...] >> As I said it does not seem that draft-yoneya-precis-mappings in >> it's current state would cause any problem. In fact all mappings >> you listed above are already specified by RFC 5895 (including >> the ones from SpecialCasing.txt as part of the case folding). So >> this is at best redundant. My worry however is that we say you >> MAY perform any mappings. I'm not sure what the motivation for >> that is. If any mappings that are not in line with what IDNA2008 >> specifies are performed DNS lookup *will* fail. Either that or >> I'm completely missing something. > > OK. So, one approach would simply be to say that a domainpart needs > to conform to IDNA2008 and all A-labels need to be represented as > U-labels. Full stop. Would that allay your concerns? > I think that was in fact my initial suggestion, so yes, that would make me happy. However, seeing how we specify preparation and validation for all other JID parts, I would amend that slightly and also suggest saying that any mapping and normalization steps specified by IDNA2008 should be performed on user input, or data send by a client. - -- Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQJEyaAAoJELv//CFWsbyxqm8P/jBXi8UGWrIs0DFC4wCsDOpP 1SBmnVcVxPLGlsRVHbGAVuRr2zmixl1by4iHbIOXURU/LerUvp+Y8Sm80G7FRII2 fMhnkrszxD6YQqPtLLgrZ+RrZiDRX6ZbdvqW/BUIFStQiDAtBNAJIVytNCiz9/UH jm06uVH38Yvb1iGoxOBqnRbYHBt8vMt8kCrRbUL0eWZja8Co/uDZi9jbnHmu/Aav thx2Z8xFZRmEpqB5spaPz4k+O6RvSulmqm1tqA2cMrUcddRhYk0Ohxx/6hvGKUSa EAIx+5DktTljkLbbrTFmuV8RCKDpjJLcPEoqcSO/0w8kqlYOHiQocsHlhVIOXu95 wsYfNlqQvI3l5ok/Xuy07l9Q6V7EihjeHes6KSgUqXFRwKwPaFUd2Vzx87mQ3r7p MuiQ/VzkKMaCo4ZmPXORd0lh3WNm3B/XG83KFKKS+Oq9r10mfuRG9YhmDQ4J/s5k XR0amryYiAY+tA7es85D2fABn9HX0ytCZJ12PODubqYZx0pmmBsm4oMJvQBnpWMw w/evwIui8An0NTQaN5DxoCt+4TVsacBr6BuOwOQ6fuhwCzpbuRUWKjop1L+eCuZq Kje+2piGzZYVkEhiZ/v+Zq+EqL9t9Kfg5l/z42CSVa3Jwoev1PQWFbTXPp3aBzNV o8x3842lMThvPe29erFQ =OKmQ -----END PGP SIGNATURE----- From lennox@cs.columbia.edu Thu Aug 9 17:14:09 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8918B11E808A for ; Thu, 9 Aug 2012 17:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=2.110, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyFUJuPN67gF for ; Thu, 9 Aug 2012 17:14:09 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id F1F8F11E8099 for ; Thu, 9 Aug 2012 17:14:08 -0700 (PDT) Received: from compute01.cs.columbia.edu (compute01.cs.columbia.edu [128.59.11.31]) by mailbackend.panix.com (Postfix) with ESMTP id F0958281A8; Thu, 9 Aug 2012 20:14:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20516.21071.596329.893583@compute01.cs.columbia.edu> Date: Thu, 9 Aug 2012 20:14:07 -0400 To: Florian Zeitz In-Reply-To: <5024184E.6010206@babelmonkeys.de> References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> <5023DA48.3080707@stpeter.im> <5024184E.6010206@babelmonkeys.de> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Cc: xmpp@ietf.org Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:14:09 -0000 On Thursday, August 9 2012, "Florian Zeitz" wrote to "Peter Saint-Andre, xmpp@ietf.org" saying: > > The local case mappings in Section 4.3 of > > draft-yoneya-precis-mappings essentially capture the exceptions > > from the SpecialCasing.txt file in the Unicode character database. > > Applying those rules also makes sense to me (e.g., to handle > > "dotless i" in certain Turkic locales). > > > As I said it does not seem that draft-yoneya-precis-mappings in it's > current state would cause any problem. In fact all mappings you listed > above are already specified by RFC 5895 (including the ones from > SpecialCasing.txt as part of the case folding). So this is at best > redundant. My worry however is that we say you MAY perform any > mappings. I'm not sure what the motivation for that is. If any > mappings that are not in line with what IDNA2008 specifies are > performed DNS lookup *will* fail. Either that or I'm completely > missing something. I had a question about this case mapping issue, which I've brought up at previous IETFs, and with some more reading of the source documents I think I can make the comment more intelligently. RFC 5895 distinguishes between "user interface" and "protocol", because a number of transformations need to take into account "culture, context, and locale." Protocol needs to be specified normatively, but user interface shouldn't be. In the XMPP context, enforcement rules need to be about protocol, but JID creation should (I think) be in the realm of user interface. I think this distinction is currently not terribly clear in 6122bis; the algorithm in Section 2 reads like it's trying to do JID creation, whereas I think what we actually need to specify is how to do enforcement, and make sure that enforcement can be entirely locale-independent. To make this more concrete, when enforcing that a JID localpart is lower case, a server doesn't need to care whether a LATIN SMALL LETTER I was originally LATIN CAPITAL LETTER I, LATIN CAPITAL LETTER I WITH DOT ABOVE, or actually entered directly by a user; it's fine regardless. Conversely, if that localpart has a LATIN CAPITAL LETTER I in it the JID is malformed, and it doesn't matter what the equivalent normalized JID would be. -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com From florob@babelmonkeys.de Fri Aug 10 05:22:27 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70321F8507 for ; Fri, 10 Aug 2012 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daHzorP4pff1 for ; Fri, 10 Aug 2012 05:22:21 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9221F8508 for ; Fri, 10 Aug 2012 05:22:16 -0700 (PDT) Received: from xdsl-87-79-52-253.netcologne.de ([87.79.52.253] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SzoEH-0005RL-W1; Fri, 10 Aug 2012 14:22:14 +0200 Message-ID: <5024FCEF.3090406@babelmonkeys.de> Date: Fri, 10 Aug 2012 14:22:07 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <501DA76F.2000109@babelmonkeys.de> <5022CFB4.9060906@stpeter.im> <502322B1.6030609@babelmonkeys.de> <5023DA48.3080707@stpeter.im> <5024184E.6010206@babelmonkeys.de> <20516.21071.596329.893583@compute01.cs.columbia.edu> In-Reply-To: <20516.21071.596329.893583@compute01.cs.columbia.edu> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [xmpp] Comments on draft-ietf-xmpp-6122bis-02 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:22:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.08.2012 02:14, schrieb lennox@cs.columbia.edu: > > > On Thursday, August 9 2012, "Florian Zeitz" wrote to "Peter > Saint-Andre, xmpp@ietf.org" saying: > >> As I said it does not seem that draft-yoneya-precis-mappings in >> it's current state would cause any problem. In fact all mappings >> you listed above are already specified by RFC 5895 (including the >> ones from SpecialCasing.txt as part of the case folding). So this >> is at best redundant. My worry however is that we say you MAY >> perform any mappings. I'm not sure what the motivation for that >> is. If any mappings that are not in line with what IDNA2008 >> specifies are performed DNS lookup *will* fail. Either that or >> I'm completely missing something. > > I had a question about this case mapping issue, which I've brought > up at previous IETFs, and with some more reading of the source > documents I think I can make the comment more intelligently. > > RFC 5895 distinguishes between "user interface" and "protocol", > because a number of transformations need to take into account > "culture, context, and locale." Protocol needs to be specified > normatively, but user interface shouldn't be. > > In the XMPP context, enforcement rules need to be about protocol, > but JID creation should (I think) be in the realm of user > interface. I think this distinction is currently not terribly > clear in 6122bis; the algorithm in Section 2 reads like it's trying > to do JID creation, whereas I think what we actually need to > specify is how to do enforcement, and make sure that enforcement > can be entirely locale-independent. > > To make this more concrete, when enforcing that a JID localpart is > lower case, a server doesn't need to care whether a LATIN SMALL > LETTER I was originally LATIN CAPITAL LETTER I, LATIN CAPITAL > LETTER I WITH DOT ABOVE, or actually entered directly by a user; > it's fine regardless. Conversely, if that localpart has a LATIN > CAPITAL LETTER I in it the JID is malformed, and it doesn't matter > what the equivalent normalized JID would be. > Hi, thank you a lot for jumping in on this discussion. You helped me get some things a bit clearer in my head. First of all, I think you are precisely right. We have two separate things here: a) Trying to prepare user input such that it becomes a valid JID b) Asserting whether a JID is valid Let's start with b) (enforcement), because that is easier. We generally would do (not necessarily in this order): 1. isNFC(part) 2. is PVALID (for NameClass+restrictions, IDNA, and FreeClass respectively) 3. check the Bidi Rule is fulfilled (4. for the domainpart only, check if each label is a U-label) If any of these fails the JID is not valid. I think these conditions are somewhat scattered across the current draft, e.g. the Bidi Rule is always separated from the rest of these conditions, by a paragraph on preparation. I suspect that is what you perceive as a missing distinction in the current draft. So what about a) (preparation). I'd like to note that I had a big misconception about this before. As far as I remember people had previously argued that they want to write simple clients, that basically forwards user input to the server right away, possibly dealing with the fact that they get a back. Conversely the current draft says: «XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with the rules before including them in protocol slots within XML streams (such that JIDs and parts of JIDs are in conformance)» With that text in place I wonder what we would want to say about servers performing preparation. It generally should not be needed, yet (overly) simple clients that don't perform preparation would get a terrible user experience (i.e. typing a single uppercase character leads to a and very confused users). I have no strong opinion about this, I suspect poor overloaded servers would prefer to only do enforcement. It also is a lot clearer to me why I was so baffled by the text about mappings now. The problem here is not necessarily allowing other mappings, it's allowing arbitrary ones. We have a goal with this mappings, which is to get user input in a form that is a valid JID. So if our input contains codepoints that are disallowed it seems sensible to allow (possibly locale specific) additional mappings that map these disallowed codepoints to allowed ones. However, I'd want the text to include that restriction. To be clear, this is not specific to domainparts. (BTW I'm still intrigued by the fact that locale specific mappings seems to imply that a Turkish user typing e.g. STPETER.IM would get that mapped to something that has a U-label as TLD, but that's beside the point here) So, for preparation I think I'd suggest: For nodeparts and resourceparts: 1. case-folding 2. mappings from draft-yoneya-precis-mappings and other goal-oriented mappings 3. NFC (I think NFC last is actually correct, since mappings might lead combining characters appearing in the wrong order, but that is admittedly more of a hunch) For domainparts: 1. goal-oriented mappings 2. procedure from RFC 5895 (includes case-folding and NFC) Where goal-oriented means that it is a mapping from the set of disallowed codepoints to the set of allowed codepoints. - -- Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQJPzvAAoJELv//CFWsbyxn2wP/i2uGSV2we6V75VkzHQF3N8Q 6XniN9FsZqsKZpXEcLCZNYHokNK3Y9Cm6zysDLFeCBsKE8r9/sdv0yu1k1j7QhWU 8PMLM1m98HvYCJSjmxQENVzVWRCITnTNyiMT4ucbadz+mC72lHaTXO8xUKjDiXTw 80J546lW6HxyExTzWlU4OvPPVAnUV3N5qVWQKSWhfilSQoSO3FEetB/cvs56Mq/v NB+FpECLa9z9Q5iB58fObM0Z6rhFy8KPc0t5gnZV6Kev2q5+kEhZcn6ea8GsHhGf BlXurhdZzAgOdtLfRGhiczzjvCWUm2pDm1TAueZcH+EunRSpfaVMsEjXVfOxGsjy T4wkSeTTNEQY6lHyxHvBgXwGpe9ovKZe+y48Nd+HqD3/hwVRikPNC/Ji6tHrWaVT v+OBAmMFFWLdtlS3aBmQ6lAGFiUV2OlA+5k2AqoiYEbQOxXW5mewGXqvTzhBuXhf GKtLW30f74oY01XCg/+nkNjPdrnAHLrwLLzpQEbwvSw3KDh4VdWS1sGt7BBjBFlT vJLVyYYWcrok//tybE07sRxP7jytqPhCO7P7g1aJ88utjOwHThURsn91Uf6u7AMR 4gTtfKUL7ikZzBGmF/mLZd/UHDxyQCAFEe+TcJUD5Xp2mPv2TjzcPT/Y/7wT7CEk MQ19gRElkIMsX/mL3NeY =ZVFX -----END PGP SIGNATURE----- From ben@nostrum.com Fri Aug 10 11:34:56 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8921F86AD for ; Fri, 10 Aug 2012 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz+-x8uM-K1P for ; Fri, 10 Aug 2012 11:34:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE7421F8526 for ; Fri, 10 Aug 2012 11:34:56 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7AIYsCS031089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 13:34:55 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 13:34:54 -0500 Message-Id: <2632B358-F94B-4A41-BAEA-B8516F4EB82F@nostrum.com> To: XMPP Group Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [xmpp] Draft Minutes X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:34:56 -0000 Hi everyone, The draft minutes from the XMPP meeting at IETF84 are available at the = following link. Please send any corrections to the XMPP list and the = chairs. http://www.ietf.org/proceedings/84/minutes/minutes-84-xmpp Thanks! Ben.=