From stpeter@stpeter.im Thu Mar 1 14:28:59 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 3AEE321E836D for ; Thu, 1 Mar 2012 14:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.772 X-Spam-Level: X-Spam-Status: No, score=-102.772 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 LJfyyAYefeOo for ; Thu, 1 Mar 2012 14:28:58 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 81A9F21E809C for ; Thu, 1 Mar 2012 14:28:58 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 55D9F4005A; Thu, 1 Mar 2012 15:40:39 -0700 (MST) Message-ID: <4F4FF829.1080705@stpeter.im> Date: Thu, 01 Mar 2012 15:28:57 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Multi-User Chat over XMPP , XMPP , XMPP Extension Discussion List References: <4F4FF778.8000402@stpeter.im> In-Reply-To: <4F4FF778.8000402@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <4F4FF778.8000402@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames 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, 01 Mar 2012 22:28:59 -0000 FYI, there's discussion happening on the SIMPLE WG list about internationalization of nicknames in chatrooms. There might be value in pursuing a common approach. Please follow up on the simple@ietf.org list: https://www.ietf.org/mailman/listinfo/simple -------- Original Message -------- Subject: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames Date: Thu, 01 Mar 2012 15:26:00 -0700 From: Peter Saint-Andre To: Ben Campbell CC: Simple WG On 3/1/12 3:12 PM, Ben Campbell wrote: > > On Mar 1, 2012, at 3:55 PM, Miguel A. Garcia wrote: > >> Dear all: >> >> I am trying to address the last known issue of the SIMPLE chat >> draft. This came through Enrico Marocco's Appsdir review, and the >> comment was: >> >> The document doesn't describe allowed characters in Nicks and any >> normalization that needs to be applied. >> >> So, I got advice from Alexy Melnikov, indicating that we should >> take a look at the ResourcePrep in: >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ >> >> The idea is to inspire on the ResourcePrep and adapted to Nicknames >> in SIMPLE chat. However, there is a dependency on the completion of >> the Precis Framework: >> https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ >> >> This means that SIMPLE chat will need to add a normative dependency >> to the Precis Framework, and if SIMPLE chat is approved and arrives >> to the RFC Editor before the Precis Framework, it will stay there >> until the framework reaches the RFC editor. > > (as individual) > > I concur with this approach in general, although I think we will find > some differences between the Resource parts in 6122/6122bis and the > use of nicknames in simple-chat. In particular: > > 1) A resource part identifies something. That makes uniqueness and > comparisons fairly important. OTOH, a nickname is really for human > display purposes. We still need to be able to compare them for > reservations to work. And the human readability part means we should > at least mention character confusion issues. In the chatroom context, XMPP resourceparts are mostly used for display purposes but also for some authorization decisions (e.g., we can kick people based on their nickname). As far as I understand it, the uses are really quite similar in XMPP chatrooms and SIMPLE chatrooms. > 2) The 6122bis resource parts live inside URIs, while simple-chat > nicknames are just strings. Well, we don't really use URIs in XMPP. Probably you mean JIDs (JabberIDs). In that case, yes, they are used sometimes for addressing in XMPP chatrooms (e.g., to send a private message to another occupant). > I'm not sure that these differences really change the outcome > much--they're just things to think about. Although I think that XMPP resourceparts *as they are used in chatrooms* are quite similar to SIMPLE nicknames, resourceparts are used in other contexts (e.g., as device/connection identifiers) so the resourceprep replacement that's developed in the XMPP WG won't be quite what you need anyway. However, there probably is value in thinking about nicks in general, because it's possible that we could define the same PRECIS profile for use in both XMPP chatrooms (XEP-0045) and SIMPLE chatrooms. A common approach might be good. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From fippo@mail.symlynx.com Fri Mar 2 00:11:35 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 8E02C21E800E for ; Fri, 2 Mar 2012 00:11:35 -0800 (PST) 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 aLGy9AYbb58l for ; Fri, 2 Mar 2012 00:11:34 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8C21F8752 for ; Fri, 2 Mar 2012 00:11:32 -0800 (PST) Received: from [192.168.178.37] (p548BDD62.dip.t-dialin.net [84.139.221.98]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q228B6RW011223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Mar 2012 09:11:30 +0100 Message-ID: <4F508095.50104@mail.symlynx.com> Date: Fri, 02 Mar 2012 09:11:01 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [xmpp] host-unknown stream error example in rfc 6120 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, 02 Mar 2012 08:11:35 -0000 the example for the host-unknown stream error is quite odd http://tools.ietf.org/html/rfc6120#section-4.9.1.3 What the example describes is that a client opens a stream from='juliet@im.example.com' to='unknown.host.example.com' and gets a response stream from='im.example.com' to='juliet@im.example.com' The example is technically correct. However, since xmpp clients typically only talk to their server, it does not make sense for juliet@im.example.com to open a stream to any other server than im.example.com. Copy-paste lazyness presumably ;-) I suggest changing the initial stream header to from='juliet@im.example.com' to='im.example.com' and the response stream header to from='' to='juliet@im.example.com' i.e. juliet attempts to contact her server and it has gone away. Actually, the host-gone stream error seems like a better example for that section. The strategy of avoiding the from/to swap certainly applies to that error as well. From rbarnes@bbn.com Fri Mar 2 07:23:15 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 1FFA621F866C for ; Fri, 2 Mar 2012 07:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.956 X-Spam-Level: X-Spam-Status: No, score=-105.956 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjhvTdEpck9U for ; Fri, 2 Mar 2012 07:23:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2C21F8663 for ; Fri, 2 Mar 2012 07:23:14 -0800 (PST) Received: from [128.89.255.207] (port=63901) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S3UK0-0001Du-6e; Fri, 02 Mar 2012 10:23:04 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> Date: Fri, 2 Mar 2012 10:23:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <450CB9EA-82F2-474C-BB2E-76C0F652D126@bbn.com> References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1251.1) Cc: xmpp@ietf.org Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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, 02 Mar 2012 15:23:15 -0000 Hey Matt, Thanks for picking this thread back up. Couple of observations inline = below. > I think this can (should?) also apply to the users at a domain; how = does romeo@montegue.lit know that the servers for shakespeare.lit hosts = his domain. +1 =20 Also, seems relevant to C2S as well as S2S, since you're trying to = authenticate the destination domain in both cases. > Solution: >=20 > The solution talked about to date has been to develop a protocol = framework to assert (or challenge) an domain from a set of possible = proof types. It is assumed that all connections are secured via TLS, = although not trusted until the assertions are accepted. Since part of = the proving happens in protocol, it means that the end-points suspend = disbelief about the certificates until this additional validation = completes. >=20 > There are two basic use cases (I am not a playwright, so no critiques = of the dialogue): >=20 > 1) "asserting": A server connects to another server, and asserts it is = authorized for a domain >=20 > (1.0 denmark.lit: I can accept your assertions!) > 1.1 montegue.lit: I am montegue.lit! > 1.2 denmark.lit: prove it, using one of these forms... (possible = optimization: accepted because of other channels) > 1.3 proving ... > 1.4 denmark.lit: Accepted (or rejected) >=20 > 2) "challenging": A server (or client) is connected to another server, = and challenges if it is authorized for a domain ("Are you X?") >=20 > (2.0 montegue.lit: I can assert my identity!) > 2.1 denmark.lit: Are you montegue.lit? Prove it, using one of these = forms... > 2.2 proving ... > 2.3 denmark.lit: Accepted (or rejected) >=20 > Here, "proving" is a protocol exchange of proof-specific details. In = practice, this might look a lot like SASL=85 Well, yes, when you abstract this much, it looks a lot like SASL :) I would keep in mind that the DNS-based solutions below, there would = probably be no actual SASL; you would probably pass the challenge and = proof out-of-band, in advance of the actual XMPP connection. For = example, in the DANE case, the initiating side will pull DANE records = from the DNS before initiating TLS to the responding side. It seems like what we're doing here should be doable at the = TLS layer, since authenticating domain names is what TLS does all the = day long. > There are a couple prooftypes that have been discussed (on- or = off-list) so far, plus some other avenues that can be investigated: >=20 > * .well-known from HTTPS > * attribute certificates > * DANE > * "dialback without dialback"[1] If the "db sans db" solution is the one I wrote up in = draft-ietf-xmpp-dna, then I think we can put that one aside for now in = favor of the DANE solution. =20 > As for documenting this, I'll be looking at starting at least two = drafts: the protocol framework and the HTTPS/.well-known prooftype. = I'll later look into another draft for the attribute certificate = prooftype, and help Peter Saint-Andre for a DANE proof type. I would also be glad to help out with a DANE version. Version -1: 0. denmark.lit wants to connect to capulet.lit 1. denmark.lit queries for TLSA records under = _xmpp-server._tcp.capulet.lit, gets DANE assertions 2. denmark.lit connects to capulet.lit [normal connection process] 3. denmark.lit initiates STARTTLS and verifies that the presented = certificate matches the DANE assertions Note that part of this process will be specifying how to use DANE for = XMPP, since the DANE WG declined to define something that would cover = XMPP. --Richard From mamille2@cisco.com Fri Mar 2 07:54:32 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 6B05B21F845C for ; Fri, 2 Mar 2012 07:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] 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 Rxf6NhR8MrmZ for ; Fri, 2 Mar 2012 07:54:31 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 799F021F8459 for ; Fri, 2 Mar 2012 07:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5192; q=dns/txt; s=iport; t=1330703671; x=1331913271; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=O4oHCjmh3K0qQ9MIuFeb/rEyqniFUnxRKgC8BBIG1/0=; b=BLvnYDVwBGiOnPysY6z3NCfJehRCvQ4YOjGHJxa2+eKzXIHPXomlSq7w nZlWOZ6AO6l9YuBY3NcpGAX9ohvuc8J++toM0q03fNZeVS1kt3zoTxiCq VwU71dPGclfiRkb2LfJSQAYnA7jMjuDGU2SW3xglE3vt4Y2cgsXaZuqVd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH7sUE+rRDoJ/2dsb2JhbAA6CYU/rwaBB4F9AQEBAwESARBWBQsLDgwCJgICVwYTGQIHh18EoRMBjGWKNoEviFaESTNjBIhQjG6TFYE0AhQD X-IronPort-AV: E=Sophos;i="4.73,518,1325462400"; d="scan'208";a="34095652" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 02 Mar 2012 15:54:31 +0000 Received: from sjc-vpn3-155.cisco.com (sjc-vpn3-155.cisco.com [10.21.64.155]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q22FsUVB006824; Fri, 2 Mar 2012 15:54:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Matt Miller In-Reply-To: <450CB9EA-82F2-474C-BB2E-76C0F652D126@bbn.com> Date: Fri, 2 Mar 2012 08:54:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> <450CB9EA-82F2-474C-BB2E-76C0F652D126@bbn.com> To: Richard Barnes X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: xmpp@ietf.org Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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, 02 Mar 2012 15:54:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 2, 2012, at 08:23, Richard Barnes wrote: > Hey Matt, >=20 > Thanks for picking this thread back up. Couple of observations inline = below. >=20 >> I think this can (should?) also apply to the users at a domain; how = does romeo@montegue.lit know that the servers for shakespeare.lit hosts = his domain. >=20 > +1 =20 >=20 > Also, seems relevant to C2S as well as S2S, since you're trying to = authenticate the destination domain in both cases. >=20 I'm glad there's some agreement! >=20 >> Solution: >>=20 >> The solution talked about to date has been to develop a protocol = framework to assert (or challenge) an domain from a set of possible = proof types. It is assumed that all connections are secured via TLS, = although not trusted until the assertions are accepted. Since part of = the proving happens in protocol, it means that the end-points suspend = disbelief about the certificates until this additional validation = completes. >>=20 >> There are two basic use cases (I am not a playwright, so no critiques = of the dialogue): >>=20 >> 1) "asserting": A server connects to another server, and asserts it = is authorized for a domain >>=20 >> (1.0 denmark.lit: I can accept your assertions!) >> 1.1 montegue.lit: I am montegue.lit! >> 1.2 denmark.lit: prove it, using one of these forms... (possible = optimization: accepted because of other channels) >> 1.3 proving ... >> 1.4 denmark.lit: Accepted (or rejected) >>=20 >> 2) "challenging": A server (or client) is connected to another = server, and challenges if it is authorized for a domain ("Are you X?") >>=20 >> (2.0 montegue.lit: I can assert my identity!) >> 2.1 denmark.lit: Are you montegue.lit? Prove it, using one of these = forms... >> 2.2 proving ... >> 2.3 denmark.lit: Accepted (or rejected) >>=20 >> Here, "proving" is a protocol exchange of proof-specific details. In = practice, this might look a lot like SASL=E2=80=A6 >=20 > Well, yes, when you abstract this much, it looks a lot like SASL :) >=20 > I would keep in mind that the DNS-based solutions below, there would = probably be no actual SASL; you would probably pass the challenge and = proof out-of-band, in advance of the actual XMPP connection. For = example, in the DANE case, the initiating side will pull DANE records = from the DNS before initiating TLS to the responding side. >=20 I fully expect most of the mechanisms/algorithms/processes/thingies will = be out-of-band of XMPP. The in-band came from some off-line discussions = with a couple other server implementors and architects. If no one else sees value in that, I'm more than happy to preclude any = mechanism-specific exchanges in-band. > It seems like what we're doing here should be doable at the = TLS layer, since authenticating domain names is what TLS does all the = day long. >=20 Once DNSSEC and DANE are ubiquitous, I'd be more than happy to drop = anything else. Until then, I think we need to keep our options slightly = more open. >> There are a couple prooftypes that have been discussed (on- or = off-list) so far, plus some other avenues that can be investigated: >>=20 >> * .well-known from HTTPS >> * attribute certificates >> * DANE >> * "dialback without dialback"[1] >=20 > If the "db sans db" solution is the one I wrote up in = draft-ietf-xmpp-dna, then I think we can put that one aside for now in = favor of the DANE solution. =20 >=20 less is more (-: >=20 >> As for documenting this, I'll be looking at starting at least two = drafts: the protocol framework and the HTTPS/.well-known prooftype. = I'll later look into another draft for the attribute certificate = prooftype, and help Peter Saint-Andre for a DANE proof type. >=20 > I would also be glad to help out with a DANE version. Version -1: > 0. denmark.lit wants to connect to capulet.lit > 1. denmark.lit queries for TLSA records under = _xmpp-server._tcp.capulet.lit, gets DANE assertions > 2. denmark.lit connects to capulet.lit [normal connection process] > 3. denmark.lit initiates STARTTLS and verifies that the presented = certificate matches the DANE assertions >=20 > Note that part of this process will be specifying how to use DANE for = XMPP, since the DANE WG declined to define something that would cover = XMPP. Thanks for the offer! Peter and I were planning to work on the = DANE-based proposal in his Life after IESG=E2=84=A2 period. - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPUO02AAoJEJq6Ou0cgrSPKdEIAJcEi5rtqxu7PHnjG4/q9uUS WPb2eogqAqncMM3JPsC58Gf6WsdM8sJhmVVGsy2jetQh9KWT9Z26n2/uAhiAx/Ax ackY6uL9SdeXKjyePl0QvSxKYdMvCwO+KFfHgjnB0BOzUfQ+S86rnuAdNbt+5G4+ i3uS7pIDYSfOyZOTrdWNcSbC1Yhmtn1NeSQLN8dU3gM6Y8X8YIEQrpWbFXag3KKD G1N9CWkjjz5HV2oItLNYlRedF4V08YoKVh9xTIjLQRtZ6t4D+DS6dRgJ3MSajk1+ PB/d/JIXVhPzST2QN6kAP9l2WbCA6TX1ckHY4jnp13t77db+5uy5h/JVHcDUZUI=3D =3DlMvf -----END PGP SIGNATURE----- From dave@cridland.net Fri Mar 2 09:04:04 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 AB58C21F86BA for ; Fri, 2 Mar 2012 09:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_73=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 JVUF25i8R4Ca for ; Fri, 2 Mar 2012 09:04:03 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5721F86D7 for ; Fri, 2 Mar 2012 09:04:01 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 724A51168087; Fri, 2 Mar 2012 17:03:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5tUulIMMkI6; Fri, 2 Mar 2012 17:03:52 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id BA5541168067; Fri, 2 Mar 2012 17:03:52 +0000 (GMT) References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> In-Reply-To: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> MIME-Version: 1.0 Message-Id: <9470.1330707832.760127@puncture> Date: Fri, 02 Mar 2012 17:03:52 +0000 From: Dave Cridland To: Matt Miller , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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, 02 Mar 2012 17:04:04 -0000 On Fri Jan 27 20:05:22 2012, Matt Miller wrote: > To restate the problem: How to determine that a multi-domain > hosting service is authorized for a given domain, in a manner that > allows connections to a hosting service be shared for multiple > domains. > > You need to ensure you've additionally added in piggybacking (Or stream multiplexing, or whatever we call this now) - or at the very least not prevented it. This changes the scenery rather a lot. > I think this can (should?) also apply to the users at a domain; how > does romeo@montegue.lit know that the servers for shakespeare.lit > hosts his domain. Mmmmm.... Kind of. Yes, users need to authenticate and authorize their servers. But the thing is, users never need to piggyback target domains, and additionally, for users, they've typically got mutual authentication via SASL. Finally, we can cheat a bit and lessen the need for signalling - if we do this - so the authorizing agent can handle the entire authorization process without any support from the authorizee - then it saves us a In fact, I'm not even convinced we ever need signalling, aside from the fact people will march on me with flaming pitchforks if I suggest that. But since I've just had a new moat put in at Castle Cridland, and the drawbridge is properly oiled... > There are a couple prooftypes that have been discussed (on- or > off-list) so far, plus some other avenues that can be investigated: > > * .well-known from HTTPS > * attribute certificates > * DANE > * "dialback without dialback"[1] OK. ".well-known from HTTPS", and "attribute certificates" (and signed-blobs-of-XML) are all equivalents. d-w-d on the other hand is a hunk of protocol for declaring a need to authenticate. Let me put up a concrete proposal: Our authorization proof is going to consist of a copy of the hosting certificate held at the domain owner's HTTPS site at .well-known/authorization/hosted-domain/_tcp/_xmpp-server/certificate.crt in DER (ie, not PEM). I'm going to call this protocol TurboHalibut. The details don't really matter that much. The name *absolutely* does. So, for hamlet@demark.lit, connecting to his server is business as usual, since it's self hosted. For juliet@capulet.lit, on the other hand, things are a bit different. The certificate she gets from connecting normally doesn't match. At this point, traditional wisdom is for her to disconnect with an error. In practise, what actually happens is that Juliet's client will ask Juliet if she wants to ignore years of careful security analysis and just continue anyway. But with TurboHalibut, her client can now take the additional step of connecting to the HTTPS site https://capulet.lit, checking *that* certificate against capulet.lit, and then checking the certificate held in TurboHalibut is the same one it's got from the XMPP service. Look, mom, no signalling - shakespeare.lit doesn't need to support any new protocol for this use-case, because it's all been handled out of band. Juliet's client, though, does need to implement TurboHalibut. So Hamlet decides to send a message to Juliet. denmark.lit connects to shakespeare.lit, and sees the wrong certificate - but denmark.lit can verify it in exactly the same way. Again, shakespeare.lit needn't support TurboHalibut. Finally, when, some time later, Juliet deigns to respond, "Art thou not Hamlet, and in completely the wrong play?", then shakespeare.lit connects to denmark.lit. Now denmark.lit can again use TurboHalibut to validate shakespeare.lit's certificate. None of this, you'll note, uses any dialback - probably. It can all use SASL EXTERNAL just as well, at the very least. But it *could* use as the authentication mechanism just as well - in fact, it's somewhat more reliable doing it this way, because servers are always good enough to supply a to and from, and it's faster because it uses fewer round-trips. The fact that the corresponding traffic never happens is just a distraction. It gets a lot more compelling doing things this way if Romeo, wondering why Hamlet is chatting up his romantic interest, drops him a message. Shakespeare.lit already has a connection to denmark.lit from capulet.lit, and it's already authenticated that connection - so it makes sense to reuse it. It can't use SASL, so instead it just sends a . Denmark.lit treats this *exactly the same way* as a SASL EXTERNAL - it checks the from address against the certificate, and should this fail - and it does, of course - it uses TurboHalibut to validate the certificate, and sends back the authorizing . Again, in this case, shakespeare.lit need not know anything about TurboHalibut. In fact, it can cheerfully assume that denmark.lit is doing "real" dialback. However, I stress - dialback without dialback is merely a solution for piggybacking. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From fippo@mail.symlynx.com Sun Mar 4 23:47:26 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 9D6EF11E8079 for ; Sun, 4 Mar 2012 23:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=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 pcvRsFvlq02Q for ; Sun, 4 Mar 2012 23:47:26 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3B11E8076 for ; Sun, 4 Mar 2012 23:47:24 -0800 (PST) Received: from [192.168.178.37] (p548BDE15.dip.t-dialin.net [84.139.222.21]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q257lACF025003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Mar 2012 08:47:22 +0100 Message-ID: <4F546F79.2040506@mail.symlynx.com> Date: Mon, 05 Mar 2012 08:47:05 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: xmpp@ietf.org References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> <9470.1330707832.760127@puncture> In-Reply-To: <9470.1330707832.760127@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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: Mon, 05 Mar 2012 07:47:26 -0000 Dave Cridland wrote: > You need to ensure you've additionally added in piggybacking (Or stream > multiplexing, or whatever we call this now) - or at the very least not > prevented it. > > This changes the scenery rather a lot. As does bidirectionality. "trying to authenticate the destination domain" and "trying to authenticate the source domain" become the same task then -- the only difference is when this happens. [...] > In fact, I'm not even convinced we ever need signalling I suspect that the unhappy paths such as dealing with bounces might get alot harder without signalling. [...] > d-w-d on the other hand is a hunk of protocol for declaring a need to > authenticate. d-w-d is an umbrella term. It is about getting rid of the old notion of "server dialback" as a ten/four step process as explained in RFC 3920 and (embarassingly so) again in the "harmonized" versions of XEP 220 0.9+. [...] > Again, in this case, shakespeare.lit need not know anything about > TurboHalibut. In fact, it can cheerfully assume that denmark.lit is > doing "real" dialback. Actually, shakespeare.lit does not care whether it is authenticated by denmark.lit. What matters is that denmark.lit has signalled that it is going to accept stanzas from shakespeare.lit. The only reason to use for this is that backward compability works like a charm. From stpeter@stpeter.im Mon Mar 5 08:45:28 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 BCFE021F8771 for ; Mon, 5 Mar 2012 08:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=-0.189, 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 DA5aJZzSakST for ; Mon, 5 Mar 2012 08:45:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 237B821F876F for ; Mon, 5 Mar 2012 08:45:28 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4BD5B40058 for ; Mon, 5 Mar 2012 09:57:21 -0700 (MST) Message-ID: <4F54EDA9.5090300@stpeter.im> Date: Mon, 05 Mar 2012 09:45:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: resourcepart 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: Mon, 05 Mar 2012 16:45:28 -0000 Discussion about a possible PRECIS profile for nicknames spilled over from the SIMPLE WG to the standards@xmpp.org list the other day. One issue that came up was possibly treating resourceparts in general as "absolute identifiers" (see draft-iab-identifier-comparison) and thus as subject merely to byte-for-byte comparison, not a full-blown PRECIS profile. This might simplify matters quite a bit. However, we would then define a PRECIS profile for nicknames, so that resourceparts as used in multi-user chat (XEP-0045) could be handled more intelligently. This approach makes quite a bit of sense to me, so I might collaborate with our friends in the SIMPLE WG on a PRECIS profile for nicknames (the decision about resourceparts is separate from that, but related). Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Mon Mar 5 11:05:53 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 49F4921F87EA for ; Mon, 5 Mar 2012 11:05:53 -0800 (PST) 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 Y6L0HqWB+6qB for ; Mon, 5 Mar 2012 11:05:52 -0800 (PST) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id A618821F87D6 for ; Mon, 5 Mar 2012 11:05:52 -0800 (PST) Received: from xdsl-84-44-250-100.netcologne.de ([84.44.250.100] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S4dED-0007MD-Rr for xmpp@ietf.org; Mon, 05 Mar 2012 20:05:49 +0100 Message-ID: <4F550E88.5010200@babelmonkeys.de> Date: Mon, 05 Mar 2012 20:05:44 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: <4F54EDA9.5090300@stpeter.im> In-Reply-To: <4F54EDA9.5090300@stpeter.im> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis: resourcepart 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: Mon, 05 Mar 2012 19:05:53 -0000 Am 05.03.2012 17:45, schrieb Peter Saint-Andre: > Discussion about a possible PRECIS profile for nicknames spilled over > from the SIMPLE WG to the standards@xmpp.org list the other day. One > issue that came up was possibly treating resourceparts in general as > "absolute identifiers" (see draft-iab-identifier-comparison) and thus as > subject merely to byte-for-byte comparison, not a full-blown PRECIS > profile. This might simplify matters quite a bit. However, we would then > define a PRECIS profile for nicknames, so that resourceparts as used in > multi-user chat (XEP-0045) could be handled more intelligently. This > approach makes quite a bit of sense to me, so I might collaborate with > our friends in the SIMPLE WG on a PRECIS profile for nicknames (the > decision about resourceparts is separate from that, but related). > > Peter > Hello Peter, could you elaborate a bit on the "not a full-blown PRECIS profile" part. I'd certainly hope we would still specify valid/disallowed code points. My rational for this is that clients currently tend to display resources. As such assuming all bytes are created equal might severely break some client's interface and create a security threat for terminal based clients (control characters). Regards, Florian Zeitz From stpeter@stpeter.im Mon Mar 5 13:20:51 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 8912D21E8036 for ; Mon, 5 Mar 2012 13:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.783 X-Spam-Level: X-Spam-Status: No, score=-102.783 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 XlaCn4mLmC-s for ; Mon, 5 Mar 2012 13:20:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 099F421E8024 for ; Mon, 5 Mar 2012 13:20:49 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8897940058 for ; Mon, 5 Mar 2012 14:32:42 -0700 (MST) Message-ID: <4F552E2F.80302@stpeter.im> Date: Mon, 05 Mar 2012 14:20:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> In-Reply-To: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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: Mon, 05 Mar 2012 21:20:51 -0000 As seen on the I-D-announce list... -------- Original Message -------- Subject: I-D Action: draft-ivov-xmpp-cusax-00.txt Date: Mon, 05 Mar 2012 12:18:24 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Combined Use of the Session Initiation Protocol (SIP) and the eXtensible Messaging and Presence Protocol (CUSAX) Author(s) : Emil Ivov Enrico Marocco Filename : draft-ivov-xmpp-cusax-00.txt Pages : 8 Date : 2012-03-05 This document describes current practices for combined use of the Session Initiation Protocol (SIP) and the eXtensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complimenting subsets of features from each of the protocols. Typically such subsets would include telephony oriented from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for neither SIP nor XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined us should be preferred to the mechanisms provided natively by each protocol like for example SIP's SIMPLE or XMPP's Jingle. It merely aims to provide guidance to those who are interested in such a combined use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Mon Mar 5 13:21: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 C849421E8039 for ; Mon, 5 Mar 2012 13:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 vnenCm2rylY0 for ; Mon, 5 Mar 2012 13:21:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9CB21E8024 for ; Mon, 5 Mar 2012 13:21:22 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 092EC40058 for ; Mon, 5 Mar 2012 14:33:07 -0700 (MST) Message-ID: <4F552E49.9070000@stpeter.im> Date: Mon, 05 Mar 2012 14:21:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP References: <20120305201639.24006.81528.idtracker@ietfa.amsl.com> In-Reply-To: <20120305201639.24006.81528.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20120305201639.24006.81528.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-tschofenig-ecrit-xmpp-es-00.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: Mon, 05 Mar 2012 21:21:24 -0000 Also seen on I-D-announce... -------- Original Message -------- Subject: I-D Action: draft-tschofenig-ecrit-xmpp-es-00.txt Date: Mon, 05 Mar 2012 12:16:39 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP) Author(s) : Hannes Tschofenig Filename : draft-tschofenig-ecrit-xmpp-es-00.txt Pages : 17 Date : 2012-03-05 The Extensible Messaging and Presence Protocol (XMPP) is a technology that enjoys widespread deployment in the instant messaging application domain. While many features for XMPP had been standardized in the IETF as well as in the XMPP Standards Foundation emergency services functionality was not part of it. This document aims to initiate a discussion about the necessary emergency services functionality for XMPP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From stpeter@stpeter.im Mon Mar 5 14:08:48 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 E554121F8885 for ; Mon, 5 Mar 2012 14:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.78 X-Spam-Level: X-Spam-Status: No, score=-102.78 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 roxMzhmcWZWZ for ; Mon, 5 Mar 2012 14:08:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8482A21F8881 for ; Mon, 5 Mar 2012 14:08:48 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 520E740058 for ; Mon, 5 Mar 2012 15:20:42 -0700 (MST) Message-ID: <4F55396F.6030106@stpeter.im> Date: Mon, 05 Mar 2012 15:08:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP References: <20120305220012.23949.48147.idtracker@ietfa.amsl.com> In-Reply-To: <20120305220012.23949.48147.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20120305220012.23949.48147.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-saintandre-precis-nickname-00.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: Mon, 05 Mar 2012 22:08:49 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-saintandre-precis-nickname-00.txt Date: Mon, 05 Mar 2012 14:00:12 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Preparation and Comparison of Nicknames Author(s) : Peter Saint-Andre Filename : draft-saintandre-precis-nickname-00.txt Pages : 6 Date : 2012-03-05 This document describes how to prepare and compare Unicode strings representing nicknames, primarily as used within textual chatrooms. This profile is intended to be used by chatroom technologies based on both the Extensible Messaging and Presence Protocol (XMPP) and the Message Session Relay Protocol (MSRP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-precis-nickname-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-saintandre-precis-nickname-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From emil@sip-communicator.org Tue Mar 6 03:00:21 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 7E7D721F86CF for ; Tue, 6 Mar 2012 03:00:21 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BAWhlKurPL0Y for ; Tue, 6 Mar 2012 03:00:20 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21FEA21F8817 for ; Tue, 6 Mar 2012 03:00:19 -0800 (PST) Received: by eeke51 with SMTP id e51so1795439eek.31 for ; Tue, 06 Mar 2012 03:00:19 -0800 (PST) Received-SPF: pass (google.com: domain of emil@sip-communicator.org designates 10.14.38.193 as permitted sender) client-ip=10.14.38.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of emil@sip-communicator.org designates 10.14.38.193 as permitted sender) smtp.mail=emil@sip-communicator.org Received: from mr.google.com ([10.14.38.193]) by 10.14.38.193 with SMTP id a41mr13382420eeb.125.1331031619333 (num_hops = 1); Tue, 06 Mar 2012 03:00:19 -0800 (PST) Received: by 10.14.38.193 with SMTP id a41mr10157760eeb.125.1331031619135; Tue, 06 Mar 2012 03:00:19 -0800 (PST) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id z47sm47294555een.5.2012.03.06.03.00.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 03:00:18 -0800 (PST) Message-ID: <4F55EE40.8000205@jitsi.org> Date: Tue, 06 Mar 2012 13:00:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Peter Saint-Andre References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> In-Reply-To: <4F552E2F.80302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk5P2NPFGJjXOVfyfR0Z2gGNedp59MistRMSHChYQGVzkijEKg5gIWjDTnhTFrnEMghjvUW Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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: Tue, 06 Mar 2012 11:00:21 -0000 Thanks for the note, Peter! All, the draft addresses a problem that has been raised and discussed on multiple occasions (including the SIXPAC effort from about a year ago). The point of this approach is to simply put forward common practices that people are resorting to in order to combine strengths of SIP and XMPP implementations. This is a very preliminary version that we've submitted in order to gauge interest, get initial feedback on open issues and the approach itself (and the fact that it was submitted a couple of hours before 00 cutoff is of course purely coincidental). What we'd like to hear at this time is whether people think such a document would make sense and also: * currently the document only vaguely mentions client provisioning. Does anyone think we should make this more specific and possibly quote some existing mechanisms? * During the SIXPAC effort it was suggested that clients could log onto a SIP service and use the domain parameter in digest authentication to discover the XMPP domain. Does anyone think this would make sense? * Currently the draft suggests a couple of alternatives for determining an XMPP identity from an incoming SIP request. One consists in searching the roster for an entry whose VCARD contains the source URI (but that only works if the caller is already in our roster). The other one would be to add a second contact header to outgoing INVITEs and put an xmpp uri in there corresponding to the caller's JID. Any thoughts on this? Cheers, Emil -- http://jitsi.org On 05.03.12 23:20, Peter Saint-Andre wrote: > As seen on the I-D-announce list... > > > -------- Original Message -------- > Subject: I-D Action: draft-ivov-xmpp-cusax-00.txt > Date: Mon, 05 Mar 2012 12:18:24 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Combined Use of the Session Initiation Protocol (SIP) > and the eXtensible Messaging and Presence Protocol (CUSAX) > Author(s) : Emil Ivov > Enrico Marocco > Filename : draft-ivov-xmpp-cusax-00.txt > Pages : 8 > Date : 2012-03-05 > > This document describes current practices for combined use of the > Session Initiation Protocol (SIP) and the eXtensible Messaging and > Presence Protocol (XMPP). Such practices aim to provide a single > fully featured real-time communication service by using complimenting > subsets of features from each of the protocols. Typically such > subsets would include telephony oriented from SIP and instant > messaging and presence capabilities from XMPP. This specification > does not define any new protocols or syntax for neither SIP nor XMPP. > However, implementing it may require modifying or at least > reconfiguring existing client and server-side software. Also, it is > not the purpose of this document to make recommendations as to > whether or not such combined us should be preferred to the mechanisms > provided natively by each protocol like for example SIP's SIMPLE or > XMPP's Jingle. It merely aims to provide guidance to those who are > interested in such a combined use. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ivov-xmpp-cusax-00.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > From stpeter@stpeter.im Tue Mar 6 15:09:16 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 398FB21E80EA for ; Tue, 6 Mar 2012 15:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.183, 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 BrRI0A1BflgD for ; Tue, 6 Mar 2012 15:09:15 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F021E805D for ; Tue, 6 Mar 2012 15:09:11 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6798640058; Tue, 6 Mar 2012 16:21:08 -0700 (MST) Message-ID: <4F569915.8060906@stpeter.im> Date: Tue, 06 Mar 2012 16:09:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Zeitz References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> In-Reply-To: <4F550E88.5010200@babelmonkeys.de> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart 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: Tue, 06 Mar 2012 23:09:16 -0000 On 3/5/12 12:05 PM, Florian Zeitz wrote: > Am 05.03.2012 17:45, schrieb Peter Saint-Andre: >> Discussion about a possible PRECIS profile for nicknames spilled over >> from the SIMPLE WG to the standards@xmpp.org list the other day. One >> issue that came up was possibly treating resourceparts in general as >> "absolute identifiers" (see draft-iab-identifier-comparison) and thus as >> subject merely to byte-for-byte comparison, not a full-blown PRECIS >> profile. This might simplify matters quite a bit. However, we would then >> define a PRECIS profile for nicknames, so that resourceparts as used in >> multi-user chat (XEP-0045) could be handled more intelligently. This >> approach makes quite a bit of sense to me, so I might collaborate with >> our friends in the SIMPLE WG on a PRECIS profile for nicknames (the >> decision about resourceparts is separate from that, but related). >> >> Peter >> > > Hello Peter, > > could you elaborate a bit on the "not a full-blown PRECIS profile" part. > I'd certainly hope we would still specify valid/disallowed code points. I think we can prohibit code points without defining a PRECIS profile (which requires that we specify a Unicode normalization form etc.). Whether we want to do that is another question. > My rational for this is that clients currently tend to display > resources. As such assuming all bytes are created equal might severely > break some client's interface and create a security threat for terminal > based clients (control characters). Yes, control characters are always a bad idea here. The fact that resourceparts are entered by some humans and displayed to other humans makes me think we probably want to use a PRECIS profile. Peter -- Peter Saint-Andre https://stpeter.im/ From florob@babelmonkeys.de Tue Mar 6 17:07:29 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 76F7621E803A for ; Tue, 6 Mar 2012 17:07:29 -0800 (PST) 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 S72YDF+2fSqE for ; Tue, 6 Mar 2012 17:07:28 -0800 (PST) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 9873B21E8011 for ; Tue, 6 Mar 2012 17:07:27 -0800 (PST) Received: from xdsl-78-34-97-92.netcologne.de ([78.34.97.92] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S55Le-0008K0-J4; Wed, 07 Mar 2012 02:07:22 +0100 Message-ID: <4F56B4C5.4010908@babelmonkeys.de> Date: Wed, 07 Mar 2012 02:07:17 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> <4F569915.8060906@stpeter.im> In-Reply-To: <4F569915.8060906@stpeter.im> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart 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, 07 Mar 2012 01:07:29 -0000 Am 07.03.2012 00:09, schrieb Peter Saint-Andre: > I think we can prohibit code points without defining a PRECIS profile > (which requires that we specify a Unicode normalization form etc.). > Whether we want to do that is another question. > I was assuming "None" would be a valid choice for a normalization form. But then again that might just be me trying to squeeze this into a PRECIS profile. > The fact that resourceparts are entered by some humans and displayed to > other humans makes me think we probably want to use a PRECIS profile. > Assuming you're implying we should specify some normalization, case mapping, etc. I think I agree. However, it might also be possible to get away without any of those and just let specific extensions/users further restrict the resource, as suggested for MUC nicknames. Florian From k.i.smith@gmail.com Tue Mar 6 23:59:16 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 E891F21E8095 for ; Tue, 6 Mar 2012 23:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 CaH9g2YE9Bhv for ; Tue, 6 Mar 2012 23:59:16 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7221E8091 for ; Tue, 6 Mar 2012 23:59:15 -0800 (PST) Received: by eaaq11 with SMTP id q11so2090149eaa.31 for ; Tue, 06 Mar 2012 23:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6qp12n7WU2Nt2TS9yo/i5ziSoB5pkbP0dfVnyg0cHy8=; b=tHOpjthZwT0tBbcLepdmp9TG1bYJjiaCI3G7QbGFXg49+DEuzi0qL0J9C5GkoxldUR zNyh71+CGXEtR6cVpkq7zwiqybfSexG4kgnvv/IGzpof1FLgN0xPtJV+/2tX4W+X0AFJ 70bMRvQ0Kc3DqLKdGsx1nh5s38R4iHVXlx91gOonYxv7kEryB3aEKBmWfXCoMtpZ00ul hIcxddDDRTrsUyofFCYp8Tg47uiVBKUZy3iT0xyKxHro4QE6isvOoJiDqk7cBW0E7B0l sPB7eV/e4d9PrkCpTfPOPfrnwf0qfzR/mLtjf05q223QjLetXniAhQClYGBj0e+psxtU Ponw== MIME-Version: 1.0 Received: by 10.213.28.66 with SMTP id l2mr265417ebc.8.1331107155283; Tue, 06 Mar 2012 23:59:15 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.213.10.208 with HTTP; Tue, 6 Mar 2012 23:59:15 -0800 (PST) In-Reply-To: <4F569915.8060906@stpeter.im> References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> <4F569915.8060906@stpeter.im> Date: Wed, 7 Mar 2012 07:59:15 +0000 X-Google-Sender-Auth: SKcBNC34cFq2l16wIYR1kLA29X4 Message-ID: From: Kevin Smith To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:59:17 -0000 On Tue, Mar 6, 2012 at 11:09 PM, Peter Saint-Andre wrote: > I think we can prohibit code points without defining a PRECIS profile > (which requires that we specify a Unicode normalization form etc.). > Whether we want to do that is another question. > The fact that resourceparts are entered by some humans and displayed to > other humans makes me think we probably want to use a PRECIS profile. I think that (apart from specific instances like MUCs), treating resources as a string of bytes seems sensible, with disallowed ranges. /K From stpeter@stpeter.im Wed Mar 7 05:22:18 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 C9E5221F87FF for ; Wed, 7 Mar 2012 05:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 JaYibzwao76g for ; Wed, 7 Mar 2012 05:22:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5F21F87FE for ; Wed, 7 Mar 2012 05:22:18 -0800 (PST) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C551C4005B; Wed, 7 Mar 2012 06:34:16 -0700 (MST) Message-ID: <4F5760F8.5050809@stpeter.im> Date: Wed, 07 Mar 2012 06:22:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Zeitz References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> <4F569915.8060906@stpeter.im> <4F56B4C5.4010908@babelmonkeys.de> In-Reply-To: <4F56B4C5.4010908@babelmonkeys.de> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart 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, 07 Mar 2012 13:22:18 -0000 On 3/6/12 6:07 PM, Florian Zeitz wrote: > Am 07.03.2012 00:09, schrieb Peter Saint-Andre: >> I think we can prohibit code points without defining a PRECIS profile >> (which requires that we specify a Unicode normalization form etc.). >> Whether we want to do that is another question. >> > I was assuming "None" would be a valid choice for a normalization form. Not an option. :) > But then again that might just be me trying to squeeze this into a > PRECIS profile. > >> The fact that resourceparts are entered by some humans and displayed to >> other humans makes me think we probably want to use a PRECIS profile. >> > Assuming you're implying we should specify some normalization, case > mapping, etc. I think I agree. > However, it might also be possible to get away without any of those and > just let specific extensions/users further restrict the resource, as > suggested for MUC nicknames. Yes, that's what Dave Cridland suggested. IMHO it makes sense, but we need to think through the implications. Peter -- Peter Saint-Andre https://stpeter.im/ From Kurt.Zeilenga@Isode.COM Wed Mar 7 06:40:41 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 CBC0B21F869D for ; Wed, 7 Mar 2012 06:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTe2LESWt26n for ; Wed, 7 Mar 2012 06:40:41 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9FB521F8678 for ; Wed, 7 Mar 2012 06:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1331131239; d=isode.com; s=selector; i=@isode.com; bh=K8QhN7lKllonGoZj3YKpjouV47gkl7DMpOy0pfWHueA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gyT6KfIRl0s1GeXLE0TyGXaUUYFeeJ/+5+HfXJeL8480d0bAPC6T+N8gmt4q2BUUs95OCw MQQhnm5NHV7Rjvnk9rCrqaUCRCfzOK/elfg6Z1SJgpjSFan8TqLoMxsfbxe1tm+bV5wIEZ UesVcPqEF9WErGqd5EzqJaOvtkPhayU=; Received: from pagan.boolean.net (66-214-104-34.dhcp.slto.ca.charter.com [66.214.104.34]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Mar 2012 14:40:39 +0000 From: Kurt Zeilenga In-Reply-To: Date: Wed, 7 Mar 2012 06:40:34 -0800 Message-Id: <91D5A914-E6E6-421B-8008-66D7EEB7A3DD@Isode.COM> References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> <4F569915.8060906@stpeter.im> To: kevin@kismith.co.uk X-Mailer: Apple Mail (2.1257) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart 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, 07 Mar 2012 14:40:41 -0000 On Mar 6, 2012, at 11:59 PM, Kevin Smith wrote: > On Tue, Mar 6, 2012 at 11:09 PM, Peter Saint-Andre = wrote: >> I think we can prohibit code points without defining a PRECIS profile >> (which requires that we specify a Unicode normalization form etc.). >> Whether we want to do that is another question. >> The fact that resourceparts are entered by some humans and displayed = to >> other humans makes me think we probably want to use a PRECIS profile. >=20 > I think that (apart from specific instances like MUCs), treating > resources as a string of bytes seems sensible, with disallowed ranges. I think it might be wise to consider various odd cases that might be = negatively impacted by the inability of an entity from re-creating a = resource through user input that matches that previously provided by a = client. Given there are cases where it desirable for a user to establish a = specific resource for a particular client, it somewhat follows that a = user might want to setup a different client to use that same resource at = some point in time. For instance, when switching clients used on their = desktop, they might want their new client to have the same (equivalent) = resource name to their old client. If there are inadequate rules in = the preparation of user input to the resource for comparison, the user = might not be able to create an equivalent resource name on their new = client. Now, we might decide this is not a big deal, and hence go with a very = simple set of rules for the resource part. But I think before we do so, = we should think through it. Off hand, I would think that comparing of resource parts should not be = done octet-wise (in the UTF-8 encoding), but that we should minimally = require Unicode normalization (on input to the wire or at time of = comparison). -- Kurt= From stpeter@stpeter.im Wed Mar 7 08:28: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 61A0621F8646 for ; Wed, 7 Mar 2012 08:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 Ze2JPNsY2976 for ; Wed, 7 Mar 2012 08:28:43 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84B9921F8645 for ; Wed, 7 Mar 2012 08:28:43 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D23794005B; Wed, 7 Mar 2012 09:40:42 -0700 (MST) Message-ID: <4F578CBA.2010103@stpeter.im> Date: Wed, 07 Mar 2012 09:28:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> <4F55EE40.8000205@jitsi.org> In-Reply-To: <4F55EE40.8000205@jitsi.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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, 07 Mar 2012 16:28:44 -0000 Hi Emil! On 3/6/12 4:00 AM, Emil Ivov wrote: > Thanks for the note, Peter! > > All, the draft addresses a problem that has been raised and discussed on > multiple occasions (including the SIXPAC effort from about a year ago). > The point of this approach is to simply put forward common practices > that people are resorting to in order to combine strengths of SIP and > XMPP implementations. > > This is a very preliminary version that we've submitted in order to > gauge interest, get initial feedback on open issues and the approach > itself (and the fact that it was submitted a couple of hours before 00 > cutoff is of course purely coincidental). > > What we'd like to hear at this time is whether people think such a > document would make sense I think so. At the same time, it would be worth looking again at the various other solutions and mechanisms that have been suggested over the years, such as: http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt http://tools.ietf.org/id/draft-saintandre-sip-xmpp-presence-02.txt http://tools.ietf.org/id/draft-saintandre-sip-xmpp-im-01.txt http://tools.ietf.org/id/draft-saintandre-sip-xmpp-chat-03.txt http://tools.ietf.org/id/draft-saintandre-sip-xmpp-groupchat-01.txt http://tools.ietf.org/id/draft-saintandre-sip-xmpp-media-01.txt http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt http://xmpp.org/extensions/xep-0152.html > and also: > > * currently the document only vaguely mentions client provisioning. Does > anyone think we should make this more specific and possibly quote some > existing mechanisms? I see no harm in mentioning existing techniques. > * During the SIXPAC effort it was suggested that clients could log onto > a SIP service and use the domain parameter in digest authentication to > discover the XMPP domain. Does anyone think this would make sense? That sounds confusing to me -- better, I think, to use the existing methods for discovering your XMPP server. > * Currently the draft suggests a couple of alternatives for determining > an XMPP identity from an incoming SIP request. One consists in searching > the roster for an entry whose VCARD contains the source URI (but that > only works if the caller is already in our roster). The other one would > be to add a second contact header to outgoing INVITEs and put an xmpp > uri in there corresponding to the caller's JID. Any thoughts on this? One objection to a SIP header for an alterative contact method was that it might be stripped out by intermediaries such as B2BUAs. I happen to think we might need to experiment with several approaches -- the vCard entries you mention, a second SIP header containing a JID, an XMPP extension containing a SIP address as in XEP-0152 -- to see what works. Peter -- Peter Saint-Andre https://stpeter.im/ From mwild1@gmail.com Wed Mar 7 08:42: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 0241C21F86C7 for ; Wed, 7 Mar 2012 08:42:37 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 YqlWdWake98R for ; Wed, 7 Mar 2012 08:42:36 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBB21F84BD for ; Wed, 7 Mar 2012 08:42:36 -0800 (PST) Received: by iazz13 with SMTP id z13so10308491iaz.31 for ; Wed, 07 Mar 2012 08:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9WQE30JvnjvVB3/8Qz8W2+ORy7v9PqfStCrIBr0tksc=; b=CdLPy/BJtZcBnML0oIuxY3dbeEhQXuJRTDaMYEBXHV5a+NTFZdefQvx3wlDzbT7sfb 38RkzZOf8UQKFC/Sv2Ad41el/CdTOBwt53yID1ZUeY193zWYEWMTgfSQUHYBWZKvzsVq /bdDbzd6OBfLIwnwhtuSVlx1lL4fyNZNvutDGfUYclYKOHFzHX/hBL5bwLzGoFCfr8Ql h5+Y7JtG7iAUR1CFMwqtSf0gUvDjC70IO1aH7cmpwr7pvfaf7yxftCwxR79wLERpbUVp 1mWUOO3egWIqJFUZWXSpcbJJe5HmLTJ2bxXc/VfY69xh8FrWnn2dFnKLwmpeDXLjhvC+ 6fEg== Received: by 10.42.138.9 with SMTP id a9mr1789512icu.14.1331138556041; Wed, 07 Mar 2012 08:42:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.199.130 with HTTP; Wed, 7 Mar 2012 08:42:15 -0800 (PST) In-Reply-To: <91D5A914-E6E6-421B-8008-66D7EEB7A3DD@Isode.COM> References: <4F54EDA9.5090300@stpeter.im> <4F550E88.5010200@babelmonkeys.de> <4F569915.8060906@stpeter.im> <91D5A914-E6E6-421B-8008-66D7EEB7A3DD@Isode.COM> From: Matthew Wild Date: Wed, 7 Mar 2012 16:42:15 +0000 Message-ID: To: Kurt Zeilenga Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: resourcepart 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, 07 Mar 2012 16:42:37 -0000 On 7 March 2012 14:40, Kurt Zeilenga wrote: > > On Mar 6, 2012, at 11:59 PM, Kevin Smith wrote: > >> On Tue, Mar 6, 2012 at 11:09 PM, Peter Saint-Andre = wrote: >>> I think we can prohibit code points without defining a PRECIS profile >>> (which requires that we specify a Unicode normalization form etc.). >>> Whether we want to do that is another question. >>> The fact that resourceparts are entered by some humans and displayed to >>> other humans makes me think we probably want to use a PRECIS profile. >> >> I think that (apart from specific instances like MUCs), treating >> resources as a string of bytes seems sensible, with disallowed ranges. > > I think it might be wise to consider various odd cases that might be nega= tively impacted by the inability of an entity from re-creating a resource t= hrough user input that matches that previously provided by a client. > > Given there are cases where it desirable for a user to establish a specif= ic resource for a particular client, it somewhat follows that a user might = want to setup a different client to use that same resource at some point in= time. =C2=A0For instance, when switching clients used on their desktop, th= ey might want their new client to have the same (equivalent) resource name = to their old client. =C2=A0 If there are inadequate rules in the preparatio= n of user input to the resource for comparison, the user might not be able = to create an equivalent resource name on their new client. > I'm much less convinced nowadays that resources should be anywhere near users than I used to be. I think a user entering a resource string (of a contact) is rather rare. We did have a discussion about this in the Prosody room the other day. The main use-case that came up was a server admin dealing with connected users via their full JID (whether communicating with them or disconnecting them, etc.). Also note that servers are able to enforce their own policies about resources. Interop mainly becomes a problem at the s2s level then, where one server may be more relaxed than another about accepting "unusual" resource strings. > Off hand, I would think that comparing of resource parts should not be do= ne octet-wise (in the UTF-8 encoding), but that we should minimally require= Unicode normalization (on input to the wire or at time of comparison). > That does seem sensible. Regards, Matthew From emil@sip-communicator.org Wed Mar 7 09:35:49 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 7745821F872A for ; Wed, 7 Mar 2012 09:35:49 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 dhVmTuMdWxQP for ; Wed, 7 Mar 2012 09:35:48 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA021F8725 for ; Wed, 7 Mar 2012 09:35:47 -0800 (PST) Received: by eeke51 with SMTP id e51so2418460eek.31 for ; Wed, 07 Mar 2012 09:35:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=DICY/J12Zs0LKaNQ/gdQbTFgXKO2fP9ZssV99nH7v18=; b=C8tTDKO0SnmvWU3+2KsX5puUIeUz9Ww7MS6f71+K7QdLl1fE0+HFk9Xu1LAovxbSJR tHx+HaItZS7RmEk/IESJjRU4UsToyLaUNNhE/FDjaj+s5N3zRwb5YuDJZyiZI3qiY5BJ eMoQWUEbMlNkfw/Uepkxzs2CdBQlEm41uVfRWorY2akSLdJIeIEJytOxtfRCncMPfyOr oZorYYHqcPxsjme3srycGPkYbXRW16xhcvGZ+wtKQlPRV7WEykSY6vuG2PCg9wXGY+4I /Ke0HmLcY2LRsArB9l1CG+m/trx2kLAhVcO9d8nKGfQjgAHr8NG9ZntVQnSL8cPaGj5u VklQ== Received: by 10.213.12.194 with SMTP id y2mr739753eby.60.1331141746865; Wed, 07 Mar 2012 09:35:46 -0800 (PST) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id n55sm49373801eef.6.2012.03.07.09.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 09:35:44 -0800 (PST) Message-ID: <4F579C6E.4070803@jitsi.org> Date: Wed, 07 Mar 2012 19:35:42 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Peter Saint-Andre References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> <4F55EE40.8000205@jitsi.org> <4F578CBA.2010103@stpeter.im> In-Reply-To: <4F578CBA.2010103@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnlbeHXBQGMst2ejDEzCRO5+IxMsOOjAD6LON1/axpFe1Ksa/i1Tm+uRwkRTkXdQlug2xqh Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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, 07 Mar 2012 17:35:49 -0000 Hey Peter, Thanks for your feedback! (inline) On 07.03.12 18:28, Peter Saint-Andre wrote: > Hi Emil! > > On 3/6/12 4:00 AM, Emil Ivov wrote: >> Thanks for the note, Peter! >> >> All, the draft addresses a problem that has been raised and discussed on >> multiple occasions (including the SIXPAC effort from about a year ago). >> The point of this approach is to simply put forward common practices >> that people are resorting to in order to combine strengths of SIP and >> XMPP implementations. >> >> This is a very preliminary version that we've submitted in order to >> gauge interest, get initial feedback on open issues and the approach >> itself (and the fact that it was submitted a couple of hours before 00 >> cutoff is of course purely coincidental). >> >> What we'd like to hear at this time is whether people think such a >> document would make sense > > I think so. At the same time, it would be worth looking again at the > various other solutions and mechanisms that have been suggested over the > years, such as: > > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-core-01.txt > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-presence-02.txt > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-im-01.txt > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-chat-03.txt > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-groupchat-01.txt > http://tools.ietf.org/id/draft-saintandre-sip-xmpp-media-01.txt Agreed. We should definitely mention those and maybe explain why they address different goals than what we have with CUSAX. Something along the lines of achieving coexistance with minimum to no implementation changes and mostly as a temporary measure until most of the features people are looking for are found in either XMPP only or SIP only implementations (knowing that such features could also be provided by sip-xmpp gateways). > http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt > http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt What we are trying with CUSAX is actually quite similar to the above and what was attempted with the SIXPACK WG ... we just try to keep it a lot simpler. We would like to avoid standardizing any new stuff (especially SIP headers). We just wanted to describe what we find to be the best practices that people are doing in cases when they need such co-existance. That's why we'd like to keep the document as info or bcp. > http://xmpp.org/extensions/xep-0152.html Thanks for this one! It would definitely be very useful! >> and also: >> >> * currently the document only vaguely mentions client provisioning. Does >> anyone think we should make this more specific and possibly quote some >> existing mechanisms? > > I see no harm in mentioning existing techniques. > >> * During the SIXPAC effort it was suggested that clients could log onto >> a SIP service and use the domain parameter in digest authentication to >> discover the XMPP domain. Does anyone think this would make sense? > > That sounds confusing to me -- better, I think, to use the existing > methods for discovering your XMPP server. Noted. We'd also prefer to avoid it but we thought we'd ask just the same. >> * Currently the draft suggests a couple of alternatives for determining >> an XMPP identity from an incoming SIP request. One consists in searching >> the roster for an entry whose VCARD contains the source URI (but that >> only works if the caller is already in our roster). The other one would >> be to add a second contact header to outgoing INVITEs and put an xmpp >> uri in there corresponding to the caller's JID. Any thoughts on this? > > One objection to a SIP header for an alterative contact method was that > it might be stripped out by intermediaries such as B2BUAs. Yup that could indeed happen quite often. > I happen to > think we might need to experiment with several approaches -- the vCard > entries you mention, a second SIP header containing a JID, Or we could advise using both in a best effort way. That is, look for a second contact, but if you don't find it in incoming INVITEs, then just look through the VCARDs in your roster and declare the caller as unknown if nothing appears. > an XMPP > extension containing a SIP address as in XEP-0152 -- to see what works. Right, this one could be useful for the opposite direction, in case there's nothing in the VCARD we got from our XMPP server. Cheers, Emil -- http://jitsi.org From stpeter@stpeter.im Wed Mar 7 10:03:26 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 1A78B21F84CE for ; Wed, 7 Mar 2012 10:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.689 X-Spam-Level: X-Spam-Status: No, score=-102.689 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 m0Ocw5-78eSl for ; Wed, 7 Mar 2012 10:03:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6121F84CD for ; Wed, 7 Mar 2012 10:03:25 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B1FE74005B; Wed, 7 Mar 2012 11:15:24 -0700 (MST) Message-ID: <4F57A2EA.8040102@stpeter.im> Date: Wed, 07 Mar 2012 11:03:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> <4F55EE40.8000205@jitsi.org> <4F578CBA.2010103@stpeter.im> <4F579C6E.4070803@jitsi.org> In-Reply-To: <4F579C6E.4070803@jitsi.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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, 07 Mar 2012 18:03:26 -0000 On 3/7/12 10:35 AM, Emil Ivov wrote: > > On 07.03.12 18:28, Peter Saint-Andre wrote: >> >> On 3/6/12 4:00 AM, Emil Ivov wrote: >> >> http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt >> http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt > > What we are trying with CUSAX is actually quite similar to the above and > what was attempted with the SIXPACK WG ... we just try to keep it a lot > simpler. We would like to avoid standardizing any new stuff (especially > SIP headers). I asked about SIP headers specifically because your I-D says: An alternate mechanism would be for CUSAX clients to add to their SIP invite requests a contact header containing their XMPP JID, but at this point we are not really sure if that's ' such a good idea. (After all Contact headers carry URIs and JIDs are not URIs). There is a URI scheme for XMPP: http://tools.ietf.org/html/rfc5122 However, if you mean the SIP Contact header, then that appears to be restricted to SIP/SIPS URIs (RFC 3361, Section 8.1.1.8): The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. However, Section 20.10 of RFC 3261 doesn't restrict Contact headers to SIP/SIPS URIs (and includes an example of a 'mailto' URI): http://tools.ietf.org/html/rfc3261#section-20.10 If a SIP INVITE is allowed to contain a Contact header that includes an XMPP URI (apparently in addition to "exactly one SIP or SIPS URI"), then that seems to be one way to advertise a JID on the SIP side of the equation. On the XMPP side, we could use XEP-0152. And in the vCard we could include both an XMPP URI (in vCard4, via the element) and a SIP URI (via the element). IMHO that would provide pretty good coverage. Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Wed Mar 7 10:45:32 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 7F8FE11E8075 for ; Wed, 7 Mar 2012 10:45:32 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jhiy7tp4OfI8 for ; Wed, 7 Mar 2012 10:45:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65111E8072 for ; Wed, 7 Mar 2012 10:45:31 -0800 (PST) Received: by eeke51 with SMTP id e51so2441030eek.31 for ; Wed, 07 Mar 2012 10:45:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=GUUC1EEEcAC6+gzllQm5AlP/Nang0u/iB4L5O51Clog=; b=juNh9lY347cipP9ISCoIAesFmcos253tCj/eO+fUYEi5i2FsR24In4sWJLz7Hpq+Gq HG6NHPOC0nDys4h/yPDhA1f2pJ6Pfp0KQKvmTDygQ3Q9LoeFBYySUkVjVRQftGI1uswa Z1kBgNvYg29uAdVvN3zMpoPOp+vYeHXp7vLgOI82a2I3FJq8PdnLxiV2wpIu4Ou0lTzQ 2dgxe0C81YvYhVUzwaZT4Wte3hNgm9tYl5IhB9tKHbXQVGfVSqEXmHmoE4hh/ydeCfRQ RTt3XWMrJ94YX9Y7Bp38NxQ+eLZMEkkKLl3Sd7DaiZXrapvstbEKfHECNvgATSLyqrvF y9Tg== Received: by 10.213.7.6 with SMTP id b6mr791939ebb.248.1331145930394; Wed, 07 Mar 2012 10:45:30 -0800 (PST) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id z47sm64191976een.5.2012.03.07.10.45.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 10:45:29 -0800 (PST) Message-ID: <4F57ACC6.90207@jitsi.org> Date: Wed, 07 Mar 2012 20:45:26 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Peter Saint-Andre References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> <4F55EE40.8000205@jitsi.org> <4F578CBA.2010103@stpeter.im> <4F579C6E.4070803@jitsi.org> <4F57A2EA.8040102@stpeter.im> In-Reply-To: <4F57A2EA.8040102@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmWeUHPyQBjTqC6QLm5oS+Tqm9t70ZSx7/NRhe8Dbch4DSB0CWdYCZBFtB56sTlKDY9Lx/4 Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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, 07 Mar 2012 18:45:32 -0000 Hey Peter, On 07.03.12 20:03, Peter Saint-Andre wrote: > On 3/7/12 10:35 AM, Emil Ivov wrote: >> >> On 07.03.12 18:28, Peter Saint-Andre wrote: >>> >>> On 3/6/12 4:00 AM, Emil Ivov wrote: >>> >>> http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt >>> http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt >> >> What we are trying with CUSAX is actually quite similar to the above and >> what was attempted with the SIXPACK WG ... we just try to keep it a lot >> simpler. We would like to avoid standardizing any new stuff (especially >> SIP headers). > > I asked about SIP headers specifically because your I-D says: > > An alternate mechanism would be for CUSAX clients to add to their SIP > invite requests a contact header containing their XMPP JID, but at > this point we are not really sure if that's ' such a good idea. > (After all Contact headers carry URIs and JIDs are not URIs). > > There is a URI scheme for XMPP: > > http://tools.ietf.org/html/rfc5122 Yes, that's what we had in mind. > > However, if you mean the SIP Contact header, That was the idea, yes. We wanted to reuse the Contact header and hence avoid the need for standardizing a new one. > then that appears to be > restricted to SIP/SIPS URIs (RFC 3361, Section 8.1.1.8): That was supposed to say "3261", right? > The Contact header field provides a SIP or SIPS URI that can be used > to contact that specific instance of the UA for subsequent requests. > The Contact header field MUST be present and contain exactly one SIP > or SIPS URI in any request that can result in the establishment of a > dialog. For the methods defined in this specification, that includes > only the INVITE request. Well, I read that as a requirement of the presence of (at least one) Contact header with exactly one SIP/SIPS URI, rather than a prohibition of secondary contact headers. I agree the text is somewhat ambiguous though so I might be missing the point. FWIW 3261 does contain examples with non-SIP URI(L)s in Contact, like the 200 OK in 11.2 that has: Contact: Contact: > However, Section 20.10 of RFC 3261 doesn't restrict Contact headers to > SIP/SIPS URIs (and includes an example of a 'mailto' URI): > > http://tools.ietf.org/html/rfc3261#section-20.10 There's that too, yes. > If a SIP INVITE is allowed to contain a Contact header that includes an > XMPP URI (apparently in addition to "exactly one SIP or SIPS URI"), then > that seems to be one way to advertise a JID on the SIP side of the > equation. On the XMPP side, we could use XEP-0152. And in the vCard we > could include both an XMPP URI (in vCard4, via the element) and > a SIP URI (via the element). IMHO that would provide pretty good > coverage. Agreed. Do we actually even need to add an XMPP uri in the VCARD provided that we are retrieving it for an entry in our XMPP roster? Or am I missing something? Emil -- http://jitsi.org From stpeter@stpeter.im Wed Mar 7 10:49:32 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 1270F11E8075 for ; Wed, 7 Mar 2012 10:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 b7Myul00geSw for ; Wed, 7 Mar 2012 10:49:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC911E8072 for ; Wed, 7 Mar 2012 10:49:31 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEDA64005B; Wed, 7 Mar 2012 12:01:30 -0700 (MST) Message-ID: <4F57ADB9.900@stpeter.im> Date: Wed, 07 Mar 2012 11:49:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Emil Ivov References: <20120305201824.24744.10949.idtracker@ietfa.amsl.com> <4F552E2F.80302@stpeter.im> <4F55EE40.8000205@jitsi.org> <4F578CBA.2010103@stpeter.im> <4F579C6E.4070803@jitsi.org> <4F57A2EA.8040102@stpeter.im> <4F57ACC6.90207@jitsi.org> In-Reply-To: <4F57ACC6.90207@jitsi.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ivov-xmpp-cusax-00.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, 07 Mar 2012 18:49:32 -0000 On 3/7/12 11:45 AM, Emil Ivov wrote: > Hey Peter, > > On 07.03.12 20:03, Peter Saint-Andre wrote: >> On 3/7/12 10:35 AM, Emil Ivov wrote: >>> >>> On 07.03.12 18:28, Peter Saint-Andre wrote: >>>> >>>> On 3/6/12 4:00 AM, Emil Ivov wrote: >>>> >>>> http://tools.ietf.org/id/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt >>>> http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt >>> >>> What we are trying with CUSAX is actually quite similar to the above and >>> what was attempted with the SIXPACK WG ... we just try to keep it a lot >>> simpler. We would like to avoid standardizing any new stuff (especially >>> SIP headers). >> >> I asked about SIP headers specifically because your I-D says: >> >> An alternate mechanism would be for CUSAX clients to add to their SIP >> invite requests a contact header containing their XMPP JID, but at >> this point we are not really sure if that's ' such a good idea. >> (After all Contact headers carry URIs and JIDs are not URIs). >> >> There is a URI scheme for XMPP: >> >> http://tools.ietf.org/html/rfc5122 > > Yes, that's what we had in mind. >> >> However, if you mean the SIP Contact header, > > That was the idea, yes. We wanted to reuse the Contact header and hence > avoid the need for standardizing a new one. I like that approach. >> then that appears to be >> restricted to SIP/SIPS URIs (RFC 3361, Section 8.1.1.8): > > That was supposed to say "3261", right? Yep. >> The Contact header field provides a SIP or SIPS URI that can be used >> to contact that specific instance of the UA for subsequent requests. >> The Contact header field MUST be present and contain exactly one SIP >> or SIPS URI in any request that can result in the establishment of a >> dialog. For the methods defined in this specification, that includes >> only the INVITE request. > > Well, I read that as a requirement of the presence of (at least one) > Contact header with exactly one SIP/SIPS URI, rather than a prohibition > of secondary contact headers. I agree the text is somewhat ambiguous > though so I might be missing the point. > > FWIW 3261 does contain examples with non-SIP URI(L)s in Contact, like > the 200 OK in 11.2 that has: > > Contact: > Contact: > >> However, Section 20.10 of RFC 3261 doesn't restrict Contact headers to >> SIP/SIPS URIs (and includes an example of a 'mailto' URI): >> >> http://tools.ietf.org/html/rfc3261#section-20.10 > > There's that too, yes. > >> If a SIP INVITE is allowed to contain a Contact header that includes an >> XMPP URI (apparently in addition to "exactly one SIP or SIPS URI"), then >> that seems to be one way to advertise a JID on the SIP side of the >> equation. On the XMPP side, we could use XEP-0152. And in the vCard we >> could include both an XMPP URI (in vCard4, via the element) and >> a SIP URI (via the element). IMHO that would provide pretty good >> coverage. > > Agreed. Do we actually even need to add an XMPP uri in the VCARD > provided that we are retrieving it for an entry in our XMPP roster? Or > am I missing something? Well, if you share the vCard with anyone who's not on XMPP, then it's good to have your JID in there for the sake of completeness. But you're right that in the context you're discussing, it's not necessary. Peter -- Peter Saint-Andre https://stpeter.im/ From ben@nostrum.com Wed Mar 14 07:18:45 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 49CAA21F86A4 for ; Wed, 14 Mar 2012 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, 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 HtA3A4g-QE72 for ; Wed, 14 Mar 2012 07:18:44 -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 BACC721F8656 for ; Wed, 14 Mar 2012 07:18:44 -0700 (PDT) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2EEIhjD061423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 09:18:44 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 09:18:46 -0500 Message-Id: To: XMPP Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [xmpp] Draft XMPP Agenda for IETF83 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, 14 Mar 2012 14:18:45 -0000 Hi, Here's the draft XMPP meeting agenda for IETF83. We're currently = scheduled for Wednesday afternoon at 1510. Please send any suggested = changes to the XMPP list as soon as possible. Thanks! Ben. ----------------------------------- XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 -- Status and Agenda Bashing -- 5 min (Chairs) -- End to End Encryption (Matt Miller) -- 20 min =09 htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 -- Domain Name Assertions (Matt MIller) -- 15 min =09 List Discussion,=20 http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 -- Internationalization Issues (Peter St. Andre) -- 15 min http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 If time permits: -- Combining XMPP and SIP ( Emil Ivov ) - 5 min =09 http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00 -- Open Discussion -- Any remaining time and energy= From stpeter@stpeter.im Wed Mar 14 08:15:21 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 0DCB621F87E9 for ; Wed, 14 Mar 2012 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 lgD2fMo1NuS7 for ; Wed, 14 Mar 2012 08:15:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE821F87BE for ; Wed, 14 Mar 2012 08:15:19 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A2E5040058; Wed, 14 Mar 2012 09:27:41 -0600 (MDT) Message-ID: <4F60B606.1020302@stpeter.im> Date: Wed, 14 Mar 2012 09:15:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Group Subject: [xmpp] i18n topic (was: Re: Draft XMPP Agenda for IETF83) 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, 14 Mar 2012 15:15:21 -0000 On 3/14/12 8:18 AM, Ben Campbell wrote: > -- Internationalization Issues (Peter St. Andre) -- 15 min > > http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 > http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 The main topic I'd like to discuss in person is this: do we really need a PRECIS profile for resourceparts, or can we just do byte-for-byte comparison in general and then define PRECIS profiles for specific applications that use resourceparts (such as the nickname profile for chatroom nicks)? Peter -- Peter Saint-Andre https://stpeter.im/ From ogashiwa@c.kyoai.ac.jp Wed Mar 14 09:12: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 610CD21F876C for ; Wed, 14 Mar 2012 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 tsG-cdgOMF6C for ; Wed, 14 Mar 2012 09:12:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A331921F8754 for ; Wed, 14 Mar 2012 09:12:08 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2556046vcb.31 for ; Wed, 14 Mar 2012 09:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=mHOfid2ATsquT/2fgCfjkzwPWPw05WUFaeVhdNAdEyw=; b=B01EUO2SDHehDX3aQimijS8/Cy6tDU5y7sU6jaTGUvHPPyOrzTBhhZD7F8TbeMVwBx FTRSv65PudY35XDZvpPaWuwWDtZTfW85p8o9suIe5Jl64EdAZoAZ0b55j4Je30GiAKv6 zcVBH2jD443rUf1twRwato4/fI70O/Kbd25tUy682cpORyyqD3GJd7G/Sh1JYY7qk0Fm vMPwsVJBERnAQurZQVrP5u2EkpFFTH61jDPJyXL3CqESN2/iIgP2RkJbpzLUh8DBSsj6 cZkH+tzGHA1czOrMRmDB1jbg188egCLcgozEQkBqPR3oH9PNda4kclmyGDOL9erG4Tw3 Axjw== MIME-Version: 1.0 Received: by 10.52.99.169 with SMTP id er9mr2243531vdb.126.1331741527831; Wed, 14 Mar 2012 09:12:07 -0700 (PDT) Received: by 10.52.90.41 with HTTP; Wed, 14 Mar 2012 09:12:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 01:12:07 +0900 Message-ID: From: Nobuo Ogashiwa To: Ben Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlWv0DQva7dYvUEnLE0wufZEw2un1IJ8g/2ti+0TqTt6bT61RGSZEPKtZ1Qc+O5ZTHQJQW6 Cc: XMPP Group Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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, 14 Mar 2012 16:12:09 -0000 Dear Ben, We have submitted an internet-draft: http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 Can we have a 5-10 minute slot to discuss this draft? If we have a presentation slot, Akari Harada will take care of a presentati= on. Regards, Nobuo Ogashiwa 2012/3/14 Ben Campbell : > Hi, > > Here's the draft XMPP meeting agenda for IETF83. We're currently schedule= d for Wednesday afternoon at 1510. Please send any suggested changes to the= XMPP list as soon as possible. > > Thanks! > > Ben. > > ----------------------------------- > > XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 > > -- Status and Agenda Bashing -- 5 min (Chairs) > > -- End to End Encryption (Matt Miller) -- 20 min > > =A0 =A0 =A0 =A0htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 > > -- Domain Name Assertions (Matt MIller) -- 15 min > > =A0 =A0 =A0 =A0List Discussion, > =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 > > -- Internationalization Issues (Peter St. Andre) -- =A015 min > > =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-0= 1 > =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-saintandre-precis-nicknam= e-00 > > If time permits: > > -- Combining XMPP and SIP ( Emil Ivov ) - 5 min > > =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00 > > -- Open Discussion -- Any remaining time and energy > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From ralphm@ik.nu Wed Mar 14 09:38:16 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 D59E821F8821 for ; Wed, 14 Mar 2012 09:38:16 -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 ck2-7sjqGVF2 for ; Wed, 14 Mar 2012 09:38:16 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) by ietfa.amsl.com (Postfix) with ESMTP id 28EFF21F8820 for ; Wed, 14 Mar 2012 09:38:16 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 48F7DA1045 for ; Wed, 14 Mar 2012 17:38:13 +0100 (CET) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id CWch25jIF2Df for ; Wed, 14 Mar 2012 17:38:12 +0100 (CET) Received: from dool.local (s53751670.adsl.wanadoo.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id 2AD5EA1047 for ; Wed, 14 Mar 2012 17:38:12 +0100 (CET) Message-ID: <4F60C972.6000406@ik.nu> Date: Wed, 14 Mar 2012 17:38:10 +0100 From: Ralph Meijer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: <4F60B606.1020302@stpeter.im> In-Reply-To: <4F60B606.1020302@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] i18n topic 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, 14 Mar 2012 16:38:16 -0000 On 2012-03-14 16:15 , Peter Saint-Andre wrote: > On 3/14/12 8:18 AM, Ben Campbell wrote: > >> -- Internationalization Issues (Peter St. Andre) -- 15 min >> >> http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 >> http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 > > The main topic I'd like to discuss in person is this: do we really need > a PRECIS profile for resourceparts, or can we just do byte-for-byte > comparison in general and then define PRECIS profiles for specific > applications that use resourceparts (such as the nickname profile for > chatroom nicks)? I'm not sure if we need a full-blown PRECIS profile for resourceparts in general, but I do think that byte-for-byte comparison is problematic. XML handling libraries typically deal with objects representing strings of codepoints, not the string of bytes sent over the wire. Codepoint-for-codepoint comparison is probably the reasonable minimum. -- ralphm From mamille2@cisco.com Wed Mar 14 11:46: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 1E65021F87E9 for ; Wed, 14 Mar 2012 11:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.69 X-Spam-Level: X-Spam-Status: No, score=-8.69 tagged_above=-999 required=5 tests=[AWL=1.309, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] 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 5BQi8eAa3PJ3 for ; Wed, 14 Mar 2012 11:46:02 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80921F8540 for ; Wed, 14 Mar 2012 11:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=7046; q=dns/txt; s=iport; t=1331750762; x=1332960362; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Lae+MbtMLjjwGyb9a2leCy+e4HFaBYDW9OPSykx9uSE=; b=Bk8sKU72F3Tjt2DwBLgZ3iURxqSJyvrwKPZpksQo1ie7SxjSmBu68y9m 8F/TEos8j9aHdJjcXdhgRhyHiRPXMLDOmz4x/cck2Rsr+CfRF9mZnXzNK QZuWc6OA0XhqGjtGje0DwGb36kR1Lv+Jqz8PydBbvArat1ReSYhYNXR5y A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJbmYE+rRDoI/2dsb2JhbABDti2BB4IJAQEBAwESASc/BQsLGCcHRhEGExsHh2MEAZtcny6QG2MEiFeJTIMzjkCBaIMFgTUCFAM X-IronPort-AV: E=Sophos;i="4.73,585,1325462400"; d="scan'208";a="36138855" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Mar 2012 18:46:00 +0000 Received: from dhcp-64-101-72-155.cisco.com (dhcp-64-101-72-155.cisco.com [64.101.72.155]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EIk0BQ029890; Wed, 14 Mar 2012 18:46:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <9470.1330707832.760127@puncture> Date: Wed, 14 Mar 2012 12:45:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> <9470.1330707832.760127@puncture> To: Dave Cridland X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Working Group Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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, 14 Mar 2012 18:46:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you for this feedback. So far, I'm hearing a lot if favor of out-of-band validation, and = little-to-none in favor of in-band. Whether it's DANE or = HTTPS/.well-known or something else is mostly irrelevant. It's = effectively happening within the software's "TLS support" (for various = definitions of "TLS support"). I also met with Peter Saint-Andre about this, and we came to a similar = conclusion regarding validation. Questions that arose: - - do we need a way to signal a preferred prooftype (probably not?) - - order of operations (SRV, TLS, DANE, HTTPS/.well-known) matter? - - how long to suspend disbelief on TLS? (interactions with existing = software) It looks like we need to codify the HTTPS/.well-known and/or DANE = validation processes; and to formalize d-w-d, presumably starting with = draft-ietf-xmpp-dna-01. - - m&m Matt Miller - Cisco Systems, Inc. 03, Dave Cridland wrote: > On Fri Jan 27 20:05:22 2012, Matt Miller wrote: >> To restate the problem: How to determine that a multi-domain hosting = service is authorized for a given domain, in a manner that allows = connections to a hosting service be shared for multiple domains. > You need to ensure you've additionally added in piggybacking (Or = stream multiplexing, or whatever we call this now) - or at the very = least not prevented it. >=20 > This changes the scenery rather a lot. >=20 >> I think this can (should?) also apply to the users at a domain; how = does romeo@montegue.lit know that the servers for shakespeare.lit hosts = his domain. >=20 > Mmmmm.... Kind of. >=20 > Yes, users need to authenticate and authorize their servers. >=20 > But the thing is, users never need to piggyback target domains, and = additionally, for users, they've typically got mutual authentication via = SASL. >=20 > Finally, we can cheat a bit and lessen the need for signalling - if we = do this - so the authorizing agent can handle the entire authorization = process without any support from the authorizee - then it saves us aIn = fact, I'm not even convinced we ever need signalling, aside from the = fact people will march on me with flaming pitchforks if I suggest that. = But since I've just had a new moat put in at Castle Cridland, and the = drawbridge is properly oiled... >=20 >> There are a couple prooftypes that have been discussed (on- or = off-list) so far, plus some other avenues that can be investigated: >> * .well-known from HTTPS >> * attribute certificates >> * DANE >> * "dialback without dialback"[1] >=20 > OK. ".well-known from HTTPS", and "attribute certificates" (and = signed-blobs-of-XML) are all equivalents. >=20 > d-w-d on the other hand is a hunk of protocol for declaring a need to = authenticate. >=20 > Let me put up a concrete proposal: >=20 > Our authorization proof is going to consist of a copy of the hosting = certificate held at the domain owner's HTTPS site at = .well-known/authorization/hosted-domain/_tcp/_xmpp-server/certificate.crti= n DER (ie, not PEM). I'm going to call this protocol TurboHalibut. >=20 > The details don't really matter that much. >=20 > The name *absolutely* does. >=20 > So, for hamlet@demark.lit, connecting to his server is business as = usual, since it's self hosted. >=20 > For juliet@capulet.lit, on the other hand, things are a bit different. = The certificate she gets from connecting normally doesn't match. At this = point, traditional wisdom is for her to disconnect with an error. In = practise, what actually happens is that Juliet's client will ask Juliet = if she wants to ignore years of careful security analysis and just = continue anyway. >=20 > But with TurboHalibut, her client can now take the additional step of = connecting to the HTTPS site https://capulet.lit, checking *that* = certificate against capulet.lit, and then checking the certificate held = in TurboHalibut is the same one it's got from the XMPP service. >=20 > Look, mom, no signalling - shakespeare.lit doesn't need to support any = new protocol for this use-case, because it's all been handled out of = band. Juliet's client, though, does need to implement TurboHalibut. >=20 > So Hamlet decides to send a message to Juliet. >=20 > denmark.lit connects to shakespeare.lit, and sees the wrong = certificate - but denmark.lit can verify it in exactly the same way. = Again, shakespeare.lit needn't support TurboHalibut. >=20 > Finally, when, some time later, Juliet deigns to respond, "Art thou = not Hamlet, and in completely the wrong play?", then shakespeare.lit = connects to denmark.lit. >=20 > Now denmark.lit can again use TurboHalibut to validate = shakespeare.lit's certificate. >=20 > None of this, you'll note, uses any dialback - probably. It can all = use SASL EXTERNAL just as well, at the very least. But it *could* use = as the authentication mechanism just as well - in fact, = it's somewhat more reliable doing it this way, because servers are = always good enough to supply a to and from, and it's faster because it = uses fewer round-trips. >=20 > The fact that the corresponding traffic never happens is = just a distraction. >=20 > It gets a lot more compelling doing things this way if Romeo, = wondering why Hamlet is chatting up his romantic interest, drops him a = message. >=20 > Shakespeare.lit already has a connection to denmark.lit from = capulet.lit, and it's already authenticated that connection - so it = makes sense to reuse it. It can't use SASL, so instead it just sends a = . Denmark.lit treats this *exactly the same way* as a SASL = EXTERNAL - it checks the from address against the certificate, and = should this fail - and it does, of course - it uses TurboHalibut to = validate the certificate, and sends back the authorizing . >=20 > Again, in this case, shakespeare.lit need not know anything about = TurboHalibut. In fact, it can cheerfully assume that denmark.lit is = doing "real" dialback. >=20 > However, I stress - dialback without dialback is merely a solution for = piggybacking. >=20 > Dave. > --=20 > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPYOdnAAoJEJq6Ou0cgrSPVGAIAIaB1AuvfEUhIxF+6LktTeft 871iNqgVsmR4+9UYLhRkUOXuTYm7D9+XiAVcW5+wWQlCeTxsDoB83Euvy/FZo3nG 89YKj6n22XNML3o34Uz3KXVuXRqVP5Cyir/Ds+AJCf7+56ZKw0XGxSdIujqWFWZ8 43/sj374eUUrmZEPRyLMzcwM59QMIDaVSzIDtQfvI/s9qCKC6+3+HZ2/fr6J3Ze+ ohgLnQp6dRuMt8/JaNX+/vAr33LCfR2HmYPFo2Yzm/pqF1wO1kp5vgttivFwKo8W r/GB+sv/53Vr64TbbKEmHmVchS7wmCUEqKoBW8JJ/3Z7TLfycaH+s4fglhXoA8U=3D =3Dk9CC -----END PGP SIGNATURE----- From fippo@mail.symlynx.com Wed Mar 14 12:44: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 31CA921F8760 for ; Wed, 14 Mar 2012 12:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 BbGbe828svuN for ; Wed, 14 Mar 2012 12:44:26 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id E9E5A21F875B for ; Wed, 14 Mar 2012 12:44:25 -0700 (PDT) Received: from [192.168.178.37] (p548BDF33.dip.t-dialin.net [84.139.223.51]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2EJiKFj032128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 20:44:24 +0100 Message-ID: <4F60F50F.7000208@mail.symlynx.com> Date: Wed, 14 Mar 2012 20:44:15 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com> <9470.1330707832.760127@puncture> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA) 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, 14 Mar 2012 19:44:27 -0000 Am 14.03.2012 19:45, schrieb Matt Miller: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thank you for this feedback. > > So far, I'm hearing a lot if favor of out-of-band validation, and little-to-none in favor of in-band. Whether it's DANE or HTTPS/.well-known or something else is mostly irrelevant. It's effectively happening within the software's "TLS support" (for various definitions of "TLS support"). > I also met with Peter Saint-Andre about this, and we came to a similar conclusion regarding validation. Questions that arose: > - - do we need a way to signal a preferred prooftype (probably not?) Matter of local service policy. > - - order of operations (SRV, TLS, DANE, HTTPS/.well-known) matter? Likewise. > - - how long to suspend disbelief on TLS? (interactions with existing software) "but it works with jabber.org" is the argument I most frequently heard when telling people that their certificate is wrong (for various meanings of that). > It looks like we need to codify the HTTPS/.well-known and/or DANE validation processes; and to formalize d-w-d, presumably starting with draft-ietf-xmpp-dna-01. A blend of XEPs 220 and 288 might be a better start. I wanted to merge both documents at some point anyway. Proof types should be separate documents: One for dial-back (essentially , historical), certificate-equality (as a replacement for 0185), trusted-cert (replaces SASL EXTERNAL), HTTPS/.well-known and DANE. Last but not least TurboHalibut of course! From ben@nostrum.com Wed Mar 14 13:08:53 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 0B12721F8503 for ; Wed, 14 Mar 2012 13:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, 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 eh1P9BjjujTK for ; Wed, 14 Mar 2012 13:08:52 -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 6CDF821F84FF for ; Wed, 14 Mar 2012 13:08:52 -0700 (PDT) Received: from dn3-123.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2EK8mTL019514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 15:08:50 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2012 15:08:47 -0500 Message-Id: <58019F4A-C074-40BF-BFFF-2F6C5EE524CB@nostrum.com> To: XMPP Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [xmpp] Updated Draft XMPP Agenda for IETF83 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, 14 Mar 2012 20:08:53 -0000 Hi, Oops, had an old draft for 6122bis. Fixed in this version. Thanks! Ben. ----------------------------------- XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 -- Status and Agenda Bashing -- 5 min (Chairs) -- End to End Encryption (Matt Miller) -- 20 min htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 -- Domain Name Assertions (Matt MIller) -- 15 min List Discussion, http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 -- Internationalization Issues (Peter St. Andre) -- 15 min http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-00 http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 If time permits: -- Combining XMPP and SIP ( Emil Ivov ) - 5 min http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00 -- Open Discussion -- Any remaining time and energy From mamille2@cisco.com Wed Mar 14 13:09:55 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 B527C21E8010 for ; Wed, 14 Mar 2012 13:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.063 X-Spam-Level: X-Spam-Status: No, score=-9.063 tagged_above=-999 required=5 tests=[AWL=1.536, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EdjnuhUmeqC6 for ; Wed, 14 Mar 2012 13:09:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7021E800E for ; Wed, 14 Mar 2012 13:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=1823; q=dns/txt; s=iport; t=1331755795; x=1332965395; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zpT5u/JFfrDVGH1oHvA5U0NSQETyO6vy0sH2ImW1V68=; b=Cvqjw4ZC6PqiXDFILqKgKkJ6UyZ45Ysd+Du7pDDgPbLWtti4WxJDPZ27 PXl2V/DFb5zo35KybegAEdPvwndAvIb+NqXHe/Ftv9t8lSIefLoSoWXk6 Z6tfoqRGQbbZ9oMMKJhVX/o7F3Eq6T8LSx2fB7jfxV1+Y54A/OW2oLrIw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADj6YE+rRDoI/2dsb2JhbABDtjaBB4IJAQEBAwEBAQEPASc0CwULC0YnMAYTIodjBAELoHWXTJAcYwSIV4x/jkCBaIMF X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="33569099" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 20:09:55 +0000 Received: from dhcp-64-101-72-155.cisco.com (dhcp-64-101-72-155.cisco.com [64.101.72.155]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EK9sPs011990; Wed, 14 Mar 2012 20:09:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <58019F4A-C074-40BF-BFFF-2F6C5EE524CB@nostrum.com> Date: Wed, 14 Mar 2012 14:09:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58019F4A-C074-40BF-BFFF-2F6C5EE524CB@nostrum.com> To: Ben Campbell X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Group Subject: Re: [xmpp] Updated Draft XMPP Agenda for IETF83 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, 14 Mar 2012 20:09:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 WFM - - m&m Matt Miller - Cisco Systems, Inc. On Mar 14, 2012, at 14:08, Ben Campbell wrote: > Hi, >=20 > Oops, had an old draft for 6122bis. Fixed in this version. >=20 > Thanks! >=20 > Ben. >=20 > ----------------------------------- >=20 > XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 >=20 > -- Status and Agenda Bashing -- 5 min (Chairs) >=20 > -- End to End Encryption (Matt Miller) -- 20 min > =09 > htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 >=20 > -- Domain Name Assertions (Matt MIller) -- 15 min > =09 > List Discussion,=20 > http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >=20 > -- Internationalization Issues (Peter St. Andre) -- 15 min >=20 > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-00 > http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 >=20 > If time permits: >=20 > -- Combining XMPP and SIP ( Emil Ivov ) - 5 min > =09 > http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00 >=20 > -- Open Discussion -- Any remaining time and energy > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPYPsSAAoJEJq6Ou0cgrSPLdAH/0EVD/1QyubTwYmlSw9nOS9J pZJdv/8SaJhx+Pf4P7jY+lw1a+9+rrrz6096kluXi1qG07DWpYqVD0R/fkvfNS9l 2uODqy3NZL217eDfHBERSjt4ebjp6AP7iRoTyYIxzlGw2F+YZDOLMGVDhwp3WKCN HNnxIwnI8bXZALREtmxZ6X1ZbCc7HDRaGju4lHXQufF7BKSimnGDDBYxDgHbIufC IcbBT+agVMMi52FS5bi7MN/kIaWWyL+Ea7DBx+d2Vo5KripuCl62Uimu91D8h4oc /t98kFlKyA/CFi9UfH7bpXQj/NQYLgQZGGvYSyWFzlKQ/FTVOVo7Q9SAAijkRxY=3D =3D4elg -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Mar 14 13:10:18 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 E0BAF21E8021 for ; Wed, 14 Mar 2012 13:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.629 X-Spam-Level: X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=0.970, 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 6kscG0YgY8IU for ; Wed, 14 Mar 2012 13:10:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC5C21E800E for ; Wed, 14 Mar 2012 13:10:18 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F2E040058; Wed, 14 Mar 2012 14:22:40 -0600 (MDT) Message-ID: <4F60FB28.4030008@stpeter.im> Date: Wed, 14 Mar 2012 14:10:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ralph Meijer References: <4F60B606.1020302@stpeter.im> <4F60C972.6000406@ik.nu> In-Reply-To: <4F60C972.6000406@ik.nu> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] i18n topic 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, 14 Mar 2012 20:10:19 -0000 On 3/14/12 10:38 AM, Ralph Meijer wrote: > On 2012-03-14 16:15 , Peter Saint-Andre wrote: >> On 3/14/12 8:18 AM, Ben Campbell wrote: >> >>> -- Internationalization Issues (Peter St. Andre) -- 15 min >>> >>> http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 >>> http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 >> >> The main topic I'd like to discuss in person is this: do we really need >> a PRECIS profile for resourceparts, or can we just do byte-for-byte >> comparison in general and then define PRECIS profiles for specific >> applications that use resourceparts (such as the nickname profile for >> chatroom nicks)? > > I'm not sure if we need a full-blown PRECIS profile for resourceparts in > general, but I do think that byte-for-byte comparison is problematic. > > XML handling libraries typically deal with objects representing strings > of codepoints, not the string of bytes sent over the wire. > Codepoint-for-codepoint comparison is probably the reasonable minimum. Hi Ralph! Yes, I think Dave Cridland probably meant codepoint-for-codepoint comparison when he mentioned the idea on another list. Purely from the perspective of stanza delivery, the server doesn't care about presentation or user confusion, only about differentiating between two resources. For example: henryiv@shakespeare.lit/Henry IV's Laptop henryiv@shakespeare.lit/Henry Ⅳ's Laptop The first one has LATIN CAPITAL LETTER I and LATIN CAPITAL LETTER V (U+0049 and U+0056), whereas the second one has ROMAN NUMERAL FOUR (U+2163). However, if clients are ever going to show these resourceparts in the UI, you can bet that users would be confused. At this point in the evolution of our thinking about i18n, I think it is probably safest to define a PRECIS profile that does exactly what Resourceprep did using stringprep (or as close as we can come to that). However, we would consider that profile to be a baseline, and would allow applications that use resourceparts in more creative ways to apply more stringent PRECIS profiles -- currently I'm thinking only about the use of resourceparts as user nicknames in XMPP chatrooms, where the MUC service could enforce the PRECIS nickname profile (and perhaps also additional logic about confusable characters, yet to be defined) so as to prevent chatroom participants from being confused about who is who in the room. Peter -- Peter Saint-Andre https://stpeter.im/ From ralphm@ik.nu Wed Mar 14 13:38:12 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 5FA5E21F884B for ; Wed, 14 Mar 2012 13:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 vkeJygnUYAb2 for ; Wed, 14 Mar 2012 13:38:12 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) by ietfa.amsl.com (Postfix) with ESMTP id DAA7621F87EA for ; Wed, 14 Mar 2012 13:38:11 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 57E7AA1047 for ; Wed, 14 Mar 2012 21:38:11 +0100 (CET) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id rrqEYGUbucWP for ; Wed, 14 Mar 2012 21:38:10 +0100 (CET) Received: from dool.local (s53751670.adsl.wanadoo.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id D5958A1045 for ; Wed, 14 Mar 2012 21:38:10 +0100 (CET) Message-ID: <4F6101B2.7000507@ik.nu> Date: Wed, 14 Mar 2012 21:38:10 +0100 From: Ralph Meijer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 CC: xmpp@ietf.org References: <4F60B606.1020302@stpeter.im> <4F60C972.6000406@ik.nu> <4F60FB28.4030008@stpeter.im> In-Reply-To: <4F60FB28.4030008@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] i18n topic 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, 14 Mar 2012 20:38:12 -0000 On 2012-03-14 21:10 , Peter Saint-Andre wrote: > [..] > Hi Ralph! > > Yes, I think Dave Cridland probably meant codepoint-for-codepoint > comparison when he mentioned the idea on another list. > > Purely from the perspective of stanza delivery, the server doesn't care > about presentation or user confusion, only about differentiating between > two resources. [..] Hi! Agreed. > At this point in the evolution of our thinking about i18n, I think it is > probably safest to define a PRECIS profile that does exactly what > Resourceprep did using stringprep (or as close as we can come to that). > However, we would consider that profile to be a baseline, and would > allow applications that use resourceparts in more creative ways to apply > more stringent PRECIS profiles -- currently I'm thinking only about the > use of resourceparts as user nicknames in XMPP chatrooms, where the MUC > service could enforce the PRECIS nickname profile (and perhaps also > additional logic about confusable characters, yet to be defined) so as > to prevent chatroom participants from being confused about who is who in > the room. Yes, that does seem sensible to me, too. Figuring out conflicts between those PRECIS profiles might be funny, though. -- ralphm From stpeter@stpeter.im Wed Mar 14 14:02: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 1D77F21F8880 for ; Wed, 14 Mar 2012 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 LX6MT-vZCguD for ; Wed, 14 Mar 2012 14:02:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2C21F887E for ; Wed, 14 Mar 2012 14:02:22 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D98C040058; Wed, 14 Mar 2012 15:14:44 -0600 (MDT) Message-ID: <4F61075D.1020503@stpeter.im> Date: Wed, 14 Mar 2012 15:02:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ralph Meijer References: <4F60B606.1020302@stpeter.im> <4F60C972.6000406@ik.nu> <4F60FB28.4030008@stpeter.im> <4F6101B2.7000507@ik.nu> In-Reply-To: <4F6101B2.7000507@ik.nu> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] i18n topic 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, 14 Mar 2012 21:02:23 -0000 On 3/14/12 2:38 PM, Ralph Meijer wrote: > On 2012-03-14 21:10 , Peter Saint-Andre wrote: >> [..] >> Hi Ralph! >> >> Yes, I think Dave Cridland probably meant codepoint-for-codepoint >> comparison when he mentioned the idea on another list. >> >> Purely from the perspective of stanza delivery, the server doesn't care >> about presentation or user confusion, only about differentiating between >> two resources. [..] > > Hi! Agreed. > >> At this point in the evolution of our thinking about i18n, I think it is >> probably safest to define a PRECIS profile that does exactly what >> Resourceprep did using stringprep (or as close as we can come to that). >> However, we would consider that profile to be a baseline, and would >> allow applications that use resourceparts in more creative ways to apply >> more stringent PRECIS profiles -- currently I'm thinking only about the >> use of resourceparts as user nicknames in XMPP chatrooms, where the MUC >> service could enforce the PRECIS nickname profile (and perhaps also >> additional logic about confusable characters, yet to be defined) so as >> to prevent chatroom participants from being confused about who is who in >> the room. > > Yes, that does seem sensible to me, too. Figuring out conflicts between > those PRECIS profiles might be funny, though. If they are defined carefully, we would not have conflicts but a kind of layering. For example, in PRECIS right now the NameClass is more restrictive than the FreeClass, but everything that's allowed by the NameClass is allowed by the FreeClass. I'd envision doing something similar here -- that is, for resourceparts we'd use the FreeClass pretty much as-is (specify NFC and perhaps optional casemapping), whereas the nickname profile would restrict things further by specifying NFKC instead of NFC and required casemapping. Naturally the proof of the pudding is in the eating, and we'd need to check the codepoints that result from each class and subclass to make sure that the nickname profile is strictly a subset of the FreeClass. Peter -- Peter Saint-Andre https://stpeter.im/ From hiro.suzuki@d3communications.jp Thu Mar 15 23:17: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 50D0A21F86D7 for ; Thu, 15 Mar 2012 23:17:09 -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=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XmLjRuU5H6iH for ; Thu, 15 Mar 2012 23:17:08 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80B21F86D9 for ; Thu, 15 Mar 2012 23:17:08 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1342028yhk.31 for ; Thu, 15 Mar 2012 23:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d3communications.jp; s=google; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=6Nc+22hcX0+OKdjCSm/rgoYTvdIsfEOLxfIvEhScvV8=; b=BhNW42sC1ZS70YOQ+XSc5Jqtp8RCHXxmY+QawUidYHN554+QPC05cq1grWn6X9hPK/ XfL44FYyhYuT0wTr1OCn5/2uXg/NPRfTyHqPoriokZ8S1qLnxEBs7IZ61CZ5gV6aE4Dr VtUk/xKNM03y1/qk2iKLbm53qu2+0C7T/Jgdk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=6Nc+22hcX0+OKdjCSm/rgoYTvdIsfEOLxfIvEhScvV8=; b=AdFVK+jrxhOkMU2/8OIR5iCuUlzhBx17wyIbrJjA/G0dBIMqpO9ijVby+8l+1XHxSZ 8mqlKbZFmVha0+cnbJiNzDLa63wy4My7DdR5rPHeHNqe1gAGspykmJV9jEV6nUIIyQ/0 HyAwDaixa8HZ8iIBQgKqiy5qNJPPrUxym2k8TPP9d5O9Gan93oW8klJ1CObHMAO+dYXW f1eI0Wa36l2BN4rk0AkTFf+NoeDmBQxNcEejboJykIiWhGqVhyJb55CylzXnU0S+5TQF 6jsaIuDLJ8pvzFFo6Djpe8089ZypLLkWmO4qQ2V3/OHOEgteNUEGootmzeuaDgp7RgJV 6lzQ== Received: by 10.68.189.104 with SMTP id gh8mr5687202pbc.26.1331878627226; Thu, 15 Mar 2012 23:17:07 -0700 (PDT) Received: from [192.168.1.8] (p32002-ipngn402hodogaya.kanagawa.ocn.ne.jp. [180.23.153.2]) by mx.google.com with ESMTPS id k3sm3553664pbd.17.2012.03.15.23.17.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 23:17:04 -0700 (PDT) From: HIro Suzuki Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 15:17:00 +0900 Message-Id: <247AF367-86EA-4D8E-B9C3-0C8E3A0A4E01@d3communications.jp> To: #info IETF XMPP WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk1QE7JbomAsfET2GO4IFf5wj8uGvvQSpfdNfC4nSH4qdq4h0sc0wFwwoIgqAaRlFDaKQO4 Subject: [xmpp] Proposal of Jingle Web Cooperation 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, 16 Mar 2012 06:17:09 -0000 Hello all, I submitted a I-D (draft-suzuki-web-jingle-00.txt) at 28h, Feb. This I-D describes Jingle extension to cooperate Web Browser, and this I-D is = actually the same as "draft-suzuki-rtcweb-jingle-web-00.txt" This proposals in this ID is almost same as first half of my "Anoter MUJI" proposal in the last XMPP Summit. But I think IETF XMPP WG = participants are different from XMPP Summit participants, and in the last XMPP = Summit, I didn't talk about my proposal in front of the whole Summit = participants. In this I-D, I made one change to signal layout information from My = proposal at the Summit, because HTML5/CSS/JavaScript syntax isn't conformed to = XML syntax, and propose two mapping manner between Jingle contents and = HTML/DOM elements. I know the discussion about realtime communication with Web bowser had = begun at RTCWeb/WebRTC WGs, and I'd like to adapt my proposal to fit the draft = of RTCWeb/WebRTC spec. I think cooperation with XMPP and Web has many potentials, it's not = limited to video or audio communication only. Web can mix and display various = information, so I'd like to submit my other proposals (MUJI extension to cooperate = Web and PubSub extension to cooperate Web, etc) introduced at the XMPP Summit as = I-Ds after Paris meeting. I'd like to apply xmpp to many realtime services, and I'd like to = realize easy-programable realtime service platform. Best Regards, Yoshihiro Suzuki= From hiro.suzuki@d3communications.jp Fri Mar 16 09:10:35 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 7C83C21F860E for ; Fri, 16 Mar 2012 09:10:35 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bI8StLWwsPXI for ; Fri, 16 Mar 2012 09:10:34 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8514E21F860D for ; Fri, 16 Mar 2012 09:10:34 -0700 (PDT) Received: by dakl33 with SMTP id l33so7261380dak.31 for ; Fri, 16 Mar 2012 09:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d3communications.jp; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=85Vxt5ooMHximpyImNpFcvuXOkVwv1kEXmvkLyDOGAU=; b=AEnUDIDRoZELh5pt7edfXiAnowNW/LtHW6NbPnxTEcWsgVkluVryI6GrUCtP9kf+RU 4OTodPcHkCu5XE4vHzSAL6rNFPzRhC5j11uH1r5V74fkVvIJUeho93quI3n/iaP1rR9R t7hUgI+3aE2GvqIRGLTOmhBUOSrHh2uXKibYg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=85Vxt5ooMHximpyImNpFcvuXOkVwv1kEXmvkLyDOGAU=; b=STl0yZSD+EifdLzIOAXaf7GCTpVWSVo9d4c5hvxD080OmbWU6bmngN/L+bxz0buRjl OuNdtPursWUxL7BrgjJPCM6D2S8mr36BSmyj5rhX9CeYScUHFDmHbma2UKRfOPlG/7jU 01WtQxrAOkqftjS/LSHgyPXMCqkFf2crkEmB5gtoCa1FPz7V4Vraq9O1DXf6C+uf8xTP qOPIWTbq+EoLUMTY0gb2LXeD0FuniD3KY2+Shsg0YWQLYN7F+cKXxt0W3usqVTdKZ1sa MHV9fiVo2UiljzmTvEuBEE0vy2MHeyBIBTwXzOiZyHTU3051rtIQqIzqTurNyDBGSKZ+ 1YfA== Received: by 10.68.229.234 with SMTP id st10mr15991526pbc.86.1331914233994; Fri, 16 Mar 2012 09:10:33 -0700 (PDT) Received: from [192.168.1.8] (p32002-ipngn402hodogaya.kanagawa.ocn.ne.jp. [180.23.153.2]) by mx.google.com with ESMTPS id u7sm4576924pbm.49.2012.03.16.09.10.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 09:10:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: HIro Suzuki In-Reply-To: <247AF367-86EA-4D8E-B9C3-0C8E3A0A4E01@d3communications.jp> Date: Sat, 17 Mar 2012 01:10:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC758A1-4B38-4F08-8281-719D3994AB90@d3communications.jp> References: <247AF367-86EA-4D8E-B9C3-0C8E3A0A4E01@d3communications.jp> To: #info IETF XMPP WG , #info XSF Jingle ml X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk2FUeWgqhGrY9fdAxw1rcA6Ni5r0pq//5G/Leu0LGr7L7TMhdDFFxTJ3G1uCEdr/hKBK2/ Subject: Re: [xmpp] Proposal of Jingle Web Cooperation 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, 16 Mar 2012 16:10:35 -0000 Hi,=20 FYI, abstract of I-D is as follows, -- XMPP Jingle specification defines an XMPP protocol extension for managing peer-to-peer media sessions between two users. And XMPP Jingle can manage multi contents simultaneously in one Jingle stream, but in the XMPP world there is no common way to layout variable multi contents on each display. In this document, a solution to this issue is provided by using Web browser's layout function. This document describes a new concept to realize one of solutions of RTCWeb. Of course, "Web Browser" is used for Web application's frontend for real-time communication, and XMPP Jingle specification (XEP-166) is used as signaling protocol. And a simple mapping manner between jingle contents and HTML graphical elements enables to unite Web browser's layout function and Jingle's media content management function to realize RTCWeb functions. --- I welcome any opinion and suggestion. Cheers, Hiro On 2012/03/16, at 15:17, HIro Suzuki wrote: > Hello all, >=20 >=20 > I submitted a I-D (draft-suzuki-web-jingle-00.txt) at 28h, Feb. This = I-D > describes Jingle extension to cooperate Web Browser, and this I-D is = actually > the same as "draft-suzuki-rtcweb-jingle-web-00.txt" >=20 > This proposals in this ID is almost same as first half of my "Anoter > MUJI" proposal in the last XMPP Summit. But I think IETF XMPP WG = participants > are different from XMPP Summit participants, and in the last XMPP = Summit, > I didn't talk about my proposal in front of the whole Summit = participants. > In this I-D, I made one change to signal layout information from My = proposal > at the Summit, because HTML5/CSS/JavaScript syntax isn't conformed to = XML > syntax, and propose two mapping manner between Jingle contents and = HTML/DOM > elements. >=20 > I know the discussion about realtime communication with Web bowser had = begun > at RTCWeb/WebRTC WGs, and I'd like to adapt my proposal to fit the = draft of > RTCWeb/WebRTC spec. >=20 > I think cooperation with XMPP and Web has many potentials, it's not = limited to > video or audio communication only. Web can mix and display various = information, > so I'd like to submit my other proposals (MUJI extension to cooperate = Web and > PubSub extension to cooperate Web, etc) introduced at the XMPP Summit = as I-Ds > after Paris meeting. >=20 > I'd like to apply xmpp to many realtime services, and I'd like to = realize > easy-programable realtime service platform. >=20 > Best Regards, > Yoshihiro Suzuki From ogashiwa@c.kyoai.ac.jp Fri Mar 16 09:27:25 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 C8AC721F8752 for ; Fri, 16 Mar 2012 09:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 0IV2mV9iHiBH for ; Fri, 16 Mar 2012 09:27:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5181C21F85EA for ; Fri, 16 Mar 2012 09:27:25 -0700 (PDT) Received: by yenm5 with SMTP id m5so4974992yen.31 for ; Fri, 16 Mar 2012 09:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=sEfGRKjJ5qUtui0BF+aXIHd2vHNW4zrGoiBs5WgiOAw=; b=T4Jh2HE5bE2L5iihuZ5s4qUZafBVvENicn893A9WQLtZXIZJkQjW9YWCmWCJvKGsH6 J7oRd2QVn52t25E7bOg6lR6M8gkOMdHakdo1/mK3Ws1TcWVfBGik6ytimGnigMmecjvJ pn/wJIooK0cdqn/1riGJnMilI3V4ThWRZdDi25mAItOHEmA5TzCQz42sC8FOWcmgoYD6 TnvXZfA4WvNOgjyac0diMAl9JyqGTkQnXD4VHfdEhfmhv2eio/KAD52bMgwQLMOwvAle dOtH872lZMppgAHjuSgAhJD+c8/0Qg4mDXti+oqwZh9tDPcgTy21kC14A48BKB57XSVk IZ7Q== MIME-Version: 1.0 Received: by 10.52.38.167 with SMTP id h7mr1682071vdk.109.1331915244763; Fri, 16 Mar 2012 09:27:24 -0700 (PDT) Received: by 10.52.90.41 with HTTP; Fri, 16 Mar 2012 09:27:24 -0700 (PDT) Date: Sat, 17 Mar 2012 01:27:24 +0900 Message-ID: From: Nobuo Ogashiwa To: XMPP Group Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlbt92PCnAhXzw2MNwiAFSYIFhcrv/EdEsF/l0xtqjJVV3abxBedfv1e6UCTJJaqZH1pryQ Subject: [xmpp] SRV record extension 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, 16 Mar 2012 16:27:25 -0000 Dear all, We have submitted following I-D: http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 After the 2011/3/11 earthquake in japan, we are interested in reliability and stability of XMPP-based systems. The RFC6120 defines that the XMPP server and client use SRV record for reliability. However, most of standard libraries in client OS like MacOS, Windows, Linux and *BSD does not support SRV record resolution. Furthermore, many DNS hosting services do not support SRV record registration. So that there are some cases that we can not get a benefit of SRV record in the global internet environment. So, we have proposed IQ message extensions to query and reply multiple server hostnames in our I-D. If you want to know the details of extensions, please see our I-D. In technically, the above problem can be solved by using TXT record instead of SRV record (and also extensions we proposed in our I-D). The TXT record solutions is just like following: TXT="sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". We think this would be an alternative solution of the problem we mentioned in the I-D. We think that maybe extensions we proposed in our I-D should be published as not I-D but XEP. However, TXT record solution I mentioned in this e-mail should be discussed not XSF but IETF XMPP WG. So we would like to know how many people in IETF XMPP WG are interested in reliability of the XMPP. If you are interested in reliability and stability of XMPP-based systems, please send comments or suggestions for our I-D. Regards, Nobuo Ogashiwa From stpeter@stpeter.im Fri Mar 16 10:15:19 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 D2CF121E8012 for ; Fri, 16 Mar 2012 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=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 u5Msbvx9l7jz for ; Fri, 16 Mar 2012 10:15:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CF21F8543 for ; Fri, 16 Mar 2012 10:15:19 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 499BD40058; Fri, 16 Mar 2012 11:27:47 -0600 (MDT) Message-ID: <4F637525.1060506@stpeter.im> Date: Fri, 16 Mar 2012 11:15:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nobuo Ogashiwa References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Group Subject: Re: [xmpp] SRV record extension 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, 16 Mar 2012 17:15:20 -0000 On 3/16/12 10:27 AM, Nobuo Ogashiwa wrote: > Dear all, > > We have submitted following I-D: > http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 > > After the 2011/3/11 earthquake in japan, we are interested in > reliability and stability of XMPP-based systems. > > The RFC6120 defines that the XMPP server and client use SRV record for > reliability. However, most of standard libraries in client OS like > MacOS, Windows, Linux and *BSD does not support SRV record > resolution. Furthermore, many DNS hosting services do not support SRV > record registration. So that there are some cases that we can not get a > benefit of SRV record in the global internet environment. > > So, we have proposed IQ message extensions to query and reply multiple > server hostnames in our I-D. If you want to know the details of > extensions, please see our I-D. > > In technically, the above problem can be solved by using TXT record instead > of SRV record (and also extensions we proposed in our I-D). > The TXT record solutions is just like following: > > TXT="sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". > > We think this would be an alternative solution of the problem we > mentioned in the I-D. > > We think that maybe extensions we proposed in our I-D should be > published as not I-D but XEP. However, TXT record solution I > mentioned in this e-mail should be discussed not XSF but IETF XMPP WG. Hello Ogashiwa-san! Why not use XEP-0156 ("Discovering Alternative XMPP Connection Methods")? http://xmpp.org/extensions/xep-0156.html I realize that XEP-0156 says "A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in RFC 6120." However, it might make sense to relax that rule, or describe when it is appropriate to override the SHOULD NOT. Peter -- Peter Saint-Andre https://stpeter.im/ From mwild1@gmail.com Fri Mar 16 10:46:58 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 0528421E8012 for ; Fri, 16 Mar 2012 10:46:58 -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=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 IFGXxJPj33LT for ; Fri, 16 Mar 2012 10:46:57 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05D21E8046 for ; Fri, 16 Mar 2012 10:46:53 -0700 (PDT) Received: by iazz13 with SMTP id z13so6678163iaz.31 for ; Fri, 16 Mar 2012 10:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ksQCICsu4XVNnVLCY/qtYHuGcmDT9cTTIWTrPHL77og=; b=sqZZqBy2mEbvMUhZdDS9+Ch/7LN58Sjwjx2xu5Lw/TSAqA8B3bNUVSIds9pG02wBr6 qWo+ax0/e4jyHDE5xBkoxHg9Hm/adOu5okR+EiQfD8262KnRvzTFun0KrC2x1swNwlMP dZKEeun+L8PQmo24I3v+Ml4ADBA71MeHIyJ231CIO2NKorIvIrTw5QatB/ZbNLGQF23n HBEqCQfaF5cuA+0687zic9wOcNTm9nAzA1S8wgOcvJCHWthSv/9cH2VROYLa88gFz9VE 0z8iP/D3jS4tTr5hVwQQvBlqFNO1kquQ9QUuo0/9YKsy4fKbsoHcNDYrJH9GHq69tc4u 7T3Q== Received: by 10.50.51.226 with SMTP id n2mr32092igo.68.1331920013015; Fri, 16 Mar 2012 10:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.146.9 with HTTP; Fri, 16 Mar 2012 10:46:32 -0700 (PDT) In-Reply-To: References: From: Matthew Wild Date: Fri, 16 Mar 2012 17:46:32 +0000 Message-ID: To: Nobuo Ogashiwa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Group Subject: Re: [xmpp] SRV record extension 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, 16 Mar 2012 17:46:58 -0000 Hi, Thanks for your draft. It's interesting. But I have a number of issues with both its defined problems and solutions. Comments inline... On 16 March 2012 16:27, Nobuo Ogashiwa wrote: > Dear all, > > We have submitted following I-D: > http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 > > After the 2011/3/11 earthquake in japan, we are interested in > reliability and stability of XMPP-based systems. > > The RFC6120 defines that the XMPP server and client use SRV record for > reliability. =C2=A0However, most of standard libraries in client OS like > MacOS, Windows, Linux and *BSD does not support SRV record I think the widespread availability of clients and servers for all these platforms suggests this isn't really that much of an issue. > resolution. Furthermore, many DNS hosting services do not support SRV > record registration. So that there are some cases that we can not get a > benefit of SRV record in the global internet environment. I don't have data on the capabilities of DNS providers, but I personally haven't encountered one that doesn't support SRV for years. While I'm sure some are still out there, all the popular ones support them. Adoption of SRV support was greatly increased by Google's usage - anyone who wants to delegate a domain to Google must use SRV. > So, we have proposed IQ message extensions to query and reply multiple > server hostnames in our I-D. If you want to know the details of > extensions, please see our I-D. Deploying this technique would not interop with the existing network. > In technically, the above problem can be solved by using TXT record inste= ad > of SRV record (and also extensions we proposed in our I-D). > The TXT record solutions is just like following: > > =C2=A0TXT=3D"sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". TXT is also a second-class citizen as far as resolvers and DNS providers are concerned. If your stated problems with SRV are valid, then I think you should be just as concerned about using TXT records. > If you are interested in reliability and stability of XMPP-based > systems, please send comments or suggestions for our I-D. I think this proposal has little to do with "reliability" as such. Your goals are to solve perceived problems with the DNS location mechanism currently used in XMPP, that are easily solved by using appropriate DNS libraries and DNS hosting providers. DNS is already a reliable distributed system for locating servers, and is used successfully by XMPP clients and servers all over the internet on every platform. Duplicating DNS at the XMPP level has a number of problems, including interop with the current network. If you have specific evidence to the contrary of anything I've written here, I would be interested to see that. Regards, Matthew From florob@babelmonkeys.de Fri Mar 16 11:14:57 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 0F4CE21F85D2 for ; Fri, 16 Mar 2012 11:14:57 -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 6TF6xCQxT3iN for ; Fri, 16 Mar 2012 11:14:56 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2621F853A for ; Fri, 16 Mar 2012 11:14:56 -0700 (PDT) Received: from xdsl-213-196-243-40.netcologne.de ([213.196.243.40] helo=[192.168.0.50]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S8bfw-0004t6-1a for xmpp@ietf.org; Fri, 16 Mar 2012 19:14:52 +0100 Message-ID: <4F638316.5020007@babelmonkeys.de> Date: Fri, 16 Mar 2012 19:14:46 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: xmpp@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] SRV record extension 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, 16 Mar 2012 18:14:57 -0000 On 16.03.2012 18:46, Matthew Wild wrote: > On 16 March 2012 16:27, Nobuo Ogashiwa wrote: >> Dear all, >> >> We have submitted following I-D: >> http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 >> >> After the 2011/3/11 earthquake in japan, we are interested in >> reliability and stability of XMPP-based systems. >> >> The RFC6120 defines that the XMPP server and client use SRV record for >> reliability. However, most of standard libraries in client OS like >> MacOS, Windows, Linux and *BSD does not support SRV record > > I think the widespread availability of clients and servers for all > these platforms suggests this isn't really that much of an issue. > Hi, I have to agree with Matthew on this point. Just to stress this: Microsoft Windows provides the DnsQuery() call, which can return a list of SRV records (nicely put into structures even). On MacOS X, Linux and *BSD (also Haiku and likely some others not in your list) the res_search() function is usually available. It is considerably harder to use than DnsQuery() (particularly parsing the result), but that's far from necessitating a new RFC. Regards, Florian Zeitz From metajack@gmail.com Fri Mar 16 11:22: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 5CBD021F864C for ; Fri, 16 Mar 2012 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 kW-5udInjmH0 for ; Fri, 16 Mar 2012 11:22:41 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6532B21F862B for ; Fri, 16 Mar 2012 11:22:41 -0700 (PDT) Received: by yenm5 with SMTP id m5so5115425yen.31 for ; Fri, 16 Mar 2012 11:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xiY0ExOrTw3nyBL8IGOS8ABKidFSQ6vYIkHCouydkyY=; b=FGCwpqjL9lgrvG6WZI1X/9Fi8rI97e/Wp/fDjHdxp8XEevz13hxOzAfGqINGC/Imnl b0GONrViZlvBRrfgFIYkN3cqi7nEwPtTUnRjQ24fEK/De3Sn7glDigmvEnZAZCX2QGhG u3skL+9rY3lZ3rd4pcGnxFG+dS5LGziWHeJ1nIiw8W79Q7WhsIk+aDRbD7FZQF12fs2P P9LC9yxeb1vIXSdKSki3rztE23nJUySAyHp7w3WHTcHpNbKKPcv3p3/ks3tmV2fqQgU0 I6c/sBgReUml1H9qE0/d523zhVFNF7GaQGjsElTzkM/bjXuAd8HjE5ZwEpHchYtO3YCP UQtQ== MIME-Version: 1.0 Received: by 10.50.179.102 with SMTP id df6mr117522igc.69.1331922160860; Fri, 16 Mar 2012 11:22:40 -0700 (PDT) Sender: metajack@gmail.com Received: by 10.50.114.99 with HTTP; Fri, 16 Mar 2012 11:22:40 -0700 (PDT) In-Reply-To: <4F638316.5020007@babelmonkeys.de> References: <4F638316.5020007@babelmonkeys.de> Date: Fri, 16 Mar 2012 12:22:40 -0600 X-Google-Sender-Auth: Dme2nytk618Ujxl7A0fpQufPgG4 Message-ID: From: Jack Moffitt To: Florian Zeitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] SRV record extension 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, 16 Mar 2012 18:22:42 -0000 >>> The RFC6120 defines that the XMPP server and client use SRV record for >>> reliability. =A0However, most of standard libraries in client OS like >>> MacOS, Windows, Linux and *BSD does not support SRV record >> >> I think the widespread availability of clients and servers for all >> these platforms suggests this isn't really that much of an issue. SRV support is readily available in system libraries on all modern platforms, and has been for at least 4-5 years. On OS X and Linux, you use res_query, and on Windows systems you use the APIs form dnsapi.dll. You do have to implement the server selection algorithm, but you can easily get the contents of SRV records without any external dependencies. You can see examples of both of these here: https://github.com/metajack/libstrophe/blob/master/src/sock.c jack. From fippo@mail.symlynx.com Fri Mar 16 15:08:39 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 A227C21E8032 for ; Fri, 16 Mar 2012 15:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_62=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 Nwbkm3KAV7BX for ; Fri, 16 Mar 2012 15:08:38 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 85D4521E801A for ; Fri, 16 Mar 2012 15:08:38 -0700 (PDT) Received: from [192.168.178.37] (p548BDB92.dip.t-dialin.net [84.139.219.146]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2GM8Laq002379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Mar 2012 23:08:37 +0100 Message-ID: <4F63B9D0.5060805@mail.symlynx.com> Date: Fri, 16 Mar 2012 23:08:16 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] SRV record extension 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, 16 Mar 2012 22:08:39 -0000 > please send comments or suggestions for our I-D. As some other people I disagree with the statement about the availability of srv resolvers -- for *nix there is public domain code from 1997 written by Arnt Gulbrandsen which does SRV resolution in 250 lines of code. SRV support in jabberd14 dates back at least to 2004 IIRC In general, the examples remind me of very old stuff like iq-auth (the usage of jabber:iq hints at this as well). It's not clear to me whether the stanza flow is supposed to happen before authentication (where it would be useful) or afterwards. Since the "Reconnection Policy Information" relies on the client to query (poll?) the information I don't see how adapt this to "lively clients". to="alice@wonderland.lit" is lacking a resource btw. From ogashiwa@c.kyoai.ac.jp Sun Mar 18 22:30:05 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 DF98021F85F3 for ; Sun, 18 Mar 2012 22:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 a1M8KMyudttv for ; Sun, 18 Mar 2012 22:30:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0AA521F85E6 for ; Sun, 18 Mar 2012 22:30:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so5267643lag.31 for ; Sun, 18 Mar 2012 22:30:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=gDR+o4vrC2znneXjwACEkMwnE1YdlAFE2cCq9MqNf0w=; b=VRlKPpFSFG3tHnIRey6OPoA/NISRzlQ+/C6T8WJXWKX1ORXYkL++kQsXv8HpmZtgFO Ibj0d5lntZsRI3T92eOTKC83gpCelgCdI85W/RPq5Hag1GhK+U/ym7V5bJgnxXrTfbc+ uicDFIjwCCpGhA9VRhYgkdCWNT8YChnjT0ByHFg7WzMzVwaVqtVzL+oDunJyVhdOEA6F 8hjqOJG8Lv9F6KOU9UhBMeeiAqQusaQtMp7rwLTpgDzLJCcndaAIFt5uoBCz/Sm5t+SD yZ3p6dNOXIRKIOaefNwwqK++XgH4ULpumaMLBGgyZoERQDUf9Oz2t10O+GavYdYHgYyq DDUw== MIME-Version: 1.0 Received: by 10.112.85.70 with SMTP id f6mr4268170lbz.16.1332135002806; Sun, 18 Mar 2012 22:30:02 -0700 (PDT) Received: by 10.112.87.65 with HTTP; Sun, 18 Mar 2012 22:30:02 -0700 (PDT) In-Reply-To: <4F637525.1060506@stpeter.im> References: <4F637525.1060506@stpeter.im> Date: Mon, 19 Mar 2012 14:30:02 +0900 Message-ID: From: Nobuo Ogashiwa To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFZOE9aM7tcSQ9aHhkXgDHnh3YSXMF7Ch4sPhvYACOjoFjUgpvVXx71KaJi+d4SBRvVYrA Cc: XMPP Group Subject: Re: [xmpp] SRV record extension 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: Mon, 19 Mar 2012 05:30:06 -0000 Hello Peter, Thank you for your helpful comments. We will consider using XEP-0156. There are some another view about TXT record as the substitutes for SRV record, so I will consider such all opinion. However, I realized it might be in different situations for each country that SRV records support status. Especially, in japan, TXT record is supported by most of all famous japanese DNS provider to support SPF, but SRV record is not supported by most of all famous japanese DNS provider. We have summarized SRV record support status in japanese famous DNS providers, please see http://nlab.jp/japan-dns.pdf . Regards, Nobuo Ogashiwa 2012/3/17 Peter Saint-Andre : > On 3/16/12 10:27 AM, Nobuo Ogashiwa wrote: >> Dear all, >> >> We have submitted following I-D: >> http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 >> >> After the 2011/3/11 earthquake in japan, we are interested in >> reliability and stability of XMPP-based systems. >> >> The RFC6120 defines that the XMPP server and client use SRV record for >> reliability. =A0However, most of standard libraries in client OS like >> MacOS, Windows, Linux and *BSD does not support SRV record >> resolution. Furthermore, many DNS hosting services do not support SRV >> record registration. So that there are some cases that we can not get a >> benefit of SRV record in the global internet environment. >> >> So, we have proposed IQ message extensions to query and reply multiple >> server hostnames in our I-D. If you want to know the details of >> extensions, please see our I-D. >> >> In technically, the above problem can be solved by using TXT record inst= ead >> of SRV record (and also extensions we proposed in our I-D). >> The TXT record solutions is just like following: >> >> =A0TXT=3D"sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". >> >> We think this would be an alternative solution of the problem we >> mentioned in the I-D. >> >> We think that maybe extensions we proposed in our I-D should be >> published as not I-D but XEP. =A0However, TXT record solution I >> mentioned in this e-mail should be discussed not XSF but IETF XMPP WG. > > Hello Ogashiwa-san! > > Why not use XEP-0156 ("Discovering Alternative XMPP Connection Methods")? > > http://xmpp.org/extensions/xep-0156.html > > I realize that XEP-0156 says "A domain SHOULD NOT present information in > DNS TXT records that is available via the DNS SRV records defined in RFC > 6120." However, it might make sense to relax that rule, or describe when > it is appropriate to override the SHOULD NOT. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From harada09@c.kyoai.ac.jp Mon Mar 19 04:30:30 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 C5E9121F865B for ; Mon, 19 Mar 2012 04:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 9q-6NdppWNWH for ; Mon, 19 Mar 2012 04:30:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0221F867F for ; Mon, 19 Mar 2012 04:30:29 -0700 (PDT) Received: by lagj5 with SMTP id j5so5476050lag.31 for ; Mon, 19 Mar 2012 04:30:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5kd2oucplbxHKmueFNprAa4eMMmFmQ2fXZWQqYK+Gmc=; b=UOa/E/bLUDWUDz2/WBRu2nXJJ3qfRFWSRrura2AjCi5fkS1QqKttX0yGxtrqKgRuoZ 2drkls1er34VdMPmy0xEYLqaCtmQpNd7e487Arl4qgt2aWbrVaMix2zx0is6ASltfVn8 NTvdPkvySOndi8fURnjkfHdVv7XQuB7ebvvuYpVyOsBL46Ycmd5g3Ufj3iVbqMpr1d7o vl5LB73LH4c2DPE9WXfy0GYlbmEMKKXxXctQfIOe+7Yyd1515xAb8eHtF1g1Wa82/6vd OonEd1bxTjYdyf84KtvvRL4hAn0eXsT0JA/JHjQvKtdORU7dV3NKBIlLSQMDURAV0qBX qjVQ== MIME-Version: 1.0 Received: by 10.112.23.39 with SMTP id j7mr4302516lbf.87.1332156628194; Mon, 19 Mar 2012 04:30:28 -0700 (PDT) Received: by 10.112.53.12 with HTTP; Mon, 19 Mar 2012 04:30:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 20:30:27 +0900 Message-ID: From: Akari Harada To: Matthew Wild Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl3lRYGDZAuLm36ZPFAYqRiG1sxJ/QYBD/1gj7FFBJzSdS3Fo1SYTYDfC/Tq1IeH5ccLvLe Cc: XMPP Group Subject: Re: [xmpp] SRV record extension 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: Mon, 19 Mar 2012 11:30:30 -0000 Dear Matthew, I'm Akari Harada, first author of the draft. Thank you for your helpful comments. As nobuo said in the above email, we recently realized that it might be in different situations each country that SRV records support status. For example, the US's popular DNS hosting service, such as networksolutions and godaddy supports SRV record. And we are using networksolutions too. However, unfortunately almost all Japanese popular that one doesn't support SRV record. In contrast, TXT record is supported large number of Japanese that one for support to SPF. We have summarized web pages of japanese DNS hosting service provider, please see http://nlab.jp/japan-dns.pdf . As most of Japanese company using SPF with TXT record, DNS hosting service supports for a TXT record. However, because of the reason it is supposed that no need to SRV record by Japanese company, Japanese DNS hosting service does't attempt to support SRV record. For this reason, we introduced the idea in the mail before that is using TXT record instead of SRV record. TXT record is more used than SRV record in Japan. I (and nobuo) personally would widely spread XMPP in the world. But because of such as s2s, search for message destination, redundancy and so on are depending heavily on the SRV record, it can also be said to an obstacle of spread of XMPP for country that less supported to SRV record like Japan. Regards, Akari Harada 2012/3/17 Matthew Wild > > Hi, > > Thanks for your draft. It's interesting. But I have a number of issues > with both its defined problems and solutions. Comments inline... > > On 16 March 2012 16:27, Nobuo Ogashiwa wrote: > > Dear all, > > > > We have submitted following I-D: > > http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 > > > > After the 2011/3/11 earthquake in japan, we are interested in > > reliability and stability of XMPP-based systems. > > > > The RFC6120 defines that the XMPP server and client use SRV record for > > reliability. =A0However, most of standard libraries in client OS like > > MacOS, Windows, Linux and *BSD does not support SRV record > > I think the widespread availability of clients and servers for all > these platforms suggests this isn't really that much of an issue. > > > resolution. Furthermore, many DNS hosting services do not support SRV > > record registration. So that there are some cases that we can not get a > > benefit of SRV record in the global internet environment. > > I don't have data on the capabilities of DNS providers, but I > personally haven't encountered one that doesn't support SRV for years. > While I'm sure some are still out there, all the popular ones support > them. Adoption of SRV support was greatly increased by Google's usage > - anyone who wants to delegate a domain to Google must use SRV. > > > So, we have proposed IQ message extensions to query and reply multiple > > server hostnames in our I-D. If you want to know the details of > > extensions, please see our I-D. > > Deploying this technique would not interop with the existing network. > > > In technically, the above problem can be solved by using TXT record ins= tead > > of SRV record (and also extensions we proposed in our I-D). > > The TXT record solutions is just like following: > > > > =A0TXT=3D"sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". > > TXT is also a second-class citizen as far as resolvers and DNS > providers are concerned. If your stated problems with SRV are valid, > then I think you should be just as concerned about using TXT records. > > > If you are interested in reliability and stability of XMPP-based > > systems, please send comments or suggestions for our I-D. > > I think this proposal has little to do with "reliability" as such. > Your goals are to solve perceived problems with the DNS location > mechanism currently used in XMPP, that are easily solved by using > appropriate DNS libraries and DNS hosting providers. > > DNS is already a reliable distributed system for locating servers, and > is used successfully by XMPP clients and servers all over the internet > on every platform. Duplicating DNS at the XMPP level has a number of > problems, including interop with the current network. > > If you have specific evidence to the contrary of anything I've written > here, I would be interested to see that. > > Regards, > Matthew > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From ben@nostrum.com Mon Mar 19 08:49:41 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 0F60E21F87D4 for ; Mon, 19 Mar 2012 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, 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 i+ElXOfTPdab for ; Mon, 19 Mar 2012 08:49:40 -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 E673C21F87D0 for ; Mon, 19 Mar 2012 08:49:38 -0700 (PDT) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2JFnZMi065022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 10:49:35 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Mon, 19 Mar 2012 10:49:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> References: To: XMPP Group X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 19 Mar 2012 15:49:41 -0000 Hi everyone, We've got an updated, and probably final*, agenda: http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt * Of course, it's always bashable :-) Thanks! Ben. On Mar 14, 2012, at 9:18 AM, Ben Campbell wrote: > Hi, >=20 > Here's the draft XMPP meeting agenda for IETF83. We're currently = scheduled for Wednesday afternoon at 1510. Please send any suggested = changes to the XMPP list as soon as possible. >=20 > Thanks! >=20 > Ben. >=20 > ----------------------------------- >=20 > XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 >=20 > -- Status and Agenda Bashing -- 5 min (Chairs) >=20 > -- End to End Encryption (Matt Miller) -- 20 min > =09 > htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 >=20 > -- Domain Name Assertions (Matt MIller) -- 15 min > =09 > List Discussion,=20 > http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >=20 > -- Internationalization Issues (Peter St. Andre) -- 15 min >=20 > http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 > http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 >=20 > If time permits: >=20 > -- Combining XMPP and SIP ( Emil Ivov ) - 5 min > =09 > http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00 >=20 > -- Open Discussion -- Any remaining time and energy > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From stpeter@stpeter.im Mon Mar 19 12:44:47 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 C860521E801F for ; Mon, 19 Mar 2012 12:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 mjkek4WV5vDr for ; Mon, 19 Mar 2012 12:44:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 309F521E8015 for ; Mon, 19 Mar 2012 12:44:47 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5FF1C40058 for ; Mon, 19 Mar 2012 13:57:25 -0600 (MDT) Message-ID: <4F678CAD.40209@stpeter.im> Date: Mon, 19 Mar 2012 13:44:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis issues 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: Mon, 19 Mar 2012 19:44:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While working on slides about 6122bis, I've discovered more open issues than I expected. To prime the pump, I'll send one email message for each open issue that I see. Hopefully we can generate some discussion beforehand and thus make good progress at the meeting next week. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9njK0ACgkQNL8k5A2w/vzTLQCgtrhyZ3980Qgj1/vW1+k4h8s4 casAoIP2nW+n3ff1fxmERoS/ZtXKeL96 =HaXM -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 12:56:22 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 4B35B21E801A for ; Mon, 19 Mar 2012 12:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 0f+O+8kDSDLu for ; Mon, 19 Mar 2012 12:56:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C821E8013 for ; Mon, 19 Mar 2012 12:56:21 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2100340058 for ; Mon, 19 Mar 2012 14:09:00 -0600 (MDT) Message-ID: <4F678F64.9010308@stpeter.im> Date: Mon, 19 Mar 2012 13:56:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: normalization form 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: Mon, 19 Mar 2012 19:56:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've previously discussed what to do about the normalization form. In RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you can think of as the most aggressive normalization form since it finds matches when less aggressive forms don't; for details, see here: http://www.unicode.org/reports/tr15/ http://www.saint-andre.com/ietf/i18n-intro.pdf RFC 5198 recommends NFC as a general rule, and that's what IDNA2008 uses, too. In the past we've talked about possibly using NFD (which does not perform recomposition) instead of NFC. As I recall, the reasoning in favor of NFD was (1) servers don't really need to perform recomposition in order to compare JID parts, so we can save some processor cycles by using NFD instead of NFC, and (2) client interfaces can easily perform recomposition before showing JIDs to humans, if needed. The reasoning in favor of NFC was (1) everyone else is doing it, specifically we'll need to do it for domainparts when resolving them anyway, and (2) the processing savings of NFD are unproven. Other than oversimplifying, am I missing anything here? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve =7OZD -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:06:59 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 09D6921F87CB for ; Mon, 19 Mar 2012 13:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.693 X-Spam-Level: X-Spam-Status: No, score=-103.693 tagged_above=-999 required=5 tests=[AWL=0.906, 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 85-XqsfOTjmH for ; Mon, 19 Mar 2012 13:06:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8C21F87C7 for ; Mon, 19 Mar 2012 13:06:58 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A191840058 for ; Mon, 19 Mar 2012 14:19:36 -0600 (MDT) Message-ID: <4F6791E0.8040708@stpeter.im> Date: Mon, 19 Mar 2012 14:06:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: U-labels and A-labels in domainparts 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: Mon, 19 Mar 2012 20:06:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 6122bis currently specifies that each A-label in a domainpart SHOULD be converted to a U-label (for background, see RFC 5890). This means that we prefer U-labels (i.e., labels that can natively include most Unicode letters and digits), but we do not prohibit A-labels (i.e., labels that are not converted into the ASCII-compatible encoding via Punycode [RFC 3492]). This is consistent with both RFC 3920 and RFC 6122. Now, in IETF-speak, "SHOULD" basically means "you must do X unless you have a really good reason not to". So I wonder: what might be a really good reason to use A-labels instead of U-labels? Would it perhaps be better to tighten up the spec by saying that each internationalized label MUST be a U-label? What do we gain by allowing A-labels? How do existing implementations behave here? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nkeAACgkQNL8k5A2w/vwwpwCfcI5ynBICf/rqfTsQSP8QgPut zAsAn0mxEREe9BUhcjisDEvFhn7HBOey =vxj4 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:12:20 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 3E6F821F8822 for ; Mon, 19 Mar 2012 13:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 r15CWU4s706n for ; Mon, 19 Mar 2012 13:12:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9316A21F8817 for ; Mon, 19 Mar 2012 13:12:12 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D71340058 for ; Mon, 19 Mar 2012 14:24:51 -0600 (MDT) Message-ID: <4F67931B.6020204@stpeter.im> Date: Mon, 19 Mar 2012 14:12:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: codepoint width 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: Mon, 19 Mar 2012 20:12:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Currently, 6122bis is silent on the handling of full-width and half-width codepoints (these are common in certain Asian scripts), specifically on the mapping of such codepoints to their decomposition mappings. This might be an issue that we can handle at the PRECIS level, not the level of applications (like XMPP) that use PRECIS, and in fact it is discussed in this proposal: https://datatracker.ietf.org/doc/draft-yoneya-precis-mappings/ This WG needs to decide if it is comfortable with letting the PRECIS WG define the rules here, which we would simply re-use for XMPP. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nkxsACgkQNL8k5A2w/vzEHwCgzEX77m2r7St9YKfCxsjPe2IZ ZkwAoIFKe/xheiv+9c0FGGEdxKB43D/M =Y0bi -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:17:01 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 3C01F21E8013 for ; Mon, 19 Mar 2012 13:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 EAeZFwGc73E0 for ; Mon, 19 Mar 2012 13:17:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9647121E800C for ; Mon, 19 Mar 2012 13:17:00 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0FFCC40058 for ; Mon, 19 Mar 2012 14:29:38 -0600 (MDT) Message-ID: <4F67943B.4060304@stpeter.im> Date: Mon, 19 Mar 2012 14:16:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: error handing 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: Mon, 19 Mar 2012 20:17:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If I recall correctly, when we talked previously about improved handling of errors related to internationalization, we decided that we would use the error condition from RFC 6120, but that we might need to add more detail to the text or provide some more examples. If you disagree with that assessment, please say so. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nlDsACgkQNL8k5A2w/vyVIwCfXvBstBazh8u89m/d7aKJ65fv 8vQAn2Q52oVhYtAqreY3SXZuHF+MTPnv =Zi5H -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:24:16 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 5B26D21F87DB for ; Mon, 19 Mar 2012 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 Rz5uuABsTpoj for ; Mon, 19 Mar 2012 13:24:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AFC4621F87CF for ; Mon, 19 Mar 2012 13:24:15 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4205040058 for ; Mon, 19 Mar 2012 14:36:54 -0600 (MDT) Message-ID: <4F6795EE.2040707@stpeter.im> Date: Mon, 19 Mar 2012 14:24:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: account registration policies 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: Mon, 19 Mar 2012 20:24:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An XMPP server that allows account creation or user provisioning essentially acts as a kind of "registrar" for the localparts of JIDs. Therefore we might want to define recommended registration policies (e.g., prohibit mixed-script localparts). Currently 6122bis points to draft-ietf-precis-framework on this point, but the framework document doesn't say much: 1. An application service SHOULD define a policy that specifies the scripts or blocks of characters that the service will allow to be registered (e.g., in an account name) or stored (e.g., in a file name). Such a policy SHOULD be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service SHOULD forbid registration or storage of strings that contain characters from more than one script and to restrict registrations to characters drawn from a very small number of scripts (e.g., scripts that are well-understood by the administrators of the service, to improve manageability). Do we think that is sufficient? Do we want to say something stronger for XMPP account registration? And, if so, is 6122bis the right place to put such a recommendation? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nle4ACgkQNL8k5A2w/vzFeACg/Owgxj1QQ0eBdNIb/xU9OdaS 1IEAn3NmFYM2Zf4qHEU2mdfbDQY6r+Ik =Gz2O -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:49:39 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 439CF21F87A3 for ; Mon, 19 Mar 2012 13:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 wMKs0G-YQyqL for ; Mon, 19 Mar 2012 13:49:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B5E5121F879A for ; Mon, 19 Mar 2012 13:49:38 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 498D640058 for ; Mon, 19 Mar 2012 15:02:17 -0600 (MDT) Message-ID: <4F679BE0.9040007@stpeter.im> Date: Mon, 19 Mar 2012 14:49:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: enforcing the rules 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: Mon, 19 Mar 2012 20:49:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One of the failings of RFC 3920, and of RFC 6122 too, is that we didn't clearly specify which entities are responsible for enforcing the i18n rules... 1. Are clients responsible for preparing JIDs and JID parts before injecting them into the system? 2. Are servers responsible for verifying the correctness of any JID in any JID-slot (or only to/from addresses plus certain other slots)? 2a. Only over client-to-server connections? 2b. Also over server-to-server connections? Note that there are many places where JIDs can be injected (to/from addresses, roster items, vCard entries, privacy lists, etc. -- see http://tools.ietf.org/id/draft-saintandre-xmpp-i18n-03.txt for a semi-complete listing). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nm+AACgkQNL8k5A2w/vyeoQCeL4Bux376Eu0V178WXkoFrUXs KUMAn18jLSVjra9iQkGUq+4HxDDFZK04 =CKqs -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 13:49:51 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 462DA21E8029 for ; Mon, 19 Mar 2012 13:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 5T9pTkS+VobI for ; Mon, 19 Mar 2012 13:49:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D822821E801C for ; Mon, 19 Mar 2012 13:49:50 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A7B540058 for ; Mon, 19 Mar 2012 15:02:29 -0600 (MDT) Message-ID: <4F679BED.8040708@stpeter.im> Date: Mon, 19 Mar 2012 14:49:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP References: <4F678CAD.40209@stpeter.im> In-Reply-To: <4F678CAD.40209@stpeter.im> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis issues 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: Mon, 19 Mar 2012 20:49:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Done. If you know of more issues, please post them to the list. On 3/19/12 1:44 PM, Peter Saint-Andre wrote: > While working on slides about 6122bis, I've discovered more open > issues than I expected. To prime the pump, I'll send one email > message for each open issue that I see. Hopefully we can generate > some discussion beforehand and thus make good progress at the > meeting next week. > > Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nm+0ACgkQNL8k5A2w/vz8GACeMW56s5D3GQ1mO//lLUMVbtBB GL0AoMCk+M6ksVJ43Gu/Wykgu+j7kHQ9 =CJoi -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 14:15: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 19C8C21E801C for ; Mon, 19 Mar 2012 14:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 eIvn1X5QPOBK for ; Mon, 19 Mar 2012 14:15:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2D21E802C for ; Mon, 19 Mar 2012 14:15:55 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BA1D40058 for ; Mon, 19 Mar 2012 15:28:31 -0600 (MDT) Message-ID: <4F67A208.3070008@stpeter.im> Date: Mon, 19 Mar 2012 15:15:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> In-Reply-To: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 19 Mar 2012 21:15:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/19/12 9:49 AM, Ben Campbell wrote: >> http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01 As previously noted, that's draft-ietf-xmpp-6122bis-00. :) >> http://tools.ietf.org/html/draft-saintandre-precis-nickname-00 Here are slides (subject to change this week): http://www.saint-andre.com/ietf/ietf83-xmpp-6122bis.pdf http://www.saint-andre.com/ietf/ietf83-precis-nickname.pdf Feedback is welcome! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nogcACgkQNL8k5A2w/vwHQwCgspWww015afwW07sTMTY2fngC twEAoO4m2whdXC6oZ16qFgWkCaUh/2Ex =0eHq -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Mar 19 14:37: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 8FC5121E8044 for ; Mon, 19 Mar 2012 14:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=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 ZFeffUu29jI0 for ; Mon, 19 Mar 2012 14:37:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53121E8048 for ; Mon, 19 Mar 2012 14:37:23 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A256140058; Mon, 19 Mar 2012 15:50:01 -0600 (MDT) Message-ID: <4F67A711.3050004@stpeter.im> Date: Mon, 19 Mar 2012 15:37:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nobuo Ogashiwa References: <4F637525.1060506@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Group Subject: Re: [xmpp] SRV record extension 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: Mon, 19 Mar 2012 21:37:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nobuo, Matthew and I chatted about this topic after we both sent our email messages last week, and we realized that perhaps there are national differences in the availability of DNS registrars that support SRV records. Now it seems that this is true. In that case, I think that using XEP-0156 is the second-best solution as a fallback. In fact, using XEP-0156 is even mentioned in Section 3.2.2 of RFC 6120. Although we prefer not to put into a TXT record the same information that would normally be found in an SRV record, we might make an exception here (especially because it is indeed a fallback method). Peter On 3/18/12 11:30 PM, Nobuo Ogashiwa wrote: > Hello Peter, > > Thank you for your helpful comments. We will consider using > XEP-0156. > > There are some another view about TXT record as the substitutes > for SRV record, so I will consider such all opinion. > > However, I realized it might be in different situations for each > country that SRV records support status. Especially, in japan, TXT > record is supported by most of all famous japanese DNS provider to > support SPF, but SRV record is not supported by most of all famous > japanese DNS provider. We have summarized SRV record support status > in japanese famous DNS providers, please see > http://nlab.jp/japan-dns.pdf . > > Regards, Nobuo Ogashiwa > > 2012/3/17 Peter Saint-Andre : >> On 3/16/12 10:27 AM, Nobuo Ogashiwa wrote: >>> Dear all, >>> >>> We have submitted following I-D: >>> http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 >>> >>> >>> After the 2011/3/11 earthquake in japan, we are interested in >>> reliability and stability of XMPP-based systems. >>> >>> The RFC6120 defines that the XMPP server and client use SRV >>> record for reliability. However, most of standard libraries in >>> client OS like MacOS, Windows, Linux and *BSD does not support >>> SRV record resolution. Furthermore, many DNS hosting services >>> do not support SRV record registration. So that there are some >>> cases that we can not get a benefit of SRV record in the global >>> internet environment. >>> >>> So, we have proposed IQ message extensions to query and reply >>> multiple server hostnames in our I-D. If you want to know the >>> details of extensions, please see our I-D. >>> >>> In technically, the above problem can be solved by using TXT >>> record instead of SRV record (and also extensions we proposed >>> in our I-D). The TXT record solutions is just like following: >>> >>> TXT="sv1.example.com:5269:0:10,sv2.example.com:5269:10:10". >>> >>> We think this would be an alternative solution of the problem >>> we mentioned in the I-D. >>> >>> We think that maybe extensions we proposed in our I-D should >>> be published as not I-D but XEP. However, TXT record solution >>> I mentioned in this e-mail should be discussed not XSF but IETF >>> XMPP WG. >> >> Hello Ogashiwa-san! >> >> Why not use XEP-0156 ("Discovering Alternative XMPP Connection >> Methods")? >> >> http://xmpp.org/extensions/xep-0156.html >> >> I realize that XEP-0156 says "A domain SHOULD NOT present >> information in DNS TXT records that is available via the DNS SRV >> records defined in RFC 6120." However, it might make sense to >> relax that rule, or describe when it is appropriate to override >> the SHOULD NOT. >> >> Peter >> >> -- Peter Saint-Andre https://stpeter.im/ >> >> >> _______________________________________________ xmpp mailing >> list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9npxEACgkQNL8k5A2w/vxjVACgyUa9hLySLwQvXkpk7fmbQlJS gd8AoPuI+Ehhr15XhcvHradx+gM2zU86 =6PR6 -----END PGP SIGNATURE----- From dave@cridland.net Tue Mar 20 01:47: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 817F121F87DA for ; Tue, 20 Mar 2012 01:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_27=1] 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 r0wJWsdWR25m for ; Tue, 20 Mar 2012 01:47:22 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 2417921F87D6 for ; Tue, 20 Mar 2012 01:47:21 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BCE901168087; Tue, 20 Mar 2012 08:47:14 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfTrgZajD0AC; Tue, 20 Mar 2012 08:47:07 +0000 (GMT) Received: from com.flipdogsolutions (unknown [IPv6:2001:470:1f09:882:7c8f:bfbd:c988:59f2]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 9C6DB1168067; Tue, 20 Mar 2012 08:47:07 +0000 (GMT) Date: Tue, 20 Mar 2012 08:52:07 +0000 (GMT) From: dave@cridland.net To: Peter Saint-Andre ,XMPP Message-ID: In-Reply-To: <4F678F64.9010308@stpeter.im> References: <4F678F64.9010308@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1095871856.1332233527593" Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 08:47:23 -0000 ------=_Part_0_1095871856.1332233527593 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I think we should use NFC. I suspect that NFD would cause some friction, and the benefits are not clear to me. In general, I think we need compelling arguments to strike out on our own here. Sent from my android device. -----Original Message----- From: Peter Saint-Andre To: XMPP Sent: Mon, 19 Mar 2012 7:56 PM Subject: [xmpp] 6122bis: normalization form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've previously discussed what to do about the normalization form. In RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you can think of as the most aggressive normalization form since it finds matches when less aggressive forms don't; for details, see here: http://www.unicode.org/reports/tr15/ http://www.saint-andre.com/ietf/i18n-intro.pdf RFC 5198 recommends NFC as a general rule, and that's what IDNA2008 uses, too. In the past we've talked about possibly using NFD (which does not perform recomposition) instead of NFC. As I recall, the reasoning in favor of NFD was (1) servers don't really need to perform recomposition in order to compare JID parts, so we can save some processor cycles by using NFD instead of NFC, and (2) client interfaces can easily perform recomposition before showing JIDs to humans, if needed. The reasoning in favor of NFC was (1) everyone else is doing it, specifically we'll need to do it for domainparts when resolving them anyway, and (2) the processing savings of NFD are unproven. Other than oversimplifying, am I missing anything here? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve =7OZD -----END PGP SIGNATURE----- _______________________________________________ xmpp mailing list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp ------=_Part_0_1095871856.1332233527593 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think we should use NFC. I suspect that NFD would cause some friction, and the benefits are not clear to me.

In general, I think we need compelling arguments to strike out on our own here.

Sent from my android device.



-----Original Message-----
From: Peter Saint-Andre <stpeter@stpeter.im>
To: XMPP <xmpp@ietf.org>
Sent: Mon, 19 Mar 2012 7:56 PM
Subject: [xmpp] 6122bis: normalization form

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We've previously discussed what to do about the normalization form. In
RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you
can think of as the most aggressive normalization form since it finds
matches when less aggressive forms don't; for details, see here:

http://www.unicode.org/reports/tr15/

http://www.saint-andre.com/ietf/i18n-intro.pdf

RFC 5198 recommends NFC as a general rule, and that's what IDNA2008
uses, too.

In the past we've talked about possibly using NFD (which does not
perform recomposition) instead of NFC. As I recall, the reasoning in
favor of NFD was (1) servers don't really need to perform
recomposition in order to compare JID parts, so we can save some
processor cycles by using NFD instead of NFC, and (2) client
interfaces can easily perform recomposition before showing JIDs to
humans, if needed. The reasoning in favor of NFC was (1) everyone else
is doing it, specifically we'll need to do it for domainparts when
resolving them anyway, and (2) the processing savings of NFD are
unproven. Other than oversimplifying, am I missing anything here?

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K
NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve
=7OZD
-----END PGP SIGNATURE-----
_______________________________________________
xmpp mailing list
xmpp@ietf.org
https://www.ietf.org/mailman/listinfo/xmpp

------=_Part_0_1095871856.1332233527593-- From stpeter@stpeter.im Tue Mar 20 10:34:16 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 C451721F8518 for ; Tue, 20 Mar 2012 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 zrGqqqdFUZvA for ; Tue, 20 Mar 2012 10:34:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA3D21F8565 for ; Tue, 20 Mar 2012 10:34:15 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AAEF440058 for ; Tue, 20 Mar 2012 11:46:56 -0600 (MDT) Message-ID: <4F68BF96.5070001@stpeter.im> Date: Tue, 20 Mar 2012 11:34:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: protocol slots 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: Tue, 20 Mar 2012 17:34:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another possible issue... In http://tools.ietf.org/id/draft-saintandre-xmpp-i18n-03.txt I had a list of "protocol slots" for JIDs, localparts, and resourceparts (see Section 7). Would it be helpful to include a non-normative inventory of these protocol slots in 6122bis or elsewhere? This is mostly for the sake of implementers, and to give a flavor of the many places where clients and servers would need to prep or compare JIDs, localparts, and resourceparts. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ov5UACgkQNL8k5A2w/vxMjQCguLSRBdDqw+lB/Da93+7TCUMz dAUAoJNcT4NvJ5Pa00wO9oQFBKntrEpv =hHPg -----END PGP SIGNATURE----- From jhildebr@cisco.com Tue Mar 20 12:33:30 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 DF17F21F85CC for ; Tue, 20 Mar 2012 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2AfUXy9uQGA0 for ; Tue, 20 Mar 2012 12:33:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0676021F85C4 for ; Tue, 20 Mar 2012 12:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=2995; q=dns/txt; s=iport; t=1332272010; x=1333481610; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=Y0jpFl9QUFOs1sTGxqA/WXr4UJV3zfrFhYV2q8x/IAA=; b=EYc8t48qCwU+fyYakawdXdjL/SIIBNLgdxp5esG+aj/5yUwXFQPxtoAo 9z8ov/P1jBqzFtXZkEbQOyVhiIhcMPcpu6GEDSjCFjfr3OCH9gCgx5g2p d6PtuotuDDQpxSYY0EZM1AVcCv0DkZxYbkMQFjT5oJJ+dPlfNO6xKXeia E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADnaaE+tJV2d/2dsb2JhbABEtmSBB4IJAQEBAgEBAQEBDwEnAgExEAcGAQgRBAEBVigIAQEEARIJGYdjBQuYEp8wkQEEiFaNCY4/gWiDBg X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="68022120" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 20 Mar 2012 19:33:29 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2KJXTgZ003534; Tue, 20 Mar 2012 19:33:29 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 14:33:29 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 19:33:28 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 13:33:28 -0600 From: Joe Hildebrand To: , Peter Saint-Andre , XMPP Message-ID: Thread-Topic: [xmpp] 6122bis: normalization form Thread-Index: Ac0G0FMNtt9zYBqGg06wZZLFnDgGJw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 19:33:29.0341 (UTC) FILETIME=[53DA92D0:01CD06D0] Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 19:33:31 -0000 Recomposition is only useful for crappy font renderers that can't deal with the most popular combining characters, which don't really exist anymore. It can also decrease the size of a couple of JIDs very slightly on uncompressed streams, at the expense of: - added tables that need to be tracked for correctness - extravagant complexity to compress the tables to manageable size - annoyingly slowness in the implementations I've seen The argument against NFD is "status quo", which doesn't seem adequate at what amounts to our last chance to chance this stuff for the next decade or two. On 3/20/12 2:52 AM, "dave@cridland.net" wrote: > I think we should use NFC. I suspect that NFD would cause some friction, and > the benefits are not clear to me. > > In general, I think we need compelling arguments to strike out on our own > here. > > Sent from my android device. > > > > -----Original Message----- > From: Peter Saint-Andre > To: XMPP > Sent: Mon, 19 Mar 2012 7:56 PM > Subject: [xmpp] 6122bis: normalization form > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We've previously discussed what to do about the normalization form. In > RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you > can think of as the most aggressive normalization form since it finds > matches when less aggressive forms don't; for details, see here: > > http://www.unicode.org/reports/tr15/ > > http://www.saint-andre.com/ietf/i18n-intro.pdf > > RFC 5198 recommends NFC as a general rule, and that's what IDNA2008 > uses, too. > > In the past we've talked about possibly using NFD (which does not > perform recomposition) instead of NFC. As I recall, the reasoning in > favor of NFD was (1) servers don't really need to perform > recomposition in order to compare JID parts, so we can save some > processor cycles by using NFD instead of NFC, and (2) client > interfaces can easily perform recomposition before showing JIDs to > humans, if needed. The reasoning in favor of NFC was (1) everyone else > is doing it, specifically we'll need to do it for domainparts when > resolving them anyway, and (2) the processing savings of NFD are > unproven. Other than oversimplifying, am I missing anything here? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K > NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve > =7OZD > -----END PGP SIGNATURE----- > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp -- Joe Hildebrand From mwild1@gmail.com Tue Mar 20 12:35:16 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 F2B0321F85C4 for ; Tue, 20 Mar 2012 12:35:15 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VSfIlCQcCuVA for ; Tue, 20 Mar 2012 12:35:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7E2321F85CC for ; Tue, 20 Mar 2012 12:35:12 -0700 (PDT) Received: by iazz13 with SMTP id z13so484719iaz.31 for ; Tue, 20 Mar 2012 12:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lXwJuC/stm1RJlXmnJVMggK/PwOcB+FP+/PbtGFmSpM=; b=cEOytVCSwTaKV2l3h6lGZEbVJNJ3w64gdgAxm72TPTJTwbsyrPWKd5KRlRZQnzD9V3 iXkHRez2nA9UJvxLvJ0seto/ywXpk6l0dkT3eljyfk6ttRjkmXqkH8M1vCL4RBz4kHYn S4rXS1+l7MMK1VuR3IldnTeZ2EE75dDYHFE6dqjlfZH/+Mq5t3O8RtuTi2bdMkiddp36 yegD6LgtG1ocpLgBF6B6nD51JULSqxeQKJblk1AkfATKQwcQlsSJOxCTW5WdYkAQuEZS YEL1+4CT+dE+0IpwH6XFLTmuXEcwuqyvxolGy7RfDQkylGVSMV5lY870IBqux2kPd00y JkXw== Received: by 10.50.181.194 with SMTP id dy2mr853021igc.48.1332272112616; Tue, 20 Mar 2012 12:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.68 with HTTP; Tue, 20 Mar 2012 12:34:52 -0700 (PDT) In-Reply-To: References: <4F678F64.9010308@stpeter.im> From: Matthew Wild Date: Tue, 20 Mar 2012 19:34:52 +0000 Message-ID: To: dave@cridland.net Content-Type: text/plain; charset=UTF-8 Cc: XMPP Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 19:35:16 -0000 On 20 March 2012 08:52, wrote: > I think we should use NFC. I suspect that NFD would cause some friction, and > the benefits are not clear to me. > > In general, I think we need compelling arguments to strike out on our own > here. Based on Peter's email (which incidentally is below this reply...) I agree. If the main reason in favour of NFD is performance - as long as NFC isn't worse than what we do now (and I believe it isn't) then I think it's fine. Stringprep (if comparable) is not really a performance bottleneck when done right. Regards, Matthew > -----Original Message----- > From: Peter Saint-Andre > To: XMPP > Sent: Mon, 19 Mar 2012 7:56 PM > Subject: [xmpp] 6122bis: normalization form > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We've previously discussed what to do about the normalization form. In > RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you > can think of as the most aggressive normalization form since it finds > matches when less aggressive forms don't; for details, see here: > > http://www.unicode.org/reports/tr15/ > > http://www.saint-andre.com/ietf/i18n-intro.pdf > > RFC 5198 recommends NFC as a general rule, and that's what IDNA2008 > uses, too. > > In the past we've talked about possibly using NFD (which does not > perform recomposition) instead of NFC. As I recall, the reasoning in > favor of NFD was (1) servers don't really need to perform > recomposition in order to compare JID parts, so we can save some > processor cycles by using NFD instead of NFC, and (2) client > interfaces can easily perform recomposition before showing JIDs to > humans, if needed. The reasoning in favor of NFC was (1) everyone else > is doing it, specifically we'll need to do it for domainparts when > resolving them anyway, and (2) the processing savings of NFD are > unproven. Other than oversimplifying, am I missing anything here? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K > NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve > =7OZD > -----END PGP SIGNATURE----- From jhildebr@cisco.com Tue Mar 20 12:36:36 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 EDB7721F85CC for ; Tue, 20 Mar 2012 12:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 p2XLPk1yM0Kj for ; Tue, 20 Mar 2012 12:36:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 112B221F85C4 for ; Tue, 20 Mar 2012 12:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=3221; q=dns/txt; s=iport; t=1332272196; x=1333481796; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=cY4s+aF8oAqyZ3U28Iks6oZ1VY78URXNSxwR2AAzPNc=; b=Hq0CZngPY+2PAV3LzOmeEAt0Ss188EO5DWc15Q94ik0r++wA1zUQXu9W sCgHEzdYA57e1IJ6na5m3GOhPcjtM121lkJU3IQawYAt5z2Qq3DUZAPRE 1/AmgdYLMlCXn+9NtLCXXSkcqd6YEpU3p0/n/YWg5HzZsshdB/sCoFWs6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJjbaE+tJXG+/2dsb2JhbABEtmSBB4IJAQEBAgEBAQEBDwEnAgExEAcGAQgRBAEBAVUoCAEBBBMJGYdjBQuWZ4EnnzORAQSIVo0Jjj+BaIMG X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="68018542" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2012 19:36:35 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2KJaZiN013029 for ; Tue, 20 Mar 2012 19:36:35 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 14:36:35 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 19:36:35 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 13:36:34 -0600 From: Joe Hildebrand To: XMPP Message-ID: Thread-Topic: [xmpp] 6122bis: normalization form Thread-Index: Ac0G0FMNtt9zYBqGg06wZZLFnDgGJwAAG7f8 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 19:36:35.0570 (UTC) FILETIME=[C2DADD20:01CD06D0] Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 19:36:37 -0000 Note: that was intended to be marked as: Hat: individual On 3/20/12 1:33 PM, "Joe Hildebrand" wrote: > Recomposition is only useful for crappy font renderers that can't deal with > the most popular combining characters, which don't really exist anymore. It > can also decrease the size of a couple of JIDs very slightly on uncompressed > streams, at the expense of: > > - added tables that need to be tracked for correctness > - extravagant complexity to compress the tables to manageable size > - annoyingly slowness in the implementations I've seen > > The argument against NFD is "status quo", which doesn't seem adequate at > what amounts to our last chance to chance this stuff for the next decade or > two. > > On 3/20/12 2:52 AM, "dave@cridland.net" wrote: > >> I think we should use NFC. I suspect that NFD would cause some friction, and >> the benefits are not clear to me. >> >> In general, I think we need compelling arguments to strike out on our own >> here. >> >> Sent from my android device. >> >> >> >> -----Original Message----- >> From: Peter Saint-Andre >> To: XMPP >> Sent: Mon, 19 Mar 2012 7:56 PM >> Subject: [xmpp] 6122bis: normalization form >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> We've previously discussed what to do about the normalization form. In >> RFC 3920 and RFC 6122, we used normalization form KC (NFKC), which you >> can think of as the most aggressive normalization form since it finds >> matches when less aggressive forms don't; for details, see here: >> >> http://www.unicode.org/reports/tr15/ >> >> http://www.saint-andre.com/ietf/i18n-intro.pdf >> >> RFC 5198 recommends NFC as a general rule, and that's what IDNA2008 >> uses, too. >> >> In the past we've talked about possibly using NFD (which does not >> perform recomposition) instead of NFC. As I recall, the reasoning in >> favor of NFD was (1) servers don't really need to perform >> recomposition in order to compare JID parts, so we can save some >> processor cycles by using NFD instead of NFC, and (2) client >> interfaces can easily perform recomposition before showing JIDs to >> humans, if needed. The reasoning in favor of NFC was (1) everyone else >> is doing it, specifically we'll need to do it for domainparts when >> resolving them anyway, and (2) the processing savings of NFD are >> unproven. Other than oversimplifying, am I missing anything here? >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk9nj2QACgkQNL8k5A2w/vzUrACaA7enXXCEy5EZDZggGtMJak/K >> NGEAn2TgLDA+cjhVIZOnV5dKiRJhLcve >> =7OZD >> -----END PGP SIGNATURE----- >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp -- Joe Hildebrand From jhildebr@cisco.com Tue Mar 20 12:38: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 ED81A21F85CC for ; Tue, 20 Mar 2012 12:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Uk3-M4yR1k94 for ; Tue, 20 Mar 2012 12:38:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E659F21F85C4 for ; Tue, 20 Mar 2012 12:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=500; q=dns/txt; s=iport; t=1332272283; x=1333481883; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=hnx8uJbb+E25ta4zdV6rLB8kYLdRwcYnfbneFlcpg08=; b=AJuGwM9YwwRQeOtZPL/Pc2JhLCGpF86aIYVaGPbB2Fe9pFR7pXoRT7U1 QaPBErSDowBF7T4sGjVHvLQoQGSjmZqeuJFTeKeygvPw61w9TKESyvOCR dYlR6WAA5jTaTIMAxJ+YpXrVwSE6VIzdlMaXtnMceUCzZwqItrtkpM/y4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAATcaE+tJV2a/2dsb2JhbABEtmSBB4IJAQEBAwESAScCATwFDQEIDlk2AQEEAQ0FIodjBZgZnzOJbIcVBIhWjQmLLoMRgWiDBoE9 X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="68007280" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 20 Mar 2012 19:38:02 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2KJc2MC016969; Tue, 20 Mar 2012 19:38:02 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 14:38:02 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 19:38:01 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 13:38:00 -0600 From: Joe Hildebrand To: Matthew Wild , Message-ID: Thread-Topic: [xmpp] 6122bis: normalization form Thread-Index: Ac0G0PUtNcgxTmpPK0mCX5Pob8C6bg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 19:38:02.0307 (UTC) FILETIME=[F68DE130:01CD06D0] Cc: XMPP Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 19:38:04 -0000 On 3/20/12 1:34 PM, "Matthew Wild" wrote: > Based on Peter's email (which incidentally is below this reply...) I > agree. If the main reason in favour of NFD is performance - as long as > NFC isn't worse than what we do now (and I believe it isn't) then I > think it's fine. Stringprep (if comparable) is not really a > performance bottleneck when done right. I'll argue that it's easy to get wrong; it *is* a bottleneck in some of our software. -- Joe Hildebrand From jhildebr@cisco.com Tue Mar 20 12:39:12 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 EB6A221F8592 for ; Tue, 20 Mar 2012 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] 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 SKsOUWhiDALV for ; Tue, 20 Mar 2012 12:39:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C68AE21F8532 for ; Tue, 20 Mar 2012 12:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1702; q=dns/txt; s=iport; t=1332272349; x=1333481949; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=pJxFvWxgsGGZn2C7ldP/vhR+wuoSLoL9f570l7i84oI=; b=J3b+wjgfNG09UWu2A9Wtv36hzSv0+snkpjADlq4NR473Bg+oo6ToxF0A MfrQSArKIA4t8JkWv13p9PfTnhCCsa3+yGrUTYTwm6z/Khtv0q1Lk3nTy UlvCAO6T7WvIrxfm8oa+NxvYbmQPUW9EcbOe+GBpw0towgHk8O4rb9Coi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAATcaE+tJV2d/2dsb2JhbABEtmSBB4ILAQQBAQEPAScCAS8CCBUBCG0wAQEEARIih2gLmA6fM5EBBIhWjQmOP4FogwY X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="68023393" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 20 Mar 2012 19:39:08 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2KJd8OA006649; Tue, 20 Mar 2012 19:39:08 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 14:39:08 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 19:39:07 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 13:39:07 -0600 From: Joe Hildebrand To: Peter Saint-Andre , XMPP Message-ID: Thread-Topic: [xmpp] 6122bis: U-labels and A-labels in domainparts Thread-Index: Ac0G0R0dk00h8sOcSU6AZMMbzOPqew== In-Reply-To: <4F6791E0.8040708@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 19:39:08.0189 (UTC) FILETIME=[1DD2ACD0:01CD06D1] Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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: Tue, 20 Mar 2012 19:39:13 -0000 Hat=individual Do we specify how to compare U- and A- encodings of what, to humans, probably mean the same thing? If not, I'd argue we should just pick U-labels and have a single mechanism for comparison. On 3/19/12 2:06 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 6122bis currently specifies that each A-label in a domainpart SHOULD > be converted to a U-label (for background, see RFC 5890). This means > that we prefer U-labels (i.e., labels that can natively include most > Unicode letters and digits), but we do not prohibit A-labels (i.e., > labels that are not converted into the ASCII-compatible encoding via > Punycode [RFC 3492]). This is consistent with both RFC 3920 and RFC > 6122. Now, in IETF-speak, "SHOULD" basically means "you must do X > unless you have a really good reason not to". So I wonder: what might > be a really good reason to use A-labels instead of U-labels? Would it > perhaps be better to tighten up the spec by saying that each > internationalized label MUST be a U-label? What do we gain by allowing > A-labels? How do existing implementations behave here? > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9nkeAACgkQNL8k5A2w/vwwpwCfcI5ynBICf/rqfTsQSP8QgPut > zAsAn0mxEREe9BUhcjisDEvFhn7HBOey > =vxj4 > -----END PGP SIGNATURE----- > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp -- Joe Hildebrand From jhildebr@cisco.com Tue Mar 20 12:44:05 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 352C821F84F0 for ; Tue, 20 Mar 2012 12:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 33ei2hgLlAaD for ; Tue, 20 Mar 2012 12:44:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE321F84EC for ; Tue, 20 Mar 2012 12:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1149; q=dns/txt; s=iport; t=1332272644; x=1333482244; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=/dhFRO8RNdBo3XkLhMXIkKEKSCz5IQK/25fmYKOgbr4=; b=CxWtbWtpo2jSkBkB7GLkD3djL/0LpC5GgGGTdxV0hsrbKj9JynZKBDzb o9+YbrbB/iZ3ecPlrtQi+iLnfUuXLfDm0jw+7zjnldqh2t4+pKLiZojPi dgrZmpNyCm+sE+wAFegbvudaROQTv5Tj2DKp7F5WPMLgKfO8K9fqjtsk9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKvcaE+tJXG//2dsb2JhbABDtm2BB4IJAQEBAwESAScCAUENAQiBHQEBBAESIodjBQufTJdNkQEEiFaNCY4/gWiDBg X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="67988576" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 20 Mar 2012 19:44:04 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KJi4oO032588; Tue, 20 Mar 2012 19:44:04 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 14:44:03 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 19:44:03 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 13:44:03 -0600 From: Joe Hildebrand To: Peter Saint-Andre , XMPP Message-ID: Thread-Topic: [xmpp] 6122bis: enforcing the rules Thread-Index: Ac0G0c2LVBzwGntTkEGAWwSbTHb1EA== In-Reply-To: <4F679BE0.9040007@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 19:44:03.0921 (UTC) FILETIME=[CE17CC10:01CD06D1] Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 19:44:05 -0000 Hat: individual On 3/19/12 2:49 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the failings of RFC 3920, and of RFC 6122 too, is that we > didn't clearly specify which entities are responsible for enforcing > the i18n rules... > > 1. Are clients responsible for preparing JIDs and JID parts before > injecting them into the system? Particularly if we move to NFD, this SHOULD happen, since servers can check for NFD-validity without decomposing/recomposing if the client puts the JID in NFD first. > 2. Are servers responsible for verifying the correctness of any JID in > any JID-slot (or only to/from addresses plus certain other slots)? > > 2a. Only over client-to-server connections? > > 2b. Also over server-to-server connections? I'd be ok with MUST at all identified JID-slots. > Note that there are many places where JIDs can be injected (to/from > addresses, roster items, vCard entries, privacy lists, etc. -- see > http://tools.ietf.org/id/draft-saintandre-xmpp-i18n-03.txt for a > semi-complete listing). -- Joe Hildebrand From mwild1@gmail.com Tue Mar 20 13:46:55 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 D370C21F861B for ; Tue, 20 Mar 2012 13:46:55 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SeBKT6ph+-6U for ; Tue, 20 Mar 2012 13:46:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7521F860F for ; Tue, 20 Mar 2012 13:46:55 -0700 (PDT) Received: by iazz13 with SMTP id z13so570066iaz.31 for ; Tue, 20 Mar 2012 13:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sZer5Ad8t5tQmEib9UgxKwhZak4nlfonGtoWpQ0U6OI=; b=M+gdjX32geUnMglxV1mEoFE1syob0KSCNOs1vl/AfHWef0bfx+flczco8eQzHASrgj q3ycuTpRHZ23H6dzlXzRFC8KfIm1qVwwMmO8U3RsjYY7U3WQLnc2iXhlQ6AYA/bJS7a3 Fxh4Nr1Dv/8qWDGApu+7fn2GnoISikExGboFgEuN29xa08KhBb5dgVv60umUYgH9fiZR ITNpyC3eHePvxLMb3V+ZNGI0Th173SYCMtK+YyOCkNBPzWtGGlSQPzQ3dQctRlIKEnoa UvgDScjtnSYbhcRmb1DQAT0PINwR/vM2W7huiBCEHbxwcAzK12s3oA0rZDkzxJ9qC9UG p3gw== Received: by 10.50.202.105 with SMTP id kh9mr9912151igc.68.1332276414944; Tue, 20 Mar 2012 13:46:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.68 with HTTP; Tue, 20 Mar 2012 13:46:34 -0700 (PDT) In-Reply-To: <4F679BE0.9040007@stpeter.im> References: <4F679BE0.9040007@stpeter.im> From: Matthew Wild Date: Tue, 20 Mar 2012 20:46:34 +0000 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 20:46:55 -0000 On 19 March 2012 20:49, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the failings of RFC 3920, and of RFC 6122 too, is that we > didn't clearly specify which entities are responsible for enforcing > the i18n rules... > > 1. Are clients responsible for preparing JIDs and JID parts before > injecting them into the system? > Currently - no. Simple clients, etc. I'm not against changing this if we can still keep it simple for clients (such as having available a standard library like libidn supporting everything, most clients need this already for IDNA). However if the server has to check validity anyway, I don't see much harm in the current situation where it can simply inform the client when a JID is wrong. I don't see validity checks in servers going away - whatever those checks may be. > 2. Are servers responsible for verifying the correctness of any JID in > any JID-slot (or only to/from addresses plus certain other slots)? I'd say any within the core XMPP specs at least (and any XEPs that deem it necessary). Most slots match to/from addresses at some point. > 2a. Only over client-to-server connections? > > 2b. Also over server-to-server connections? > I think the above two are pretty tied - the question is whether we want to allow for site-specific policies, thereby skipping checks on stanzas from clients destined for remote servers. I would suggest not cater for this (we currently don't). Regards, Matthew From dave@cridland.net Tue Mar 20 14:00:57 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 27FAD21F8622 for ; Tue, 20 Mar 2012 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_27=1] 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 1qReyNtSs3H9 for ; Tue, 20 Mar 2012 14:00:34 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D221F85D9 for ; Tue, 20 Mar 2012 14:00:33 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 3DE361168087; Tue, 20 Mar 2012 21:00:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZEoMjV+t+ne; Tue, 20 Mar 2012 21:00:23 +0000 (GMT) Received: from com.flipdogsolutions (94.197.198.44.threembb.co.uk [94.197.198.44]) by peirce.dave.cridland.net (Postfix) with ESMTPA id CF8101168067; Tue, 20 Mar 2012 21:00:21 +0000 (GMT) Date: Tue, 20 Mar 2012 21:05:43 +0000 (GMT) From: dave@cridland.net To: Matthew Wild ,Peter Saint-Andre Message-ID: In-Reply-To: References: <4F679BE0.9040007@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1093490712.1332277544054" Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 21:00:57 -0000 ------=_Part_1_1093490712.1332277544054 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I'm wondering what is actually required for interoperability, here. The minimum, it seems to me, is actually pretty low, but requiring that jids sent to clients be normalized seems a reasonable addition - it means a simple client could avoid knowing about normalization at all. The minimum is that any jid comparisons MUST occur on normalized jids. I can't think of anything else. Sent from my android device. -----Original Message----- From: Matthew Wild To: Peter Saint-Andre Cc: XMPP Sent: Tue, 20 Mar 2012 8:46 PM Subject: Re: [xmpp] 6122bis: enforcing the rules On 19 March 2012 20:49, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the failings of RFC 3920, and of RFC 6122 too, is that we > didn't clearly specify which entities are responsible for enforcing > the i18n rules... > > 1. Are clients responsible for preparing JIDs and JID parts before > injecting them into the system? > Currently - no. Simple clients, etc. I'm not against changing this if we can still keep it simple for clients (such as having available a standard library like libidn supporting everything, most clients need this already for IDNA). However if the server has to check validity anyway, I don't see much harm in the current situation where it can simply inform the client when a JID is wrong. I don't see validity checks in servers going away - whatever those checks may be. > 2. Are servers responsible for verifying the correctness of any JID in > any JID-slot (or only to/from addresses plus certain other slots)? I'd say any within the core XMPP specs at least (and any XEPs that deem it necessary). Most slots match to/from addresses at some point. > 2a. Only over client-to-server connections? > > 2b. Also over server-to-server connections? > I think the above two are pretty tied - the question is whether we want to allow for site-specific policies, thereby skipping checks on stanzas from clients destined for remote servers. I would suggest not cater for this (we currently don't). Regards, Matthew _______________________________________________ xmpp mailing list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp ------=_Part_1_1093490712.1332277544054 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I'm wondering what is actually required for interoperability, here.

The minimum, it seems to me, is actually pretty low, but requiring that jids sent to clients be normalized seems a reasonable addition - it means a simple client could avoid knowing about normalization at all.

The minimum is that any jid comparisons MUST occur on normalized jids. I can't think of anything else.

Sent from my android device.



-----Original Message-----
From: Matthew Wild <mwild1@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Cc: XMPP <xmpp@ietf.org>
Sent: Tue, 20 Mar 2012 8:46 PM
Subject: Re: [xmpp] 6122bis: enforcing the rules

On 19 March 2012 20:49, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> One of the failings of RFC 3920, and of RFC 6122 too, is that we
> didn't clearly specify which entities are responsible for enforcing
> the i18n rules...
>
> 1. Are clients responsible for preparing JIDs and JID parts before
> injecting them into the system?
>

Currently - no. Simple clients, etc.

I'm not against changing this if we can still keep it simple for
clients (such as having available a standard library like libidn
supporting everything, most clients need this already for IDNA).

However if the server has to check validity anyway, I don't see much
harm in the current situation where it can simply inform the client
when a JID is wrong. I don't see validity checks in servers going away
- whatever those checks may be.

> 2. Are servers responsible for verifying the correctness of any JID in
> any JID-slot (or only to/from addresses plus certain other slots)?

I'd say any within the core XMPP specs at least (and any XEPs that
deem it necessary). Most slots match to/from addresses at some point.

> 2a. Only over client-to-server connections?
>
> 2b. Also over server-to-server connections?
>

I think the above two are pretty tied - the question is whether we
want to allow for site-specific policies, thereby skipping checks on
stanzas from clients destined for remote servers. I would suggest not
cater for this (we currently don't).

Regards,
Matthew
_______________________________________________
xmpp mailing list
xmpp@ietf.org
https://www.ietf.org/mailman/listinfo/xmpp

------=_Part_1_1093490712.1332277544054-- From stpeter@stpeter.im Tue Mar 20 14:41:13 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 8719E21E8017 for ; Tue, 20 Mar 2012 14:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 HGpGkz9PYIO4 for ; Tue, 20 Mar 2012 14:41:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1B421E8015 for ; Tue, 20 Mar 2012 14:41:12 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BAD240058; Tue, 20 Mar 2012 15:53:53 -0600 (MDT) Message-ID: <4F68F977.8000404@stpeter.im> Date: Tue, 20 Mar 2012 15:41:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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: Tue, 20 Mar 2012 21:41:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 1:39 PM, Joe Hildebrand wrote: > Hat=individual > > Do we specify how to compare U- and A- encodings of what, to > humans, probably mean the same thing? Well, I think we'd need to compare U-to-U or A-to-A (if a machine has labels in both forms it would need to translate them all to U or A before performing its comparison operations). Or do you mean comparing U to user expectations and A to user expectations? It's not clear to me exactly what that means -- machines can compare U-to-U or A-to-A, but they don't know about things that might have meaning to humans. We could call that the inside-of-the-mind problem, which is the converse of the side-of-the-bus problem. :) > If not, I'd argue we should just pick U-labels and have a single > mechanism for comparison. Having a single mechanism does simplify matters. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9o+XYACgkQNL8k5A2w/vweGgCfbP3LOPzrYL1H66eG4oBt1rcu jq0AniAWPCgTDhMPx/nLpo6o416Jbjc4 =EvGc -----END PGP SIGNATURE----- From jhildebr@cisco.com Tue Mar 20 14:44:13 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 BED5521E801A for ; Tue, 20 Mar 2012 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.799 X-Spam-Level: X-Spam-Status: No, score=-10.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YpTS6jdiQOe7 for ; Tue, 20 Mar 2012 14:44:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0921E8015 for ; Tue, 20 Mar 2012 14:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1747; q=dns/txt; s=iport; t=1332279853; x=1333489453; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=OFS/stq/JwOGV95VCSav0I5IqivfaAjYCKaBU/9WnYU=; b=Y7bWPSmA7HFQ+znD3ylk6Dv4tqgr2RsQn9GsACzmK+TiOr23d8KW1ZWY dJ3vvOWw4VJjREk3gWx/d7qE/HWqnr2I6N+zckH6J3Jo7IbAm3SOn1UX9 na/Jtip+Zf8sRQnh6PBBW13xv3y/bB2cpfMJHIOGLpL1ixZ6vE3ip9RcX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEz5aE+tJV2b/2dsb2JhbABEtmSBB4IJAQEBBBIBJwIBPBIBCBiBBQEBBA4FIodol2yfMZEBBIhWjQmOP4FogwY X-IronPort-AV: E=Sophos;i="4.73,620,1325462400"; d="scan'208";a="68041547" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 20 Mar 2012 21:44:12 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KLiC1k021789; Tue, 20 Mar 2012 21:44:12 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 16:44:12 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 21:44:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 15:44:11 -0600 From: Joe Hildebrand To: Peter Saint-Andre Message-ID: Thread-Topic: [xmpp] 6122bis: U-labels and A-labels in domainparts Thread-Index: Ac0G4pXYTp3ql/UgeUOtjZwfQLfrMA== In-Reply-To: <4F68F977.8000404@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 21:44:12.0504 (UTC) FILETIME=[96BE4580:01CD06E2] Cc: XMPP Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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: Tue, 20 Mar 2012 21:44:13 -0000 I was thinking we could define a heuristic to determine that a label was a punycoded A-label, and specify that it had to be canonicalized into a U-label (then nameprep-equivalent canonicalized) before comparison with another label. However, that sounds like a PITA to specify and implement, so I'd rather we just say they're always U-labels. On 3/20/12 3:41 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/20/12 1:39 PM, Joe Hildebrand wrote: >> Hat=individual >> >> Do we specify how to compare U- and A- encodings of what, to >> humans, probably mean the same thing? > > Well, I think we'd need to compare U-to-U or A-to-A (if a machine has > labels in both forms it would need to translate them all to U or A > before performing its comparison operations). Or do you mean comparing > U to user expectations and A to user expectations? It's not clear to > me exactly what that means -- machines can compare U-to-U or A-to-A, > but they don't know about things that might have meaning to humans. We > could call that the inside-of-the-mind problem, which is the converse > of the side-of-the-bus problem. :) > >> If not, I'd argue we should just pick U-labels and have a single >> mechanism for comparison. > > Having a single mechanism does simplify matters. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9o+XYACgkQNL8k5A2w/vweGgCfbP3LOPzrYL1H66eG4oBt1rcu > jq0AniAWPCgTDhMPx/nLpo6o416Jbjc4 > =EvGc > -----END PGP SIGNATURE----- -- Joe Hildebrand From stpeter@stpeter.im Tue Mar 20 14:46:36 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 2519A21E801E for ; Tue, 20 Mar 2012 14:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 3oixuIj7aBmB for ; Tue, 20 Mar 2012 14:46:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A958F21E8015 for ; Tue, 20 Mar 2012 14:46:35 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 70D9440058; Tue, 20 Mar 2012 15:59:17 -0600 (MDT) Message-ID: <4F68FABA.4050904@stpeter.im> Date: Tue, 20 Mar 2012 15:46:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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: Tue, 20 Mar 2012 21:46:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 3:44 PM, Joe Hildebrand wrote: > I was thinking we could define a heuristic to determine that a > label was a punycoded A-label, and specify that it had to be > canonicalized into a U-label (then nameprep-equivalent > canonicalized) before comparison with another label. However, that > sounds like a PITA to specify and implement, so I'd rather we just > say they're always U-labels. I think IDNA2008 might define such a heuristic, but I tend to agree that if we can move from SHOULD to MUST on U-labels then we can avoid that madness. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9o+rkACgkQNL8k5A2w/vxhgQCfZ2mnIdOPp3pc0FepX2wR55PJ w5MAoJpGmIwwhxUmp1sh2tIjlNutSDW7 =OsFR -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Mar 20 14:54:41 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 E18B421F8555 for ; Tue, 20 Mar 2012 14:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.691 X-Spam-Level: X-Spam-Status: No, score=-103.691 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, GB_I_INVITATION=-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 U4HstzBd848H for ; Tue, 20 Mar 2012 14:54:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E54C021F854A for ; Tue, 20 Mar 2012 14:54:40 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7ACFF4005B; Tue, 20 Mar 2012 16:07:22 -0600 (MDT) Message-ID: <4F68FC9E.4000607@stpeter.im> Date: Tue, 20 Mar 2012 15:54:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 21:54:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 1:44 PM, Joe Hildebrand wrote: > Hat: individual > > On 3/19/12 2:49 PM, "Peter Saint-Andre" > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> One of the failings of RFC 3920, and of RFC 6122 too, is that we >> didn't clearly specify which entities are responsible for >> enforcing the i18n rules... >> >> 1. Are clients responsible for preparing JIDs and JID parts >> before injecting them into the system? > > Particularly if we move to NFD, this SHOULD happen, since servers > can check for NFD-validity without decomposing/recomposing if the > client puts the JID in NFD first. > > >> 2. Are servers responsible for verifying the correctness of any >> JID in any JID-slot (or only to/from addresses plus certain other >> slots)? >> >> 2a. Only over client-to-server connections? >> >> 2b. Also over server-to-server connections? > > I'd be ok with MUST at all identified JID-slots. Just so we're all aware, there are a lot of JID-slots. :) Here is the old text I had in draft-saintandre-xmpp-i18n... ### 7. XMPP Protocol Slots IDNA2008 defined the concept of a "domain name slot", i.e., "a protocol element or a function argument or a return value (and so on) explicitly designated for carrying a domain name" (Section 2.3.2.6 of [RFC5890]). Similarly, the XMPP community can define the concepts of a "JID slot", a "localpart slot", and a "resourcepart slot" (and might re-use the concepts of a "nameything slot", "wordything slot", and "stringything slot" from PRECIS specifications). The community has yet to determine the full inventory of such slots. However, the following subsections provide a start at such an inventory. 7.1. JID Slot In XMPP systems, JabberIDs can appear in at least the following slots: o Core [RFC6120]: the 'from' and 'to' stream attributes; the 'from' and 'to' stanza attributes. o IM [RFC6121]: the 'jid' attribute of the roster element. o Privacy Lists [RFC3921], [XEP-0016]: the 'value' attribute of the element when the value of the 'type' attribute is "jid". o Data Forms [XEP-0004]: the element when the 'type' attribute is "jid-single" or "jid-multi". o Flexible Offline Message Retrieval [XEP-0013]: the 'jid' attribute of the element. o Service Discovery [XEP-0030]: the 'jid' attribute of the element. o Extended Stanza Addressing [XEP-0033]: the 'jid' attribute of the
element. o Multi-User Chat [XEP-0045]: the 'actor' child of the element; the 'jid' attribute of the element; the 'from' and 'to' attributes of the and elements; the 'jid' attribute of the element. o Bookmarks [XEP-0048]: the 'jid' attribute of the element. o vCards [XEP-0054]: the of the element. o Jabber Search [XEP-0055]: the 'jid' attribute of the element. o Publish-Subscribe [XEP-0060]: the 'jid' attribute of the , , , , and elements; the 'publisher' attribute of the element. o SOCKS5 Bytestreams [XEP-0065]: the 'jid' attribute of the and elements. o Advanced Message Processing [XEP-0079]: the 'from' and 'to' attributes of the element. o Jabber Component Protocol [XEP-0114]: the 'from' and 'to' attributes of the , , and elements. o Message Archiving [XEP-0136]: the 'with' attribute of the , , and elements. o Roster Item Exchange [XEP-0144]: the 'jid' attribute of the element. o Jingle [XEP-0166]: the 'initiator' and 'responder' attributes of the element. o Delayed Delivery [XEP-0203]: the 'from' attribute of the element. o Simple Communications Blocking [XEP-0191]: the 'jid' attribute of the element. o Server Dialback [RFC3921], [XEP-0220]: the 'from' and 'to' attributes of the and elements. o Direct MUC Invitations [XEP-0249]: the 'jid' attribute of the element. 7.2. Localpart Slot In XMPP systems, localparts can appear in at least the following slots: o Multi-User Chat [XEP-0045]: the element. o In-Band Registration [XEP-0077]: the element. 7.3. Resourcepart Slot In XMPP systems, resourceparts can appear in at least the following slots: o Core [RFC6120]: the child of the element. o Multi-User Chat [XEP-0045]: the 'nick' attribute of the element. o Bookmarks [XEP-0048]: the 'nick' attribute of the element. o Jabber Search [XEP-0055]: the 'nick' attribute of the and elements. o Publish-Subscribe [XEP-0060]: the 'node' attribute of the
element (this might actually be a "stringything slot" but typically it is handled as a resourcepart). ### Some of those are things that only clients will use (say, the 'initiator' and 'responder' attributes in Jingle). So even if the server checks every JID-slot (and localpart-slot and resourcepart-slot), the user experience could suffer if clients don't enforce the rules. Just a thought. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9o/J4ACgkQNL8k5A2w/vxJGACcCroNGjPo/eshxDbkSLjCU32c VRAAoMaWB5dkI2mNMehr5QFU6BZEHbX3 =EGM9 -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Mar 20 15:05: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 B06A221F8581 for ; Tue, 20 Mar 2012 15:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 8V8RXXsAEdoG for ; Tue, 20 Mar 2012 15:05:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E236B21F8594 for ; Tue, 20 Mar 2012 15:05:36 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3C4540058; Tue, 20 Mar 2012 16:18:18 -0600 (MDT) Message-ID: <4F68FF2F.2020408@stpeter.im> Date: Tue, 20 Mar 2012 16:05:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Matthew Wild References: <4F679BE0.9040007@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 22:05:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 2:46 PM, Matthew Wild wrote: > On 19 March 2012 20:49, Peter Saint-Andre > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> One of the failings of RFC 3920, and of RFC 6122 too, is that we >> didn't clearly specify which entities are responsible for >> enforcing the i18n rules... >> >> 1. Are clients responsible for preparing JIDs and JID parts >> before injecting them into the system? >> > > Currently - no. Simple clients, etc. > > I'm not against changing this if we can still keep it simple for > clients (such as having available a standard library like libidn > supporting everything, most clients need this already for IDNA). > > However if the server has to check validity anyway, I don't see > much harm in the current situation where it can simply inform the > client when a JID is wrong. I don't see validity checks in servers > going away - whatever those checks may be. True. Do take note of all the JID-slots we've got -- servers might be checking to/from and roster items and perhaps a few others, but not the full range of JID-slots. So documenting that seems useful. >> 2. Are servers responsible for verifying the correctness of any >> JID in any JID-slot (or only to/from addresses plus certain other >> slots)? > > I'd say any within the core XMPP specs at least (and any XEPs that > deem it necessary). Most slots match to/from addresses at some > point. > >> 2a. Only over client-to-server connections? >> >> 2b. Also over server-to-server connections? >> > > I think the above two are pretty tied - the question is whether we > want to allow for site-specific policies, thereby skipping checks > on stanzas from clients destined for remote servers. I would > suggest not cater for this (we currently don't). Seems sensible. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9o/y8ACgkQNL8k5A2w/vxF2wCcDtIjD9FYNXPGfkYLNo1a5vUV mJMAn1gZ17ht4Nu9AdMOuN3Ux5m0Ukku =Ylqn -----END PGP SIGNATURE----- From jhildebr@cisco.com Tue Mar 20 15:09:45 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 4640D21F85B5 for ; Tue, 20 Mar 2012 15:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.766 X-Spam-Level: X-Spam-Status: No, score=-10.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 c2BovnBPL25N for ; Tue, 20 Mar 2012 15:09:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2842A21F8537 for ; Tue, 20 Mar 2012 15:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=677; q=dns/txt; s=iport; t=1332281384; x=1333490984; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=pYNgTzZh9MlpbhzyYTDYO2PccSeES45rp4WO27ZDXSU=; b=mmtJJPOlvI8u73+7lIVm8gp5ci15NwzguRvpx4k19+1t8Eft00iFKcIZ CxHzT9+CewEP8imHHyW8/pgukMJ/DEkPQe6HrccTzHYBlk2er2dipgfDh x0Lbwor7+/8O+GO+K3P2hnL84Fw3VxmllujNuidk5wCZJaqOpVyGRseBc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOf/aE+tJV2b/2dsb2JhbABEtmSBB4IJAQEBAwESAScCATwFDQEIgR0BAQQOBSKHYwWXa58skQEEiFaNCY4/gWiDBg X-IronPort-AV: E=Sophos;i="4.73,620,1325462400"; d="scan'208";a="68064171" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 20 Mar 2012 22:09:43 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KM9hai003704; Tue, 20 Mar 2012 22:09:43 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 17:09:43 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 22:09:43 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 16:09:42 -0600 From: Joe Hildebrand To: Peter Saint-Andre Message-ID: Thread-Topic: [xmpp] 6122bis: enforcing the rules Thread-Index: Ac0G5iZkSL5GGJV3kkaJ0gvtODxQGw== In-Reply-To: <4F68FC9E.4000607@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 22:09:43.0617 (UTC) FILETIME=[275B9310:01CD06E6] Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 22:09:45 -0000 On 3/20/12 3:54 PM, "Peter Saint-Andre" wrote: > Some of those are things that only clients will use (say, the > 'initiator' and 'responder' attributes in Jingle). So even if the > server checks every JID-slot (and localpart-slot and > resourcepart-slot), the user experience could suffer if clients don't > enforce the rules. I'd also be ok with another approach, which is the server MUST convert to canonical form if and only if it has to deal with the protocol (i.e. rosters), but MAY pass through unmodified JID slots in protocols that it otherwise wouldn't have to understand (such as Jingle initiator/responder). -- Joe Hildebrand From stpeter@stpeter.im Tue Mar 20 15:11:06 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 647D321F862A for ; Tue, 20 Mar 2012 15:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 kNRbrqvGjQFz for ; Tue, 20 Mar 2012 15:11:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 97A9A21F860F for ; Tue, 20 Mar 2012 15:11:05 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 751B140058; Tue, 20 Mar 2012 16:23:47 -0600 (MDT) Message-ID: <4F690078.4080204@stpeter.im> Date: Tue, 20 Mar 2012 16:11:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 22:11:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 4:09 PM, Joe Hildebrand wrote: > On 3/20/12 3:54 PM, "Peter Saint-Andre" > wrote: > >> Some of those are things that only clients will use (say, the >> 'initiator' and 'responder' attributes in Jingle). So even if >> the server checks every JID-slot (and localpart-slot and >> resourcepart-slot), the user experience could suffer if clients >> don't enforce the rules. > > I'd also be ok with another approach, which is the server MUST > convert to canonical form if and only if it has to deal with the > protocol (i.e. rosters), but MAY pass through unmodified JID slots > in protocols that it otherwise wouldn't have to understand (such as > Jingle initiator/responder). Yes, I wouldn't want to say that servers would need to clean up JIDs that are deep in Jingle stanzas or whatever! So that makes sense. Then we need to make sure that server implementers are clear on the JID slots that they need to care about. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pAHgACgkQNL8k5A2w/vwVmgCeLxz4RsXXcZ22tmrEmagAH/w/ 4q4AoMyhUo6iSiVNgaJ61XS20ngA/Svi =pwYA -----END PGP SIGNATURE----- From jhildebr@cisco.com Tue Mar 20 15:19:08 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 5D58D21E8017 for ; Tue, 20 Mar 2012 15:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.742 X-Spam-Level: X-Spam-Status: No, score=-10.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kjqKdvBzv1b8 for ; Tue, 20 Mar 2012 15:19:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 792DD21E800F for ; Tue, 20 Mar 2012 15:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=447; q=dns/txt; s=iport; t=1332281947; x=1333491547; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=7WRKB71SAzD7bytOMjVM9M3VXWnwzpldGGqtYWBi4Dc=; b=XLnHtXAmHJ0OubjrW4mmD4+jDBpaa54InJQIc2uNHcXwWdACCol6no2K cm+62mpWwpUMVK8Gu/TqkgBSA5b280m5Qd6GFXVVPJLQWdFiBjef409dC UziZwhMjds99xQjQ0V04GQqwN4/isXSwWashHz1QC9xsdQb3nlHvPvoq9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAIBaU+tJXG+/2dsb2JhbABDtm2BB4IJAQEBAwESAScCATwFDQEIgR0BAQQOBSKHYwWfQ5dGkQEEiFaNCY4/gWiDBg X-IronPort-AV: E=Sophos;i="4.73,620,1325462400"; d="scan'208";a="68066790" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 20 Mar 2012 22:19:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2KMJ6sZ014915; Tue, 20 Mar 2012 22:19:06 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 17:19:06 -0500 Received: from 10.21.80.175 ([10.21.80.175]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Mar 2012 22:19:06 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 20 Mar 2012 16:19:05 -0600 From: Joe Hildebrand To: Peter Saint-Andre Message-ID: Thread-Topic: [xmpp] 6122bis: enforcing the rules Thread-Index: Ac0G53X38+DhGku6wkKZE+xIu8uN3g== In-Reply-To: <4F690078.4080204@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Mar 2012 22:19:06.0945 (UTC) FILETIME=[77209B10:01CD06E7] Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 22:19:08 -0000 On 3/20/12 4:11 PM, "Peter Saint-Andre" wrote: > Yes, I wouldn't want to say that servers would need to clean up JIDs > that are deep in Jingle stanzas or whatever! So that makes sense. Then > we need to make sure that server implementers are clear on the JID > slots that they need to care about. Yes. And provide language for future RFC or XEP editors to say what flavor each new slot is. -- Joe Hildebrand From stpeter@stpeter.im Tue Mar 20 15:19:51 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 9C21221E8017 for ; Tue, 20 Mar 2012 15:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 oJDcm5lYqUjK for ; Tue, 20 Mar 2012 15:19:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 078AF21E800F for ; Tue, 20 Mar 2012 15:19:48 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D452940058; Tue, 20 Mar 2012 16:32:30 -0600 (MDT) Message-ID: <4F690283.5080408@stpeter.im> Date: Tue, 20 Mar 2012 16:19:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 22:19:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 4:19 PM, Joe Hildebrand wrote: > On 3/20/12 4:11 PM, "Peter Saint-Andre" > wrote: > >> Yes, I wouldn't want to say that servers would need to clean up >> JIDs that are deep in Jingle stanzas or whatever! So that makes >> sense. Then we need to make sure that server implementers are >> clear on the JID slots that they need to care about. > > Yes. And provide language for future RFC or XEP editors to say > what flavor each new slot is. Exactly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pAoMACgkQNL8k5A2w/vwPJgCg6nVhRq9wYqLnWxsjnmKCdOrK Gq0AoLwfo9C0kzvK8TejGSJ1SEXls/pE =BxVy -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Mar 20 15:37:16 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 722CD21F8595 for ; Tue, 20 Mar 2012 15:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 JeJ2VWSB2Eab for ; Tue, 20 Mar 2012 15:37:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA86921F858A for ; Tue, 20 Mar 2012 15:37:15 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8846A40058; Tue, 20 Mar 2012 16:49:57 -0600 (MDT) Message-ID: <4F69069A.8030800@stpeter.im> Date: Tue, 20 Mar 2012 16:37:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: normalization form 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: Tue, 20 Mar 2012 22:37:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 1:38 PM, Joe Hildebrand wrote: > On 3/20/12 1:34 PM, "Matthew Wild" wrote: > >> Based on Peter's email (which incidentally is below this >> reply...) I agree. If the main reason in favour of NFD is >> performance - as long as NFC isn't worse than what we do now (and >> I believe it isn't) then I think it's fine. Stringprep (if >> comparable) is not really a performance bottleneck when done >> right. > > I'll argue that it's easy to get wrong; it *is* a bottleneck in > some of our software. It would be helpful to gather some numbers here, but that might not be so easy (you'd need to run the same tests on the same software, but swap out the normalization form). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pBpkACgkQNL8k5A2w/vxsnACghWNPYFa5kEVOTscLPxdJll9d 64kAoPIgzn0FrvpPxuWjg4GB5XLjFu0+ =I4sc -----END PGP SIGNATURE----- From mwild1@gmail.com Tue Mar 20 16:18:52 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 0CC2F21F84C4 for ; Tue, 20 Mar 2012 16:18:52 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eGFO4SjPjh49 for ; Tue, 20 Mar 2012 16:18:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8186221F84A1 for ; Tue, 20 Mar 2012 16:18:51 -0700 (PDT) Received: by iazz13 with SMTP id z13so756473iaz.31 for ; Tue, 20 Mar 2012 16:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hP3a0IR5jqlSOw02lj/xopVAiBGewPI8EmDJT6sUK6M=; b=a5v3DB4rMuY1cjUlISKGKOo0sLA/kyhRgFMiUjegFuCQrK57e/zqsQvYXexh+Q1Qre RjnHKrnu/dZdG8Ivy4v89jgvo9kN+YgdFI/zTSgMmHJXNJU76A8eDW9WM8cMMFujm6v1 PW/cl4lL1ACqpgyB/tg5GwGextDMaw0uI6FIxZdYCSOAL2dTo7wU/lWBs1Xqbi3FAFN6 zCLq5C8PBT+YVW452PP25kf1lTW9m45p9hTmfHOxEV3gT7GjHpZ6+/Ak8uKbKTjZrERY s8ZB5e++5T5VlTWCtdg2/QQ/mJDj+IQhKRljnOqH2+qELeS13k3SMZy5AXLUuTUglXCy jheA== Received: by 10.50.149.163 with SMTP id ub3mr1235414igb.68.1332285531066; Tue, 20 Mar 2012 16:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.68 with HTTP; Tue, 20 Mar 2012 16:18:30 -0700 (PDT) In-Reply-To: <4F690283.5080408@stpeter.im> References: <4F690283.5080408@stpeter.im> From: Matthew Wild Date: Tue, 20 Mar 2012 23:18:30 +0000 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] 6122bis: enforcing the rules 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: Tue, 20 Mar 2012 23:18:52 -0000 On 20 March 2012 22:19, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/20/12 4:19 PM, Joe Hildebrand wrote: >> On 3/20/12 4:11 PM, "Peter Saint-Andre" >> wrote: >> >>> Yes, I wouldn't want to say that servers would need to clean up >>> JIDs that are deep in Jingle stanzas or whatever! So that makes >>> sense. Then we need to make sure that server implementers are >>> clear on the JID slots that they need to care about. >> >> Yes. =C2=A0And provide language for future RFC or XEP editors to say >> what flavor each new slot is. > > Exactly. > I like this approach. Regards, Matthew From florob@babelmonkeys.de Tue Mar 20 18:25:55 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 9D2DD21F856C for ; Tue, 20 Mar 2012 18:25:55 -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 L4ON9eDdfoLj for ; Tue, 20 Mar 2012 18:25:55 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2B21F8569 for ; Tue, 20 Mar 2012 18:25:54 -0700 (PDT) Received: from xdsl-87-79-62-191.netcologne.de ([87.79.62.191] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SAAJE-0008Uj-Lo for xmpp@ietf.org; Wed, 21 Mar 2012 02:25:52 +0100 Message-ID: <4F692E1A.3010109@babelmonkeys.de> Date: Wed, 21 Mar 2012 02:25:46 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <4F68FABA.4050904@stpeter.im> In-Reply-To: <4F68FABA.4050904@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 01:25:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.03.2012 22:46, schrieb Peter Saint-Andre: > On 3/20/12 3:44 PM, Joe Hildebrand wrote: >> I was thinking we could define a heuristic to determine that a >> label was a punycoded A-label, and specify that it had to be >> canonicalized into a U-label (then nameprep-equivalent >> canonicalized) before comparison with another label. However, >> that sounds like a PITA to specify and implement, so I'd rather >> we just say they're always U-labels. > > I think IDNA2008 might define such a heuristic, but I tend to > agree that if we can move from SHOULD to MUST on U-labels then we > can avoid that madness. > Correct me if I'm wrong here, but I was under the impression we could perform comparison on the result of the ToASCII operation. A-labels would remain unaffected by this and U-labels would become A-labels. That said I would definitely prefer if JIDs were only allowed to contain U-labels. I'm somewhat concerned about how to enforce this in user input though. At least libidn apparently allows you to use ToUnicode on U-labels (as a NOP), which means it's safe to use on all user input. However this doesn't strike me as an elegant solution either. Regards, Florian Zeitz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPaS4NAAoJELv//CFWsbyxWUAP/1GbdYAGIL3/UlpyZP2gB2Xd e7+0SNWdGbiz2DS0wpFsEXX8BLTlMASUKwMKYjKxedwQ2f2eWOrG40NLx6FsRq5T mLVykkPrTdtZg1fvK274J3Yyv5o8cSyAwTNashgtIjkMwV6TGJfbzO54S/3pzYiJ pRWJC2QbCb9hzHs7eEi5fh1bJw29+N5dbRIElDMRl6r9vOkyRJNj8sw6abMNG5Cl MczfE2orAvtMAUfcpLZUotXvzim+IZ8LotXNBqHXUBwhAtE2404AlTFWKGmTupTv aDM3+sh7fF8INtZmS3rcz8HLG+hZ8u2j3wUha3P4GU0JwEkCgYdWmCjyX8wAGcbo xlAoUFnl7rbcEoYJhxHIWTtH3nYyBKbNYVbIOrK4vXYg/uVeP70jxF5TGWc6hBBq zl85Nyt0FMczqLn60NbYV40HlQ0sMN0S2dYAO+bDhBE8bOUC4BxrNQpWbBwjwT87 EWidHlSAFqS92i42TIUkPqq8TZPzMvqmk95izzP34W/u/ovSqb4lgu2HlP5+8TEG CEnFCT2B2ORbs0LFRenmNTnxRRcDX+wrLDZssPNzKKQHSHhcUDQ4ZVUjou5rCgpz uEFMlzeodzWVu6HBpxB1Ya5LdQnmkHoyY+Vccj1DkKx1qhkuo3x6XFJz4FPb+2Lg UbDoE37cEaHNV/G+kWUs =sWEc -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Mar 20 19:00:35 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 AC90F21E801C for ; Tue, 20 Mar 2012 19:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=1.040, 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 BQy9yYhl0VgR for ; Tue, 20 Mar 2012 19:00:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B630321E801A for ; Tue, 20 Mar 2012 19:00:34 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0C9A40058; Tue, 20 Mar 2012 20:13:13 -0600 (MDT) Message-ID: <4F693626.2010205@stpeter.im> Date: Tue, 20 Mar 2012 20:00:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Zeitz References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> In-Reply-To: <4F692E1A.3010109@babelmonkeys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 02:00:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 7:25 PM, Florian Zeitz wrote: > Am 20.03.2012 22:46, schrieb Peter Saint-Andre: >> On 3/20/12 3:44 PM, Joe Hildebrand wrote: >>> I was thinking we could define a heuristic to determine that a >>> label was a punycoded A-label, and specify that it had to be >>> canonicalized into a U-label (then nameprep-equivalent >>> canonicalized) before comparison with another label. However, >>> that sounds like a PITA to specify and implement, so I'd >>> rather we just say they're always U-labels. > >> I think IDNA2008 might define such a heuristic, but I tend to >> agree that if we can move from SHOULD to MUST on U-labels then >> we can avoid that madness. > > Correct me if I'm wrong here, but I was under the impression we > could perform comparison on the result of the ToASCII operation. > A-labels would remain unaffected by this and U-labels would become > A-labels. Sure, we can do that. The question is, what do we want to send over the wire? > That said I would definitely prefer if JIDs were only allowed to > contain U-labels. Actually, our specs might already say that. :) Let's look at RFC 6122... A domainpart consisting of a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003]; that is, it MUST be "a domain name in which every label is an internationalized label" and MUST follow the rules for construction of internationalized domain names specified in [IDNA2003]. When preparing a text label (consisting of a sequence of UTF-8 encoded Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domainpart or comparing two XMPP domainparts, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. (Note: The ToASCII operation includes application of the [NAMEPREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA2003].) Although XMPP applications do not communicate the output of the ToASCII operation (called an "ACE label") over the wire, it MUST be possible to apply that operation without failing to each internationalized label. If an XMPP application receives as input an ACE label, it SHOULD convert that ACE label to an internationalized label using the ToUnicode operation (see [IDNA2003]) before including the label in an XMPP domainpart that will be communicated over the wire on an XMPP network (however, instead of converting the label, there are legitimate reasons why an application might instead refuse the input altogether and return an error to the entity that provided the offending data). So, we see that although it must be possible to apply the IDNA2003 ToASCII operation to a domainpart, the output of the ToASCII operation (an ACE label, which in IDNA2008 we'd call an A-label) is not communicated over the wire; if an XMPP application receives the "offending data" of an ACE label, it SHOULD convert it into a U-label for sending over the wire, but it's allowed to return an error instead. I conclude that we've never allowed A-labels on the wire. (IMHO the use of SHOULD was misleading in RFC 3920 / RFC 6122, because it followed the kind of "SHOULD ... but MAY instead" construction that we try to avoid these days.) > I'm somewhat concerned about how to enforce this in user input > though. At least libidn apparently allows you to use ToUnicode on > U-labels (as a NOP), which means it's safe to use on all user > input. However this doesn't strike me as an elegant solution > either. Are you concerned that users would enter A-labels? I see that as exceedingly unlikely. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pNiYACgkQNL8k5A2w/vyo5gCgwCXwZwg19Fvxuc3F6Tacssds QzkAoK+fULFheIV9WrWrgkyi9SL6KDho =ZzRC -----END PGP SIGNATURE----- From florob@babelmonkeys.de Tue Mar 20 19:31:21 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 A455D21E803C for ; Tue, 20 Mar 2012 19:31:21 -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, 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 jGYHPCVJbqqY for ; Tue, 20 Mar 2012 19:31:20 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85F21E801A for ; Tue, 20 Mar 2012 19:31:20 -0700 (PDT) Received: from xdsl-87-79-49-183.netcologne.de ([87.79.49.183] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SABKW-0006DC-D6; Wed, 21 Mar 2012 03:31:16 +0100 Message-ID: <4F693D6E.9070000@babelmonkeys.de> Date: Wed, 21 Mar 2012 03:31:10 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> <4F693626.2010205@stpeter.im> In-Reply-To: <4F693626.2010205@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 02:31:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-21 03:00, Peter Saint-Andre wrote: > On 3/20/12 7:25 PM, Florian Zeitz wrote: >> Correct me if I'm wrong here, but I was under the impression we >> could perform comparison on the result of the ToASCII operation. >> A-labels would remain unaffected by this and U-labels would >> become A-labels. > > Sure, we can do that. The question is, what do we want to send > over the wire? > Indeed, or at least if the answer to that question is "only U-labels" the comparison becomes less of an issue. >> That said I would definitely prefer if JIDs were only allowed to >> contain U-labels. > > Actually, our specs might already say that. :) > > Let's look at RFC 6122... > > A domainpart consisting of a fully qualified domain name MUST be > an "internationalized domain name" as defined in [IDNA2003]; that > is, it MUST be "a domain name in which every label is an > internationalized label" and MUST follow the rules for construction > of internationalized domain names specified in [IDNA2003]. When > preparing a text label (consisting of a sequence of UTF-8 encoded > Unicode code points) for representation as an internationalized > label in the process of constructing an XMPP domainpart or > comparing two XMPP domainparts, an application MUST ensure that for > each text label it is possible to apply without failing the ToASCII > operation specified in [IDNA2003] with the UseSTD3ASCIIRules flag > set (thus forbidding ASCII code points other than letters, digits, > and hyphens). If the ToASCII operation can be applied without > failing, then the label is an internationalized label. (Note: The > ToASCII operation includes application of the [NAMEPREP] profile > of [STRINGPREP] and encoding using the algorithm specified in > [PUNYCODE]; for details, see [IDNA2003].) Although XMPP > applications do not communicate the output of the ToASCII operation > (called an "ACE label") over the wire, it MUST be possible to apply > that operation without failing to each internationalized label. If > an XMPP application receives as input an ACE label, it SHOULD > convert that ACE label to an internationalized label using the > ToUnicode operation (see [IDNA2003]) before including the label in > an XMPP domainpart that will be communicated over the wire on an > XMPP network (however, instead of converting the label, there are > legitimate reasons why an application might instead refuse the > input altogether and return an error to the entity that provided > the offending data). > > So, we see that although it must be possible to apply the IDNA2003 > ToASCII operation to a domainpart, the output of the ToASCII > operation (an ACE label, which in IDNA2008 we'd call an A-label) is > not communicated over the wire; if an XMPP application receives > the "offending data" of an ACE label, it SHOULD convert it into a > U-label for sending over the wire, but it's allowed to return an > error instead. > > I conclude that we've never allowed A-labels on the wire. > > (IMHO the use of SHOULD was misleading in RFC 3920 / RFC 6122, > because it followed the kind of "SHOULD ... but MAY instead" > construction that we try to avoid these days.) > I think this is actually underspecified in several ways. Specifically we are not mandating that domainparts have to be U-labels at all. An A-label is a valid "internationalized label", since (as noted before) ToASCII applies to it just fine (or at least that is my understanding). Also if we don't allow A-labels on the wire, why SHOULD an application ever have to convert them? Taking that text too literal it is also valid to send A-labels as long as they were not received from somewhere else. I think implementers usually did take this to mean that only U-labels should be send over the wire, but I think there are several loop holes to close here. >> I'm somewhat concerned about how to enforce this in user input >> though. At least libidn apparently allows you to use ToUnicode >> on U-labels (as a NOP), which means it's safe to use on all user >> input. However this doesn't strike me as an elegant solution >> either. > > Are you concerned that users would enter A-labels? I see that as > exceedingly unlikely. > I agree it's unlikely, in the spirit of Postel's law I do however at least feel discomfort about this ;). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPaT1uAAoJELv//CFWsbyxv4UQAM6o7ANQ/2li2FbMNY5TQ99y PddufCFR8nNnSWdxzACv8plfUB2kmsK1EXQNU/ri2mMGr+KLnfzsuQz4FKHtmzUG qdxa0/8Dx4+Vu/UnV2cmtM0eZ/9guZbRj1orXGJz2PSIXi0uLZZjmhJ6xxuyYIFQ 9bFRKKPo96Lvz1p32M9XQA0twPf9mAbHdH2C8zFk2HGIA7YU7qk4NyIfZZxENBgI vqr8xbW7uur2Gf0qDfPCFc0hE/HZBPJh1JbZGdQyDdaq9poEVf7tade9hZzd/RX0 /0x5xjI0UTcDzeX3P7cpTOKKIuDhrv6JiqxOvfKOXXv/wv478AGAH5PpvK/XmCXE Y9cyUyb0L0xUlqaTmLsFPHz5rFx3z4MktxGTEsA7Qx3MEH7fHxTLBG+ciz15uweR 24PVU0EhV0UrLnDE7+CFI4bLFkf5Ou6T521gd3oTg2CdbehsgoXcc53oCN+kx5Tz IsHTxtw20GOsFBB9HJ+Yx8KX0JzVhbXBkfR0fpwtK3xXobAdapHlRvauh/7M9EGg mPeRIX6/92f5MenfETDZ5q+Eq/7/ryH7maToNyqPvFAzUosXerkHIqv2PTAXVS6c EtUgk8CDHJ68v9YxtNazzmoPHDEoz9KQZkNc/TQGI3fpLTq+0dnwj/JSTbSnrl0T 070r4MwsV1GQTKTSqOxN =0Pk4 -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Mar 20 20:36:20 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 1540321F84F6 for ; Tue, 20 Mar 2012 20:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=0.999, 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 X9kjl6mmxoXJ for ; Tue, 20 Mar 2012 20:36:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09921F84F9 for ; Tue, 20 Mar 2012 20:36:15 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 597A840058; Tue, 20 Mar 2012 21:48:57 -0600 (MDT) Message-ID: <4F694CAD.90504@stpeter.im> Date: Tue, 20 Mar 2012 21:36:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Zeitz References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> <4F693626.2010205@stpeter.im> <4F693D6E.9070000@babelmonkeys.de> In-Reply-To: <4F693D6E.9070000@babelmonkeys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 03:36:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 8:31 PM, Florian Zeitz wrote: > On 2012-03-21 03:00, Peter Saint-Andre wrote: >> On 3/20/12 7:25 PM, Florian Zeitz wrote: >>> Correct me if I'm wrong here, but I was under the impression we >>> could perform comparison on the result of the ToASCII >>> operation. A-labels would remain unaffected by this and >>> U-labels would become A-labels. > >> Sure, we can do that. The question is, what do we want to send >> over the wire? > > Indeed, or at least if the answer to that question is "only > U-labels" the comparison becomes less of an issue. > >>> That said I would definitely prefer if JIDs were only allowed >>> to contain U-labels. > >> Actually, our specs might already say that. :) > >> Let's look at RFC 6122... > >> A domainpart consisting of a fully qualified domain name MUST be >> an "internationalized domain name" as defined in [IDNA2003]; >> that is, it MUST be "a domain name in which every label is an >> internationalized label" and MUST follow the rules for >> construction of internationalized domain names specified in >> [IDNA2003]. When preparing a text label (consisting of a >> sequence of UTF-8 encoded Unicode code points) for representation >> as an internationalized label in the process of constructing an >> XMPP domainpart or comparing two XMPP domainparts, an application >> MUST ensure that for each text label it is possible to apply >> without failing the ToASCII operation specified in [IDNA2003] >> with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code >> points other than letters, digits, and hyphens). If the ToASCII >> operation can be applied without failing, then the label is an >> internationalized label. (Note: The ToASCII operation includes >> application of the [NAMEPREP] profile of [STRINGPREP] and >> encoding using the algorithm specified in [PUNYCODE]; for >> details, see [IDNA2003].) Although XMPP applications do not >> communicate the output of the ToASCII operation (called an "ACE >> label") over the wire, it MUST be possible to apply that >> operation without failing to each internationalized label. If an >> XMPP application receives as input an ACE label, it SHOULD >> convert that ACE label to an internationalized label using the >> ToUnicode operation (see [IDNA2003]) before including the label >> in an XMPP domainpart that will be communicated over the wire on >> an XMPP network (however, instead of converting the label, there >> are legitimate reasons why an application might instead refuse >> the input altogether and return an error to the entity that >> provided the offending data). > >> So, we see that although it must be possible to apply the >> IDNA2003 ToASCII operation to a domainpart, the output of the >> ToASCII operation (an ACE label, which in IDNA2008 we'd call an >> A-label) is not communicated over the wire; if an XMPP >> application receives the "offending data" of an ACE label, it >> SHOULD convert it into a U-label for sending over the wire, but >> it's allowed to return an error instead. > >> I conclude that we've never allowed A-labels on the wire. > >> (IMHO the use of SHOULD was misleading in RFC 3920 / RFC 6122, >> because it followed the kind of "SHOULD ... but MAY instead" >> construction that we try to avoid these days.) > > I think this is actually underspecified in several ways. It's underspecified in a lot of ways -- that's why we're working on 6122bis. :) Please understand that RFC 6122 is based on IDNA2003, whereas 6122bis is based on IDNA20008. > Specifically we are not mandating that domainparts have to be > U-labels at all. An A-label is a valid "internationalized label", > since (as noted before) ToASCII applies to it just fine (or at > least that is my understanding). Also if we don't allow A-labels on > the wire, why SHOULD an application ever have to convert them? If we way that a server must enforce the rules but a client doesn't have to, then a server might receive an A-label from the client. > Taking that text too literal it is also valid to send A-labels as > long as they were not received from somewhere else. Too literal indeed. Anyway, it's better to look at 6122bis. I quoted RFC 6122 only for historical purposes. > I think implementers usually did take this to mean that only > U-labels should be send over the wire, but I think there are > several loop holes to close here. Agreed. Please review draft-ietf-xmpp-6122bis and send your feedback. :) >>> I'm somewhat concerned about how to enforce this in user input >>> though. At least libidn apparently allows you to use >>> ToUnicode on U-labels (as a NOP), which means it's safe to use >>> on all user input. However this doesn't strike me as an elegant >>> solution either. > >> Are you concerned that users would enter A-labels? I see that as >> exceedingly unlikely. > > I agree it's unlikely, in the spirit of Postel's law I do however > at least feel discomfort about this ;). Let's see, would a Czech person type #2 instead of #1? 1. Pročprostěnemluvíčesky.cz 2. xn--Proprostnemluvesky-uyb24dma41a.cz I rather doubt it, but I suppose it's possible. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pTK0ACgkQNL8k5A2w/vytxACdFPY5D0MgwhoAKxuTd4V7fgqs baYAn3gW8PVpT1MacNmLWU8RUo3Bre7t =VIM1 -----END PGP SIGNATURE----- From dave@cridland.net Tue Mar 20 23:16:46 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 E212921F863F for ; Tue, 20 Mar 2012 23:16:46 -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 VZ5eS7idgjJp for ; Tue, 20 Mar 2012 23:16:46 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 092A221F863C for ; Tue, 20 Mar 2012 23:16:36 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 4C6861168087; Wed, 21 Mar 2012 06:16:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prd83EV3DbdQ; Wed, 21 Mar 2012 06:16:27 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id D22761168067; Wed, 21 Mar 2012 06:16:26 +0000 (GMT) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <20897.1332310586.860439@puncture> Date: Wed, 21 Mar 2012 06:16:26 +0000 From: Dave Cridland To: Joe Hildebrand , XMPP Working Group , Matthew Wild Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] 6122bis: normalization form 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, 21 Mar 2012 06:16:47 -0000 On Tue Mar 20 19:38:00 2012, Joe Hildebrand wrote: > On 3/20/12 1:34 PM, "Matthew Wild" wrote: > > > Based on Peter's email (which incidentally is below this > reply...) I > > agree. If the main reason in favour of NFD is performance - as > long as > > NFC isn't worse than what we do now (and I believe it isn't) then > I > > think it's fine. Stringprep (if comparable) is not really a > > performance bottleneck when done right. > > I'll argue that it's easy to get wrong; it *is* a bottleneck in > some of our > software. I agree it's a significant chunk of performance, but changing the normalized form of a jid will mean lots of complex handling in order to transition "right". NFC, on the other hand, should be OK. Addressing performance is, I think, best done by simply minimizing the amount of normalization we require - that is, ensure that jids are normalized when needed, instead of as a routine on any input. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From jhildebr@cisco.com Tue Mar 20 23:30:13 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 483F821E8019 for ; Tue, 20 Mar 2012 23:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.724 X-Spam-Level: X-Spam-Status: No, score=-10.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qbMlh8+Viuou for ; Tue, 20 Mar 2012 23:30:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 72E7021E8012 for ; Tue, 20 Mar 2012 23:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=580; q=dns/txt; s=iport; t=1332311412; x=1333521012; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=1ElxAfmCAor2Pbo1FcIRYruF9PxEopnkd2RT6gFGYjc=; b=VXcX2nK9W2eDY+KdQARHBmNZvOOgDqgDgM78w5JX2cFd3jEFnMTMW7+e Rne834jA5gLNQAyiiEJJ5YccKG6gUTqIWcrqmnb8aGTS45rTidQF4gUYR c3GiceUA3unJbI0Adz125mlz7+hSEUJ4mlnd8GH1C7XMcaNYITE1BZVXA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANN0aU+tJXG+/2dsb2JhbABEtnaBB4IJAQEBAwESAScCAUENAQiBHQEBBAESIodjBZgbnx2RAQSIVo0Ijj+BaIMG X-IronPort-AV: E=Sophos;i="4.73,621,1325462400"; d="scan'208";a="68146331" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2012 06:30:12 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2L6UBj8027279; Wed, 21 Mar 2012 06:30:11 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 01:30:11 -0500 Received: from 10.21.121.72 ([10.21.121.72]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2012 06:30:11 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Mar 2012 00:30:10 -0600 From: Joe Hildebrand To: Dave Cridland , XMPP Working Group , Matthew Wild Message-ID: Thread-Topic: [xmpp] 6122bis: normalization form Thread-Index: Ac0HLBB6g3/BPhkZyUeWYQ/SC0Bo8w== In-Reply-To: <20897.1332310586.860439@puncture> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Mar 2012 06:30:11.0618 (UTC) FILETIME=[1170E820:01CD072C] Subject: Re: [xmpp] 6122bis: normalization form 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, 21 Mar 2012 06:30:13 -0000 On 3/21/12 12:16 AM, "Dave Cridland" wrote: > I agree it's a significant chunk of performance, but changing the > normalized form of a jid will mean lots of complex handling in order > to transition "right". > > NFC, on the other hand, should be OK. Can you say more about this? We're still going to have to deal with transition with JIDs that contains codepoints with kompatibility mappings. Anything that is canonicalizing can deal with NFKC inputs just as easily as NFD inputs, and will get the same outputs for each. -- Joe Hildebrand From dave@cridland.net Tue Mar 20 23:32: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 E4ADF21E804E for ; Tue, 20 Mar 2012 23:32:30 -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 qIeuq77KMhls for ; Tue, 20 Mar 2012 23:32:29 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 902F921E803F for ; Tue, 20 Mar 2012 23:32:27 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BF3991168087; Wed, 21 Mar 2012 06:32:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ayTlFdPhs1M; Wed, 21 Mar 2012 06:32:23 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id F0C671168067; Wed, 21 Mar 2012 06:32:22 +0000 (GMT) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <20897.1332311542.982967@puncture> Date: Wed, 21 Mar 2012 06:32:22 +0000 From: Dave Cridland To: Joe Hildebrand , XMPP Working Group , Matthew Wild Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] 6122bis: normalization form 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, 21 Mar 2012 06:32:31 -0000 On Wed Mar 21 06:30:10 2012, Joe Hildebrand wrote: > On 3/21/12 12:16 AM, "Dave Cridland" wrote: > > > I agree it's a significant chunk of performance, but changing the > > normalized form of a jid will mean lots of complex handling in > order > > to transition "right". > > > > NFC, on the other hand, should be OK. > > Can you say more about this? We're still going to have to deal with > transition with JIDs that contains codepoints with kompatibility > mappings. > Anything that is canonicalizing can deal with NFKC inputs just as > easily as > NFD inputs, and will get the same outputs for each. Yeah, I'm assuming K is a much smaller problem. I'm also assuming the problem isn't input jids, per se, but stored jids. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Wed Mar 21 05:28:21 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 C71E421F8673 for ; Wed, 21 Mar 2012 05:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 Ohi-IxPWZdD8 for ; Wed, 21 Mar 2012 05:28:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E8A2721F8646 for ; Wed, 21 Mar 2012 05:28:19 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 52EB840058; Wed, 21 Mar 2012 06:41:03 -0600 (MDT) Message-ID: <4F69C962.4050602@stpeter.im> Date: Wed, 21 Mar 2012 06:28:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dave Cridland References: <20897.1332311542.982967@puncture> In-Reply-To: <20897.1332311542.982967@puncture> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 6122bis: normalization form 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, 21 Mar 2012 12:28:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/21/12 12:32 AM, Dave Cridland wrote: > On Wed Mar 21 06:30:10 2012, Joe Hildebrand wrote: >> On 3/21/12 12:16 AM, "Dave Cridland" wrote: >> >>> I agree it's a significant chunk of performance, but changing >>> the normalized form of a jid will mean lots of complex handling >>> in order to transition "right". >>> >>> NFC, on the other hand, should be OK. >> >> Can you say more about this? We're still going to have to deal >> with transition with JIDs that contains codepoints with >> kompatibility mappings. Anything that is canonicalizing can deal >> with NFKC inputs just as easily as NFD inputs, and will get the >> same outputs for each. > > Yeah, I'm assuming K is a much smaller problem. I tend to agree. I'd be happy to gather some real-life data from the jabber.org service to see what percentage of our ~1 million users have usernames containing codepoints that have compatibility equivalents. > I'm also assuming the problem isn't input jids, per se, but stored > jids. Yes, some form of migration / JID scrubbing will be necessary. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9pyWEACgkQNL8k5A2w/vxUdgCg4DZywputTyx18lZJ5KRkuYdV xjkAoLZI2o+tW4Vx4r2WZSOi+KAfqnzb =3Ddg -----END PGP SIGNATURE----- From florob@babelmonkeys.de Wed Mar 21 14:51: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 3EE0721F8684 for ; Wed, 21 Mar 2012 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 3ytCBME1N896 for ; Wed, 21 Mar 2012 14:51:30 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 440D521F866E for ; Wed, 21 Mar 2012 14:51:29 -0700 (PDT) Received: from xdsl-87-79-166-143.netcologne.de ([87.79.166.143] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SATRE-00039T-4Y; Wed, 21 Mar 2012 22:51:24 +0100 Message-ID: <4F6A4D55.2070106@babelmonkeys.de> Date: Wed, 21 Mar 2012 22:51:17 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> <4F693626.2010205@stpeter.im> <4F693D6E.9070000@babelmonkeys.de> <4F694CAD.90504@stpeter.im> In-Reply-To: <4F694CAD.90504@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 21:51:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.03.2012 04:36, schrieb Peter Saint-Andre: > On 3/20/12 8:31 PM, Florian Zeitz wrote: >> Taking that text too literal it is also valid to send A-labels >> as long as they were not received from somewhere else. > > Too literal indeed. Anyway, it's better to look at 6122bis. I > quoted RFC 6122 only for historical purposes. > Which is also my reason for getting into it's details. I think we need to have a clear understanding of what the current RFCs say, to find a (backwards compatible) way forward. I disagree with your assessment that A-labels (ACE labels) were always disallowed on the wire. >> I think implementers usually did take this to mean that only >> U-labels should be send over the wire, but I think there are >> several loop holes to close here. > > Agreed. Please review draft-ietf-xmpp-6122bis and send your > feedback. :) > I shall do a proper full review once I have more spare time. Some notes concerning the issue discussed in this thread: As it has been since RFC 3920 conversion of A-labels is only specified in certain cases. I.e. a JID's domainpart can contain an A-label, just if you want to do $something specific with it SHOULD that label be converted to a U-label. I personally don't see the compelling reason for that approach. Is there anything wrong with saying that a JID's domainpart SHOULD(/MUST?) be a internationalized domain name containing only U- and NR-LDH-labels? Particularly the current wording in 6122bis ("For the purposes of communication over XMPP") seems incredibly vague to me. Amongst other things it seems to exempt "for comparison", which is one of the cases where we certainly need mapping, normalization, and some coherent representation of labels. Note that the point I'm trying to make here is specifically that I'd want the domainpart of a JID to always follow certain rules, as opposed to making arrangements for it to follow certain rules in certain cases. If worse comes to worse I'm willing to accept that a domainpart is a general IDNA-aware domain name slot (i.e. can include A-labels). Having rules that amount to "It's a general internationalized domain name, except in 'to' and 'from' attributes and some other cases, where the server converts A-labels to U-labels, except when there was a good reason for the server not to" will almost certainly lead to problems. >>> Are you concerned that users would enter A-labels? I see that >>> as exceedingly unlikely. > >> I agree it's unlikely, in the spirit of Postel's law I do >> however at least feel discomfort about this ;). > > Let's see, would a Czech person type #2 instead of #1? > > 1. Pročprostěnemluvíčesky.cz > > 2. xn--Proprostnemluvesky-uyb24dma41a.cz > > I rather doubt it, but I suppose it's possible. > What I fear is that some users (unfortunately also/mostly/even tech-savvy ones) are too convinced that internationalization is often broken. E.g. some people have apparently taught themselves to type ü, ä, ö and ß as ue, ae, oe and ss for certain uses (usernames etc.) because "everything else often causes problems". I suspect similar prejudice might exist for labels too. E.g. the reason the IDNA related testing at the XMPP Summit in Brussels initially failed was that the server was configured using A-labels and would not accept the U-label version thereof. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPak1OAAoJELv//CFWsbyx8w0P/0lSg1RUbmIYbzM2j7BhXND5 tMBqrEbjV3SvJh5zxxWLC9uLWj5CNQBMLB2JbWlAiF4vB4iemAcMrRT5Ru8dpjzR FeyFkBfeDYFg5c3Ntry4XEjdax16Cn9ix6W5Fg6uXTXlga5bC9bWPcb1eZotv8aq uqcfLym9Rl48JFf0APFiKDMOS8rFTlIWBnAo3pNPqNnEYnIDfDwVpIbRKnodU27A eksJVUOWepGWbpmaZ1gqf4A0bZSFl6gxi6yk49JxzVa1zbU0I3b6+JEdxm2vQbBL 6CiSsXKXBUkCuEoZVyxE2fHtkXOh0lulvtnCagm7vUW5A2QFss+QNn7M8qrPvAzD 3Zodne1ZQhbVahq3zFsv+D86hXa74PiwoiFHKcZsgeopQF4IgwsNPvANiRf57sEA L2toF8TTFATkmpq1vwy8EE+IRdGZ2lCKUONM1iL71s2t1O5hBpPhVDGlAf2tFdDu OMJZrdEOdryeUeuWEhp18BAizld6oiT/n9sJTpNA9wejJF71DtlZwQRuV7Yi3NpR P/3xQrA2v5ZYwIIjk2mBN0tNRX/oYfzl6EuPVl4TJS6PW+r0ucd2BgtKNVkiELfh RmgiqNtibsZX408enR5xA1L/EQ47LyVGTohYv+2lcxvNGGonDOO/QgdHm4ab4xDx EBXTBJoa5ZA0jYkQalP8 =x80r -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Mar 21 15:45:34 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 88A2F21E80AB for ; Wed, 21 Mar 2012 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 SHGTyMGyJnAQ for ; Wed, 21 Mar 2012 15:45:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8546F21E805A for ; Wed, 21 Mar 2012 15:45:33 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D464640058; Wed, 21 Mar 2012 16:58:17 -0600 (MDT) Message-ID: <4F6A5A0B.30801@stpeter.im> Date: Wed, 21 Mar 2012 16:45:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Zeitz References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> <4F693626.2010205@stpeter.im> <4F693D6E.9070000@babelmonkeys.de> <4F694CAD.90504@stpeter.im> <4F6A4D55.2070106@babelmonkeys.de> In-Reply-To: <4F6A4D55.2070106@babelmonkeys.de> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 21 Mar 2012 22:45:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/21/12 3:51 PM, Florian Zeitz wrote: > Am 21.03.2012 04:36, schrieb Peter Saint-Andre: >> On 3/20/12 8:31 PM, Florian Zeitz wrote: >>> Taking that text too literal it is also valid to send A-labels >>> as long as they were not received from somewhere else. > >> Too literal indeed. Anyway, it's better to look at 6122bis. I >> quoted RFC 6122 only for historical purposes. > > Which is also my reason for getting into it's details. I think we > need to have a clear understanding of what the current RFCs say, to > find a (backwards compatible) way forward. I disagree with your > assessment that A-labels (ACE labels) were always disallowed on the > wire. What is your interpretation? I agree that RFC 3920 and RFC 6122 were not worded very clearly, but it seems to me that ACE labels were not permitted on the wire, e.g., "XMPP applications do not communicate the output of the ToASCII operation (called an "ACE label") over the wire". Because we want to be backward compatible, it's important to know what we specified before (and how implementers understood the spec). But in any case, I think the right thing to do now is to say that a domainpart MUST NOT include A-labels. >>> I think implementers usually did take this to mean that only >>> U-labels should be send over the wire, but I think there are >>> several loop holes to close here. > >> Agreed. Please review draft-ietf-xmpp-6122bis and send your >> feedback. :) > > I shall do a proper full review once I have more spare time. > > Some notes concerning the issue discussed in this thread: As it has > been since RFC 3920 conversion of A-labels is only specified in > certain cases. I.e. a JID's domainpart can contain an A-label, just > if you want to do $something specific with it SHOULD that label be > converted to a U-label. > > I personally don't see the compelling reason for that approach. Is > there anything wrong with saying that a JID's domainpart > SHOULD(/MUST?) be a internationalized domain name containing only > U- and NR-LDH-labels? That would be my preference. > Particularly the current wording in 6122bis ("For the purposes of > communication over XMPP") seems incredibly vague to me. I am not sure that it is *incredibly* vague. The contrast was with XMPP IRIs, i.e., representation of a JID in IRI form, not JIDs as natively used on the XMPP network. > Amongst other things it seems to exempt "for comparison", which is > one of the cases where we certainly need mapping, normalization, > and some coherent representation of labels. That was not the intent. > Note that the point I'm trying to make here is specifically that > I'd want the domainpart of a JID to always follow certain rules, > as opposed to making arrangements for it to follow certain rules > in certain cases. Agreed. > If worse comes to worse I'm willing to accept that a domainpart is > a general IDNA-aware domain name slot (i.e. can include A-labels). > Having rules that amount to "It's a general internationalized > domain name, except in 'to' and 'from' attributes and some other > cases, where the server converts A-labels to U-labels, except when > there was a good reason for the server not to" will almost > certainly lead to problems. Right, that would lead to all sorts of trouble. >>>> Are you concerned that users would enter A-labels? I see >>>> that as exceedingly unlikely. > >>> I agree it's unlikely, in the spirit of Postel's law I do >>> however at least feel discomfort about this ;). > >> Let's see, would a Czech person type #2 instead of #1? > >> 1. Pročprostěnemluvíčesky.cz > >> 2. xn--Proprostnemluvesky-uyb24dma41a.cz > >> I rather doubt it, but I suppose it's possible. > > What I fear is that some users (unfortunately also/mostly/even > tech-savvy ones) are too convinced that internationalization is > often broken. E.g. some people have apparently taught themselves to > type ü, ä, ö and ß as ue, ae, oe and ss for certain uses (usernames > etc.) because "everything else often causes problems". I suspect > similar prejudice might exist for labels too. E.g. the reason the > IDNA related testing at the XMPP Summit in Brussels initially > failed was that the server was configured using A-labels and would > not accept the U-label version thereof. That's true, but I doubt that it would lead people to type A-labels, which are horrendously ugly. See above. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9qWgsACgkQNL8k5A2w/vxjNwCgnnbMmB3xgzLrcynTxLjUc1EL 0n0AoMMrIQSvTQPSST93BTwJsvZpwfy3 =rdEs -----END PGP SIGNATURE----- From florob@babelmonkeys.de Wed Mar 21 17:39:15 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 87AC121E811B for ; Wed, 21 Mar 2012 17:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 q2BKvpXY35ZO for ; Wed, 21 Mar 2012 17:39:14 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C421E80EB for ; Wed, 21 Mar 2012 17:39:14 -0700 (PDT) Received: from xdsl-87-79-166-143.netcologne.de ([87.79.166.143] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SAW3a-0003Lz-Is; Thu, 22 Mar 2012 01:39:11 +0100 Message-ID: <4F6A74A8.1090409@babelmonkeys.de> Date: Thu, 22 Mar 2012 01:39:04 +0100 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F68FABA.4050904@stpeter.im> <4F692E1A.3010109@babelmonkeys.de> <4F693626.2010205@stpeter.im> <4F693D6E.9070000@babelmonkeys.de> <4F694CAD.90504@stpeter.im> <4F6A4D55.2070106@babelmonkeys.de> <4F6A5A0B.30801@stpeter.im> In-Reply-To: <4F6A5A0B.30801@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: U-labels and A-labels in domainparts 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, 22 Mar 2012 00:39:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.03.2012 23:45, schrieb Peter Saint-Andre: > On 3/21/12 3:51 PM, Florian Zeitz wrote: >> Am 21.03.2012 04:36, schrieb Peter Saint-Andre: >>> On 3/20/12 8:31 PM, Florian Zeitz wrote: >>>> Taking that text too literal it is also valid to send >>>> A-labels as long as they were not received from somewhere >>>> else. > >>> Too literal indeed. Anyway, it's better to look at 6122bis. I >>> quoted RFC 6122 only for historical purposes. > >> Which is also my reason for getting into it's details. I think >> we need to have a clear understanding of what the current RFCs >> say, to find a (backwards compatible) way forward. I disagree >> with your assessment that A-labels (ACE labels) were always >> disallowed on the wire. > > What is your interpretation? I agree that RFC 3920 and RFC 6122 > were not worded very clearly, but it seems to me that ACE labels > were not permitted on the wire, e.g., "XMPP applications do not > communicate the output of the ToASCII operation (called an "ACE > label") over the wire". Because we want to be backward compatible, > it's important to know what we specified before (and how > implementers understood the spec). > "Remember that you asked for it" :) I do believe that ACE label were/are not forbidden. The over-shortened reasoning for this is that there is no "MUST NOT" requirement to not send them. The more/overly detailed version goes something like this: There are (IMHO) just two places that could restrict ACE labels in domain parts: 1. «Although XMPP applications do not communicate the output of the ToASCII operation (called an "ACE label") over the wire, it MUST be possible to apply that operation without failing to each internationalized label.» First of all it says "do not" instead of "MUST NOT", which makes it seem more like a side note. That in mind it is easy to derive the following procedure from the text: a) apply ToASCII to each label b) verify it succeeded b1) if it did, use your input to the ToASCII operation as domainpart b2) otherwise, produce an error The problem with that approach is that it does not catch ACE labels that already existed in the input. Also the ToASCII operation can have a LDH label as output (it passes through unchanged). In that sense "output of the ToASCII operation" and "ACE label" are in fact not equivalent. Hence taking this text to mean that anything that looks like output of the ToASCII operation is forbidden on the wire, would imply LDH labels are forbidden. 2. «If an XMPP application receives as input an ACE label, it SHOULD convert that ACE label to an internationalized label using the ToUnicode operation (see [IDNA2003]) before including the label in an XMPP domainpart that will be communicated over the wire on an XMPP network (however, instead of converting the label, there are legitimate reasons why an application might instead refuse the input altogether and return an error to the entity that provided the offending data).» As I said before there is a point to be made about the precondition on having received that label. It is certainly nitpicking, but this text does not forbid an entity to produce ACE labels and send them. Additionally this is only a SHOULD requirement, which means implementations need to prepare for accepting domainparts from implementations that had a good reason not to follow it. In particular this is not a "MUST either ..., or ..." in combination with the parenthetic remark. The fact that there is text that defines what SHOULD happen when ACE labels are received on the wire could be taken to imply that they certainly were allowed (to be send) on the wire. > But in any case, I think the right thing to do now is to say that > a domainpart MUST NOT include A-labels. > Agreed. While I do think they were allowed before, I'm also under the impression that introducing this requirement will not break existing deployments. Feedback on whether that impression is correct, especially from somebody who lives where IDNA domains are somewhat wider deployed, would obviously be appreciated. >> Particularly the current wording in 6122bis ("For the purposes of >> communication over XMPP") seems incredibly vague to me. > > I am not sure that it is *incredibly* vague. The contrast was with > XMPP IRIs, i.e., representation of a JID in IRI form, not JIDs as > natively used on the XMPP network. > Unfortunately it is to me, though that may partially be due to the language barrier. Especially in the context of XMPP I think "communication over XMPP" could be interpreted as anything from "instant messaging" to "data send over an XMPP stream" (where I'd assume the later was the intended interpretation). Regards, Florian Zeitz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPanSoAAoJELv//CFWsbyxzb0P/2Fr1SqPAKzKb/hzuHG07RkZ Me3H8JmetIUpmTa+EafoSyYPCtUjwU49F+enaTcCouIkfec+jyZGo3ZXuJqO/G7z LSf+tr2xxEdxyi7GQd30zVg4gcKNVqLfGlIXRpa0e+a4rPkBfsN4RVm+YzbVF4Ze QIe2HzhKfBcCdLhD3EUUUjulAkCD4QLzwulqwTBl93GUIrXTPiTNWtEpCzByrWcT 7/8C0IBxDixrgTWQrFGlCBrwQXwg7faAKWKT9QT1vwM7HqY9NxgWuvtwSwptFw5A QRjY4Hrmc/X7kyWam0hYDq1udQPn3zQaxkZwy+dbyw5tO+JJx3xPMaIxPNd2dTrC lTZEybW/VQr9DU4d6Nap7taGsYlGhqMGkcU16UK/5Lh1GQ0MzZzkXlIDtLr3vVhF jYFbAn+o5OEr0FJ23Moyc1K3kbSv9h3J82jAU+vTX9n+UQQ8zO2N/DrC79T3Q3VV MFIqGhmB97RqVBRkP9ClTerpQxIPo/R1xkWRd7vN9oEVZKk3/tRrqkKlhRuUdCg/ 2iwxVL+9dVgRSkmN2VLpNUC18h/+2jgFl/myRlHvF8UGwxmGlkvKWiVk2kOAe/Ix uEh82XvVmDPCvTGgjmKmk2ZWOTWRlTXgOxAaEHG0IdJCtzGOUT6molScilMXPpen 3n32vSuedwyo8YZ1x8uA =568t -----END PGP SIGNATURE----- From mamille2@cisco.com Sun Mar 25 07:40:06 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 E6F5C21F84C5 for ; Sun, 25 Mar 2012 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 M6pQEx55R-4h for ; Sun, 25 Mar 2012 07:40:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9B21F84AA for ; Sun, 25 Mar 2012 07:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=1370; q=dns/txt; s=iport; t=1332686405; x=1333896005; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=VmFacegwBgBZgt+YcEvjU/8uw/alki0zeGlkgTCpLuY=; b=ZwLXBRnVAIY2iHcU3ry0KlRSyKfLaZDHw89HGluTq/m1gzcDcJT4jrhl 9G4r9G8t2tLbRHKitsQXdLfm+pEA4lHvlz9EFqiAAHrx9xEiPoZO8vY4t f/j0ANUQXyK6CGnB5/o2XmH4+3/BHki8q8rVvPukbIeT3IF2RelfbdilN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKMtb0+rRDoJ/2dsb2JhbABEuCSBB4IJAQEBAgISASdPCxguVwYTIodnDJl5nguQRWMElWCBEY00gWiCaQ X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208";a="34463960" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 25 Mar 2012 14:40:04 +0000 Received: from sjc-vpn5-840.cisco.com (sjc-vpn5-840.cisco.com [10.21.91.72]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2PEe42Z009567 for ; Sun, 25 Mar 2012 14:40:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Matt Miller In-Reply-To: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> Date: Sun, 25 Mar 2012 16:40:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> To: XMPP Group X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Sun, 25 Mar 2012 14:40:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 19, 2012, at 09:49, Ben Campbell wrote: >>=20 >> ----------------------------------- >>=20 >> XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610 >>=20 >> -- Status and Agenda Bashing -- 5 min (Chairs) >>=20 >> -- End to End Encryption (Matt Miller) -- 20 min >> =09 >> htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 >>=20 Slides (subject to change): < = http://outer-planes.net/ietf/ietf83-xmppwg-e2e.pdf > >> -- Domain Name Assertions (Matt Miller) -- 15 min >> =09 >> List Discussion,=20 >> http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >>=20 Slides (subject to change): < = http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPby5GAAoJEJq6Ou0cgrSP02oH/0Yqdybi3vt4U4U0cU15La5P A9Dug8ZUNHhtbICvvDgJHwaDF8ApCa7ORyrfjZL4P6VwGFeVQw19yxbiRyHjn1kp ooXYGk8NEym3LWyvcJ2hVIXc5FtRn8n3FPBvBINlYGP89H+wpAgUz1MmQmteDzRu VCJQgpO7nGgCDk1IT672dphhq6L4WfbtfS03v8JVwKxGl8hQcrE59clbdrJI2MLj a2H6LrwnnDCvS4ebHFLFzbMeNnDHAvD4I99Wpp5Yv6LbZdADCJWlPdWkhoKebfUY 1BVU8ze9bEZn+xetovd4m2ymBw+FQ6OjajbcH/dgVzXzrqic+b8S1XjxjG2WqSU=3D =3DebY3 -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Mar 25 17:12:22 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 2EC2821E804C for ; Sun, 25 Mar 2012 17:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 jmft3S5VOior for ; Sun, 25 Mar 2012 17:12:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA5C21E8018 for ; Sun, 25 Mar 2012 17:12:21 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8A2CD4005B; Sun, 25 Mar 2012 18:25:19 -0600 (MDT) Message-ID: <4F6FB463.1070102@stpeter.im> Date: Mon, 26 Mar 2012 02:12:19 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Matt Miller References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> In-Reply-To: <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Group Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 26 Mar 2012 00:12:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/25/12 4:40 PM, Matt Miller wrote: > > On Mar 19, 2012, at 09:49, Ben Campbell wrote: >>> >>> ----------------------------------- >>> >>> XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 >>> 1510-1610 >>> >>> -- Status and Agenda Bashing -- 5 min (Chairs) >>> >>> -- End to End Encryption (Matt Miller) -- 20 min >>> htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 >>> > > Slides (subject to change): < > http://outer-planes.net/ietf/ietf83-xmppwg-e2e.pdf > > >>> -- Domain Name Assertions (Matt Miller) -- 15 min List >>> Discussion, http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >>> > > Slides (subject to change): < > http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > Yay! Looks like we could have an interesting discussion. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9vtGMACgkQNL8k5A2w/vycLwCgzMPm07cpWxYhIZPpXJ9foUoe H5kAnRxctYP9imYfWNlzvarXHKTju94g =31Ya -----END PGP SIGNATURE----- From mamille2@cisco.com Mon Mar 26 00:26:46 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 F17B621E8098 for ; Mon, 26 Mar 2012 00:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GouHsyv3E1pf for ; Mon, 26 Mar 2012 00:26:43 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AA50821F8498 for ; Mon, 26 Mar 2012 00:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=1716; q=dns/txt; s=iport; t=1332746800; x=1333956400; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=bDHeBeE52LTZ0JoglMp4Fbw35N4xzEtZUKemn9bPfVA=; b=B3GKzOYGUQWk3QGq7g4DQsTvZONW0ui1bcjyz1TK8ZevBN5rFJWM/iHN FGNmT+Oqt9lRu7Y84T3zK6dqrHFfLynVzr5JHYJjgJMlXK4DqcX99/H5X RrRip5WZ9goP8DbvHtrJxRuB7axq0UtE3RgJZv10JqZ3WSF7r7CWR3rCU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHAZcE+rRDoJ/2dsb2JhbABEuC6BB4IJAQEBAgEBEgEnRAsLGC5XBgESIodjBAyZdp4tkEVjBJVggRGNNIFogmk X-IronPort-AV: E=Sophos;i="4.73,649,1325462400"; d="scan'208";a="34524794" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Mar 2012 07:26:37 +0000 Received: from sjc-vpn3-558.cisco.com (sjc-vpn3-558.cisco.com [10.21.66.46]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2Q7QakX012786; Mon, 26 Mar 2012 07:26:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Matt Miller In-Reply-To: <4F6FB463.1070102@stpeter.im> Date: Mon, 26 Mar 2012 09:26:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> To: Peter Saint-Andre , XMPP Group X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 26 Mar 2012 07:26:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 26, 2012, at 02:12, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/25/12 4:40 PM, Matt Miller wrote: >>=20 >> On Mar 19, 2012, at 09:49, Ben Campbell wrote: >>>>=20 >>>> ----------------------------------- >>>>=20 >>>> XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 >>>> 1510-1610 >>>>=20 >>>> -- Status and Agenda Bashing -- 5 min (Chairs) >>>>=20 >>>> -- End to End Encryption (Matt Miller) -- 20 min =20 >>>> htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00 >>>>=20 >>=20 >> Slides (subject to change): < >> http://outer-planes.net/ietf/ietf83-xmppwg-e2e.pdf > >>=20 >>>> -- Domain Name Assertions (Matt Miller) -- 15 min List >>>> Discussion, http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >>>>=20 >>=20 >> Slides (subject to change): < >> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > >=20 slides updated to fix typos (same location) > Yay! Looks like we could have an interesting discussion. :) >=20 That's the hope (-: - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPcBowAAoJEJq6Ou0cgrSP7eMH/iEOKZF8XTVBobxJ/1rzDYH+ 0RkQQTa/vvABlhgWQMLJQ97ECUZmsGkKLRAwjZXguddZdB6ldNyjmJ+ntSodGkxw nX0KWbUbOnqy5QyQehEJ/jchOCP4kumWrOVBRRkCSHuqWq9FHaZKujRwrii7fEFi dQrZ0lk42QicyO6MlIrNsDyxLdRQ02BQ6kCXlbuaO5FQVYrfNwWdXdm872H8Wb9e gl1YpyVZQC0ezSN+lisyRdrnpp1YFZIFDDFNpY96b1iekb/aOMe67TLdU52FxdT7 RJC0Pn8ONK5e419NnTgP7vCTeSFyD1PKlMKQCCwQsHLuqp1bZvR32rgJMSTrrmg=3D =3DzUm9 -----END PGP SIGNATURE----- From ben@nostrum.com Mon Mar 26 05:12:53 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 B6C0C21F85FB for ; Mon, 26 Mar 2012 05:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 33emvIiYXTBa for ; Mon, 26 Mar 2012 05:12:53 -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 78CE621F85A4 for ; Mon, 26 Mar 2012 05:12:39 -0700 (PDT) Received: from [130.129.18.148] (dhcp-1294.meeting.ietf.org [130.129.18.148]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2QCCbFq052514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 07:12:38 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Transfer-Encoding: quoted-printable From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9B176) Message-Id: <8D3E5657-3725-47F3-A9B1-D635803DD013@nostrum.com> Date: Mon, 26 Mar 2012 14:12:36 +0200 To: "xmpp@ietf.org" Mime-Version: 1.0 (1.0) Received-SPF: pass (nostrum.com: 130.129.18.148 is authenticated by a trusted mechanism) Subject: [xmpp] XMPP Minute Takers and Jabber Scribe 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: Mon, 26 Mar 2012 12:12:53 -0000 Hi all, We only have an hour long slot for Wednesday's XMPP meeting. We can get down= to business more quickly if we can get volunteers prior to the meeting. To t= hat end, can we get 2 volunteers to take minutes, and 1 to be the Jabber scr= ibe? At a minimum, minutes should capture issues, resolutions, and action items. M= ore can be better, but it's not usually necessary to capture every "he said/= she said" exchange. For jabber, we primarily need someone to watch the Jabbe= r room for issues that need to go to the mike. It can help to flag speaker i= dentity and slide changes. Thanks! Ben.= From dave@cridland.net Mon Mar 26 07:22:47 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 E700A21E803C for ; Mon, 26 Mar 2012 07:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 rUz2cX98eI-0 for ; Mon, 26 Mar 2012 07:22:46 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4EC21E8013 for ; Mon, 26 Mar 2012 07:22:46 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 77E131168087; Mon, 26 Mar 2012 15:22:42 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwLAazjVe3Y9; Mon, 26 Mar 2012 15:22:39 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 6B61F1168067; Mon, 26 Mar 2012 15:22:39 +0100 (BST) References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> In-Reply-To: <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> MIME-Version: 1.0 Message-Id: <20897.1332771759.413167@puncture> Date: Mon, 26 Mar 2012 15:22:39 +0100 From: Dave Cridland To: Matt Miller , Peter Saint-Andre , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 26 Mar 2012 14:22:47 -0000 On Mon Mar 26 08:26:40 2012, Matt Miller wrote: > >> Slides (subject to change): < > >> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > A few comments: 1) I still maintain you don't need to change XMPP on the wire at all to handle this case. All you need to do is change, in effect, the out of band RFC 6125 replacement which allows us to delegate service to a specific cert. 2) You needn't signal to a connecting entity (C2S or S2S) that you're capable of using this replacement, whichever it is. How you authenticate people is up to you; how they authenticate you is up to them. You present the best certificate you can in each case. 3) You needn't change the on-wire format of XEP-0220 either - dialback can carry a key even if it's ignored by the other end. Doing things this way is not only simpler, it also means that there's no fork-lift required. Now, you *can* have a stream feature so that servers can boast about how they use DANE, .well-known, and TurboHalibut - but this is essentially in-line marketing, and it's equivalent to suggesting that clients should list what SASL mechanisms they will use to servers. Really, the peer (client or server) will trust what it trusts. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Mon Mar 26 08:53: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 91C2721E80D0 for ; Mon, 26 Mar 2012 08:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.767 X-Spam-Level: X-Spam-Status: No, score=-104.767 tagged_above=-999 required=5 tests=[AWL=-2.168, 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 Efl9sCcXEPIO for ; Mon, 26 Mar 2012 08:53:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D296D21E80A3 for ; Mon, 26 Mar 2012 08:53:26 -0700 (PDT) Received: from dhcp-5052.meeting.ietf.org (unknown [130.129.80.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D057E40058; Mon, 26 Mar 2012 10:06:26 -0600 (MDT) Message-ID: <4F7090F4.2070900@stpeter.im> Date: Mon, 26 Mar 2012 17:53:24 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> <20897.1332771759.413167@puncture> In-Reply-To: <20897.1332771759.413167@puncture> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 26 Mar 2012 15:53:27 -0000 On 3/26/12 4:22 PM, Dave Cridland wrote: > On Mon Mar 26 08:26:40 2012, Matt Miller wrote: >> >> Slides (subject to change): < >> >> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > > > A few comments: > > 1) I still maintain you don't need to change XMPP on the wire at all to > handle this case. > > All you need to do is change, in effect, the out of band RFC 6125 > replacement which allows us to delegate service to a specific cert. > > 2) You needn't signal to a connecting entity (C2S or S2S) that you're > capable of using this replacement, whichever it is. How you authenticate > people is up to you; how they authenticate you is up to them. You > present the best certificate you can in each case. > > 3) You needn't change the on-wire format of XEP-0220 either - dialback > can carry a key even if it's ignored by the other end. Yes, that's broadly consistent with what Matt Miller, Richard Barnes, and I discussed yesterday. Peter -- Peter Saint-Andre https://stpeter.im/ From fippo@goodadvice.pages.de Mon Mar 26 11:16:57 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 14B2C21E80F7 for ; Mon, 26 Mar 2012 11:16:57 -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 j5O6KUNLYdDR for ; Mon, 26 Mar 2012 11:16:56 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 579E321E80CE for ; Mon, 26 Mar 2012 11:16:55 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2QIGoID004070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 20:16:50 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id q2QIGnce004066; Mon, 26 Mar 2012 20:16:50 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Mon, 26 Mar 2012 20:16:49 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Dave Cridland In-Reply-To: <20897.1332771759.413167@puncture> Message-ID: References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> <20897.1332771759.413167@puncture> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 27 Mar 2012 07:19:14 -0700 Cc: XMPP Working Group Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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: Mon, 26 Mar 2012 18:21:10 -0000 On Mon, 26 Mar 2012, Dave Cridland wrote: > All you need to do is change, in effect, the out of band RFC 6125 replacement > which allows us to delegate service to a specific cert. well, you still need to answer the "when to multiplex two target domains to the same tcp connextion" issue. Sounds trivial (same ip/port + support for dialback errors as described in 220), but even I was scared when implementing this. The main problem is that it takes quite a number of round trips to discover the latter condition. That quickly becomes ugly and inefficient. bidi helps a little at least. From mamille2@cisco.com Wed Mar 28 00:50:40 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 0B23621F88E6 for ; Wed, 28 Mar 2012 00:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 y1J2qxp9OAGe for ; Wed, 28 Mar 2012 00:50:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98D21F88E5 for ; Wed, 28 Mar 2012 00:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=2040; q=dns/txt; s=iport; t=1332921038; x=1334130638; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rUBU0l7ezJVpElfKxz65NlbCvFP522GbNFUbJPF/dts=; b=lcGKtdEgCoTvOiplq+YyOAfwS+OZRjcCWOGBWUlamKB8NWleO0UiffOZ yqNlJdjV2AUOzkJ18iptSv6grjzVRvUFOZE5ZQL6fCdi2HJpvWGUmkze2 SnKJPuyUj+FIiZHTde3d0/DPG/LVpfud5qJK54cDjAa4hrNp2Jr/Xe9i3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEvCck+rRDoI/2dsb2JhbABFuGuBB4IJAQEBAgEBEgEnPwULCxguVwYTIodjBAybLJ8SkBxjBJVhgRGNNIFogmk X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="37991099" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Mar 2012 07:50:38 +0000 Received: from sjc-vpn7-410.cisco.com (sjc-vpn7-410.cisco.com [10.21.145.154]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S7oaJj016672; Wed, 28 Mar 2012 07:50:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matt Miller In-Reply-To: <4F7090F4.2070900@stpeter.im> Date: Wed, 28 Mar 2012 09:50:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E985E8A-F635-40A4-8DC3-10023E2C490A@cisco.com> References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> <20897.1332771759.413167@puncture> <4F7090F4.2070900@stpeter.im> To: Peter Saint-Andre X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Working Group Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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, 28 Mar 2012 07:50:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 26, 2012, at 17:53, Peter Saint-Andre wrote: > On 3/26/12 4:22 PM, Dave Cridland wrote: >> On Mon Mar 26 08:26:40 2012, Matt Miller wrote: >>>>> Slides (subject to change): < >>>>> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf > >>=20 >> A few comments: >>=20 >> 1) I still maintain you don't need to change XMPP on the wire at all = to >> handle this case. >>=20 >> All you need to do is change, in effect, the out of band RFC 6125 >> replacement which allows us to delegate service to a specific cert. >>=20 >> 2) You needn't signal to a connecting entity (C2S or S2S) that you're >> capable of using this replacement, whichever it is. How you = authenticate >> people is up to you; how they authenticate you is up to them. You >> present the best certificate you can in each case. >>=20 >> 3) You needn't change the on-wire format of XEP-0220 either - = dialback >> can carry a key even if it's ignored by the other end. >=20 > Yes, that's broadly consistent with what Matt Miller, Richard Barnes, > and I discussed yesterday. >=20 Richard Barnes expressed a desire for the receiving server to *require* = the initiating server support these alternatives. I tentatively agree = that this can be done with no changes, but not yet completely (-: Sounds like we'll have a fruitful discussion today at 13:10Z (-: - - m&m Matt Miller - Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPcsLVAAoJEJq6Ou0cgrSPhcsIAJcga+dQd8RoOYKKtqflPPy6 88Cf+kbWJIrmz2JU5cgxEq3jx7oMnd9Kl+goPrLHuEinbppEc16SXgGNGGATS0Xj B/fo8QRooZhD1obe1Djtsehw9CUqeouUAU4+WOXYvDuoU2QTMe7yHQjJQGZxjewG gtdcmZyrNRfn5BO8jbzD0bIFQH3HZsnkUWKQzCI5OmUDbf14ojtLkzaYhEOwQe/v uCisJ2mr9uNSjsnoq/hgcpKILeStftXkF8OA7m5+8Hy3RveEdSnBi7kTTRCAqUdv hwdJi8FLR2ad7WvbJcEuyNV+XgyPGP8uPVkeN6yztiUs20G/T2VyymQHwJviOdM=3D =3DaLsg -----END PGP SIGNATURE----- From ben@nostrum.com Wed Mar 28 00:59:58 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 24EC721F8952 for ; Wed, 28 Mar 2012 00:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.466, 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 h05WEqbgNwxU for ; Wed, 28 Mar 2012 00:59:57 -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 93ABF21F892C for ; Wed, 28 Mar 2012 00:59:57 -0700 (PDT) Received: from dhcp-6231.meeting.ietf.org (dhcp-6231.meeting.ietf.org [130.129.98.49]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2S7xtix080807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Mar 2012 02:59:56 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Mar 2012 09:59:49 +0200 Message-Id: <949A55E1-8099-4503-AED7-11314E4C15C0@nostrum.com> To: XMPP Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 130.129.98.49 is authenticated by a trusted mechanism) Subject: [xmpp] Meeting Slides 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, 28 Mar 2012 07:59:58 -0000 Hi All, I've uploaded all the slides for this afternoon's meeting: https://datatracker.ietf.org/meeting/83/materials.html#wg-xmpp Thanks! Ben. From dave@cridland.net Wed Mar 28 01:00:12 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 6062D21F8974 for ; Wed, 28 Mar 2012 01:00:12 -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 Z0MmMnZqidAs for ; Wed, 28 Mar 2012 01:00:11 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13421F8973 for ; Wed, 28 Mar 2012 01:00:10 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 9B0F11168087; Wed, 28 Mar 2012 09:00:03 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4wnFMMQkphe; Wed, 28 Mar 2012 09:00:00 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 8951B1168067; Wed, 28 Mar 2012 09:00:00 +0100 (BST) References: <3FE6136B-8AAF-4F29-BFA8-AAB9C5C84442@nostrum.com> <398B8404-1DCA-491B-BE2E-2F57074A38E3@cisco.com> <4F6FB463.1070102@stpeter.im> <1831DACE-D423-44FB-8F8A-C0C88FCF6574@cisco.com> <20897.1332771759.413167@puncture> <4F7090F4.2070900@stpeter.im> <1E985E8A-F635-40A4-8DC3-10023E2C490A@cisco.com> In-Reply-To: <1E985E8A-F635-40A4-8DC3-10023E2C490A@cisco.com> MIME-Version: 1.0 Message-Id: <20897.1332921600.547831@puncture> Date: Wed, 28 Mar 2012 09:00:00 +0100 From: Dave Cridland To: Matt Miller , XMPP Working Group , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Draft XMPP Agenda for IETF83 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, 28 Mar 2012 08:00:12 -0000 On Wed Mar 28 08:50:44 2012, Matt Miller wrote: > Richard Barnes expressed a desire for the receiving server to > *require* the initiating server support these alternatives. I > tentatively agree that this can be done with no changes, but not > yet completely (-: So the receiving server needs to require the initiator to authenticate it in certain ways? What if those ways are considered insufficient by the initiator? What if the initiator supports other ways, which work to its satisfaction? How far do we go - do we mandate trust anchors? Allowable SANs? How does the receiving server enforce its requirement? I don't really see the benefit of going this route. (I do see a benefit to servers to have a configured list of how they think they could be authenticated, but equally that then has the possibility of needing code changes on the receiving server, which otherwise isn't mandated, so...) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ben@nostrum.com Wed Mar 28 04:53:01 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 CA5E121E8101 for ; Wed, 28 Mar 2012 04:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.139 X-Spam-Level: X-Spam-Status: No, score=-101.139 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 kw3RPJj3TguM for ; Wed, 28 Mar 2012 04:53:01 -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 37FCF21E80AA for ; Wed, 28 Mar 2012 04:53:01 -0700 (PDT) Received: from [10.75.94.229] (mobile-166-147-068-036.mycingular.net [166.147.68.36]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2SBqtZX025260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 06:53:00 -0500 (CDT) (envelope-from ben@nostrum.com) References: <8D3E5657-3725-47F3-A9B1-D635803DD013@nostrum.com> In-Reply-To: <8D3E5657-3725-47F3-A9B1-D635803DD013@nostrum.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <633123C6-A657-4D43-849E-C73C341E7A51@nostrum.com> X-Mailer: iPad Mail (9B176) From: Ben Campbell Date: Wed, 28 Mar 2012 13:52:47 +0200 To: Ben Campbell Received-SPF: pass (nostrum.com: 166.147.68.36 is authenticated by a trusted mechanism) Cc: "xmpp@ietf.org" Subject: Re: [xmpp] XMPP Minute Takers and Jabber Scribe 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, 28 Mar 2012 11:53:02 -0000 We've got one volunteer so far. Anyone else? On Mar 26, 2012, at 2:12 PM, Ben Campbell wrote: > Hi all, >=20 > We only have an hour long slot for Wednesday's XMPP meeting. We can get do= wn to business more quickly if we can get volunteers prior to the meeting. T= o that end, can we get 2 volunteers to take minutes, and 1 to be the Jabber s= cribe? >=20 > At a minimum, minutes should capture issues, resolutions, and action items= . More can be better, but it's not usually necessary to capture every "he sa= id/she said" exchange. For jabber, we primarily need someone to watch the Ja= bber room for issues that need to go to the mike. It can help to flag speake= r identity and slide changes. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From stpeter@stpeter.im Wed Mar 28 04:55:53 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 E1F5821E811B for ; Wed, 28 Mar 2012 04:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.861 X-Spam-Level: X-Spam-Status: No, score=-102.861 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 2zCxDp-+ZiFW for ; Wed, 28 Mar 2012 04:55:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC021E811C for ; Wed, 28 Mar 2012 04:55:51 -0700 (PDT) Received: from dhcp-153f.meeting.ietf.org (unknown [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9267040058; Wed, 28 Mar 2012 06:08:57 -0600 (MDT) Message-ID: <4F72FC45.8050501@stpeter.im> Date: Wed, 28 Mar 2012 13:55:49 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Ben Campbell References: <8D3E5657-3725-47F3-A9B1-D635803DD013@nostrum.com> <633123C6-A657-4D43-849E-C73C341E7A51@nostrum.com> In-Reply-To: <633123C6-A657-4D43-849E-C73C341E7A51@nostrum.com> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "xmpp@ietf.org" Subject: Re: [xmpp] XMPP Minute Takers and Jabber Scribe 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, 28 Mar 2012 11:55:53 -0000 Hopefully we can at least get a volunteer to be the Jabber scribe. ;-) On 3/28/12 1:52 PM, Ben Campbell wrote: > We've got one volunteer so far. Anyone else? > > On Mar 26, 2012, at 2:12 PM, Ben Campbell wrote: > >> Hi all, >> >> We only have an hour long slot for Wednesday's XMPP meeting. We can get down to business more quickly if we can get volunteers prior to the meeting. To that end, can we get 2 volunteers to take minutes, and 1 to be the Jabber scribe? >> >> At a minimum, minutes should capture issues, resolutions, and action items. More can be better, but it's not usually necessary to capture every "he said/she said" exchange. For jabber, we primarily need someone to watch the Jabber room for issues that need to go to the mike. It can help to flag speaker identity and slide changes. >> >> Thanks! >> >> Ben. From rbarnes@bbn.com Wed Mar 28 05:00: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 242B021F8852 for ; Wed, 28 Mar 2012 05:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-FMYJP5rNMi for ; Wed, 28 Mar 2012 05:00:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1D621F8838 for ; Wed, 28 Mar 2012 05:00:04 -0700 (PDT) Received: from [128.89.255.10] (port=59334 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCrXV-000HWz-B9; Wed, 28 Mar 2012 07:59:45 -0400 Message-ID: <4F72FD3D.3070008@bbn.com> Date: Wed, 28 Mar 2012 13:59:57 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <8D3E5657-3725-47F3-A9B1-D635803DD013@nostrum.com> <633123C6-A657-4D43-849E-C73C341E7A51@nostrum.com> <4F72FC45.8050501@stpeter.im> In-Reply-To: <4F72FC45.8050501@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "xmpp@ietf.org" Subject: Re: [xmpp] XMPP Minute Takers and Jabber Scribe 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, 28 Mar 2012 12:00:09 -0000 I'll do it. On 3/28/12 1:55 PM, Peter Saint-Andre wrote: > Hopefully we can at least get a volunteer to be the Jabber scribe. ;-) > > On 3/28/12 1:52 PM, Ben Campbell wrote: >> We've got one volunteer so far. Anyone else? >> >> On Mar 26, 2012, at 2:12 PM, Ben Campbell wrote: >> >>> Hi all, >>> >>> We only have an hour long slot for Wednesday's XMPP meeting. We can get down to business more quickly if we can get volunteers prior to the meeting. To that end, can we get 2 volunteers to take minutes, and 1 to be the Jabber scribe? >>> >>> At a minimum, minutes should capture issues, resolutions, and action items. More can be better, but it's not usually necessary to capture every "he said/she said" exchange. For jabber, we primarily need someone to watch the Jabber room for issues that need to go to the mike. It can help to flag speaker identity and slide changes. >>> >>> Thanks! >>> >>> Ben. > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From rbarnes@bbn.com Wed Mar 28 07:12:55 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 62F2F21E825D for ; Wed, 28 Mar 2012 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVvC35b5qChE for ; Wed, 28 Mar 2012 07:12:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 97B2421E8227 for ; Wed, 28 Mar 2012 07:12:54 -0700 (PDT) Received: from [128.89.255.35] (port=59923 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCtc8-000Kte-S4 for xmpp@ietf.org; Wed, 28 Mar 2012 10:12:40 -0400 Message-ID: <4F731C64.3000209@bbn.com> Date: Wed, 28 Mar 2012 16:12:52 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "xmpp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [xmpp] Commonality of proof types 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, 28 Mar 2012 14:12:55 -0000 Just musing on what proof types look like... During the DANE process, Adam Langley proposed a way to serialize "DNSSEC chains" [1]. Basically, you write a file with all the DNS records you need to chain back from some record to the root. I wonder if this would be a nice format for the .well-known proof type. For domains that support DNSSEC, at least to the level of having a DS, this approach has the advantage of not depending on HTTPS for security. After all, relying on HTTPS for our proof type is just kicking the can from a domain where we're not comfortable with hosting providers having certs in their clients' names (XMPP) to one where we are (HTTP). Domains that don't support DNSSEC won't be able to construct a chain all the way back to the root, but it seems like we could specify that in that case, you just provision the chain as far up as you can (or just put in a DANE record), and rely on HTTPS. At least it provides a smooth path forward as more people deploy DNSSEC. And in any case, there are already open-source encoding and validation tools available [2]. Just a thought, --Richard [1] [2] From dave@cridland.net Wed Mar 28 08:37:20 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 8CB4C21E8294 for ; Wed, 28 Mar 2012 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 IMXljPz1350z for ; Wed, 28 Mar 2012 08:37:19 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id A88A121E81B1 for ; Wed, 28 Mar 2012 08:37:15 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AEBE81168087; Wed, 28 Mar 2012 16:37:10 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhDYthNNpZhN; Wed, 28 Mar 2012 16:37:04 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id D1D361168067; Wed, 28 Mar 2012 16:37:02 +0100 (BST) References: <4F731C64.3000209@bbn.com> In-Reply-To: <4F731C64.3000209@bbn.com> MIME-Version: 1.0 Message-Id: <20897.1332949022.825953@puncture> Date: Wed, 28 Mar 2012 16:37:02 +0100 From: Dave Cridland To: "Richard L\. Barnes" , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Commonality of proof types 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, 28 Mar 2012 15:37:20 -0000 On Wed Mar 28 15:12:52 2012, Richard L. Barnes wrote: > Just musing on what proof types look like... That smells like it's somewhat combining the proof types. That is, you're saying we'd use DNSSEC if possible, but to maximize the potential of it working, we'd serialize the chain and stick it somewhere well-known, secured by HTTPS as a final fallback. The serialization of the chain is basically a potted set of the DNS answers (and their signatures) that you'd have got if you'd gone through the DNS anyway. If you can (only) trust the HTTPS cert used to secure the blob, you use that. Does that sounds roughly right? My only concern is that the "bare" certificate in .well-known (as exemplified by TurboHalibut) has a very low implementation threshold[1], whereas this would invoke DNSSEC quite heavily. Dave. [1] - This means it's easy to code. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From rbarnes@bbn.com Wed Mar 28 08:47:52 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 EE00821E81D2 for ; Wed, 28 Mar 2012 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Iyy76DHw8QN for ; Wed, 28 Mar 2012 08:47:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 418F321E80BD for ; Wed, 28 Mar 2012 08:47:52 -0700 (PDT) Received: from [128.89.255.15] (port=60690 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCv61-000O51-4T; Wed, 28 Mar 2012 11:47:37 -0400 Message-ID: <4F7332A5.1030602@bbn.com> Date: Wed, 28 Mar 2012 17:47:49 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Dave Cridland References: <4F731C64.3000209@bbn.com> <20897.1332949022.825953@puncture> In-Reply-To: <20897.1332949022.825953@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Commonality of proof types 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, 28 Mar 2012 15:47:53 -0000 >> Just musing on what proof types look like... > > That smells like it's somewhat combining the proof types. > > That is, you're saying we'd use DNSSEC if possible, but to maximize the > potential of it working, we'd serialize the chain and stick it somewhere > well-known, secured by HTTPS as a final fallback. > > The serialization of the chain is basically a potted set of the DNS > answers (and their signatures) that you'd have got if you'd gone through > the DNS anyway. If you can (only) trust the HTTPS cert used to secure > the blob, you use that. > > Does that sounds roughly right? Yep, you got it. > My only concern is that the "bare" certificate in .well-known (as > exemplified by TurboHalibut) has a very low implementation threshold[1], > whereas this would invoke DNSSEC quite heavily. > > Dave. > > [1] - This means it's easy to code. Appreciate the concern. It does help that there are already tools, as in: