From stpeter@stpeter.im Mon Jul 4 09:38:53 2011 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 7297C11E80C5 for ; Mon, 4 Jul 2011 09:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.774 X-Spam-Level: X-Spam-Status: No, score=-103.774 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK2lcbNBglxB for ; Mon, 4 Jul 2011 09:38:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2026811E80AC for ; Mon, 4 Jul 2011 09:38:52 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CE14040E24 for ; Mon, 4 Jul 2011 10:39:04 -0600 (MDT) Message-ID: <4E11EC8B.2070206@stpeter.im> Date: Mon, 04 Jul 2011 10:38:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-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, 04 Jul 2011 16:38:53 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-chen-xmpp-pubsub-extension-00.txt Date: Mon, 04 Jul 2011 09:22:55 -0700 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 : XMPP Pubsub Extenstion for Long-lived TCP Services Author(s) : Gang Chen Filename : draft-chen-xmpp-pubsub-extension-00.txt Pages : 5 Date : 2011-07-04 This memo defines extensions to pubsub features of the Extensible Messaging and Presence Protocol (XMPP) that will address issues encountered by a long-lived TCP connection in mobile environments. Network resources consumption issues are happenned when there are frequent notification messages have been transmitted periodically. Depending on raised issues, the extension for XMPP pubsub protocol could be considered to optimize network quality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-xmpp-pubsub-extension-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-chen-xmpp-pubsub-extension-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 Jul 4 09:43:45 2011 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 B377811E80CD for ; Mon, 4 Jul 2011 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F437BgmWkziS for ; Mon, 4 Jul 2011 09:43:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0747211E80CC for ; Mon, 4 Jul 2011 09:43:45 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 50B2B40E24 for ; Mon, 4 Jul 2011 10:43:57 -0600 (MDT) Message-ID: <4E11EDBE.3080406@stpeter.im> Date: Mon, 04 Jul 2011 10:43:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: [precis] [remind] Precis interim meeting: July 6th 13:00 UTC 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, 04 Jul 2011 16:43:45 -0000 This meeting of the PRECIS WG might be of interest to XMPP folks... -------- Original Message -------- Subject: [precis] [remind] Precis interim meeting: July 6th 13:00 UTC Date: Mon, 04 Jul 2011 23:56:10 +0900 (JST) From: Yoshiro YONEYA To: precis@ietf.org This is reminder and instruction of precis WG interim meeting. As announced before, we'll have interim meeting on July 6th, 13:00 UTC, which is: - July 6th, 09:00 Montreal - July 6th, 07:00 Denver - July 6th, 06:00 Seattle - July 6th, 22:00 Tokyo Proposed agenda items are problem-statement and framework document. For the framework document, co-chairs are planning to adopt it as WG document according to WG charter. If you have any objections, please explain them and discuss in the interim meeting. The interim meeting is scheduled as WebEx meeting. Please follow the following instructions to join the meeting. ====================================================================== Topic: PRECIS Date: Wednesday, July 6, 2011 Time: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 963 409 853 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=154184662&UID=1215987537&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=154184662&UID=1215987537&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=154184662&tollFree=0 Access code:963 409 853 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". ====================================================================== See you soon! Marc&Yoneya, co-chairs. -- Yoshiro YONEYA _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis From wwwrun@rfc-editor.org Wed Jul 6 02:06:33 2011 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 470A721F84C9 for ; Wed, 6 Jul 2011 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmYgmIRfc1hU for ; Wed, 6 Jul 2011 02:06:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id D833221F84C7 for ; Wed, 6 Jul 2011 02:06:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6F7698C506; Wed, 6 Jul 2011 02:06:32 -0700 (PDT) To: psaintan@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, jhildebr@cisco.com From: RFC Errata System Message-Id: <20110706090632.B6F7698C506@rfc-editor.org> Date: Wed, 6 Jul 2011 02:06:32 -0700 (PDT) Cc: toby@moncaster.com, xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] [Editorial Errata Reported] RFC6120 (2855) 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, 06 Jul 2011 09:06:33 -0000 The following errata report has been submitted for RFC6120, "Extensible Messaging and Presence Protocol (XMPP): Core". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6120&eid=2855 -------------------------------------- Type: Editorial Reported by: Toby Moncaster Section: 3.2.1 Original Text ------------- 3. If a response is received, it will contain one or more combinations of a port and FDQN, Corrected Text -------------- 3. If a response is received, it will contain one or more combinations of a port and FQDN, Notes ----- There are multiple occurrences (1 each in list items 3, 4, 5, 6 & 7). All read FDQN and should read FQDN Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6120 (draft-ietf-xmpp-3920bis-22) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Core Publication Date : March 2011 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From stpeter@stpeter.im Wed Jul 6 06:22:17 2011 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 BF98B21F866A for ; Wed, 6 Jul 2011 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adaXysK-I5l5 for ; Wed, 6 Jul 2011 06:22:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBDF21F865D for ; Wed, 6 Jul 2011 06:22:17 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C43B140327 for ; Wed, 6 Jul 2011 07:22:20 -0600 (MDT) Message-ID: <4E146186.7000304@stpeter.im> Date: Wed, 06 Jul 2011 07:22:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-iab-identifier-comparison-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, 06 Jul 2011 13:22:17 -0000 This document is relevant to the XMPP WG since it will likely be referenced from the security considerations of 6122bis. -------- Original Message -------- Subject: I-D Action: draft-iab-identifier-comparison-00.txt Date: Sat, 02 Jul 2011 11:38:34 -0700 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 : Issues in Identifier Comparison for Security Purposes Author(s) : Dave Thaler Filename : draft-iab-identifier-comparison-00.txt Pages : 19 Date : 2011-07-02 Identifiers such as hostnames, URIs/IRIs, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier supplied via some protocol is often compared against some policy to make security decisions such as whether the principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-identifier-comparison-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-iab-identifier-comparison-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 Jul 11 15:36:47 2011 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 F18D211E834D for ; Mon, 11 Jul 2011 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGCNRPYRH8Wz for ; Mon, 11 Jul 2011 15:36:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BDAA511E834C for ; Mon, 11 Jul 2011 15:36:44 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C95F40FFF for ; Mon, 11 Jul 2011 16:37:03 -0600 (MDT) Message-ID: <4E1B7AFB.7080406@stpeter.im> Date: Mon, 11 Jul 2011 16:36:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-saintandre-xmpp-6122bis-01.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, 11 Jul 2011 22:36:48 -0000 FYI, I've updated my 6122bis document to reflect changes to the PRECIS framework spec. Peter -------- Original Message -------- Subject: I-D Action: draft-saintandre-xmpp-6122bis-01.txt Date: Mon, 11 Jul 2011 15:19:58 -0700 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 : Extensible Messaging and Presence Protocol (XMPP): Address Format Author(s) : Peter Saint-Andre Filename : draft-saintandre-xmpp-6122bis-01.txt Pages : 17 Date : 2011-07-11 This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for Unicode characters outside the US-ASCII range. This document obsoletes RFC 6122. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-6122bis-01.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-xmpp-6122bis-01.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 waqas20@gmail.com Mon Jul 11 17:00:26 2011 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 E2F8D11E83D9 for ; Mon, 11 Jul 2011 17:00:26 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqJcGWXUOGsc for ; Mon, 11 Jul 2011 17:00:26 -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 931FE11E83E8 for ; Mon, 11 Jul 2011 17:00:25 -0700 (PDT) Received: by ywp31 with SMTP id 31so1331461ywp.31 for ; Mon, 11 Jul 2011 17:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1x2Botwdpneu6TW43JFVNDfoAu1lo1mCKES0nChigVQ=; b=xgq7ao4t+brxxis/7hLHvT3yeS3u1S/T0GhpJlKVguKzqQb62UIVD8TpAmkCXCHIQS 2jDC2hOeR/3tMXYIkzbNal8peb8Ee31vPvrhuCrQWOvoQeZaTJaAjjb6rZXswyd/zMsU eqYImIWEUq7QonfVRANdmi8hZCmDGFwIWRfNw= Received: by 10.151.137.1 with SMTP id p1mr4941022ybn.415.1310428825095; Mon, 11 Jul 2011 17:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Mon, 11 Jul 2011 17:00:05 -0700 (PDT) In-Reply-To: <4E1B7AFB.7080406@stpeter.im> References: <4E1B7AFB.7080406@stpeter.im> From: Waqas Hussain Date: Tue, 12 Jul 2011 05:00:05 +0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-saintandre-xmpp-6122bis-01.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, 12 Jul 2011 00:00:27 -0000 On Tue, Jul 12, 2011 at 3:36 AM, Peter Saint-Andre wrote: > FYI, I've updated my 6122bis document to reflect changes to the PRECIS > framework spec. > > Peter > Diff for those interested: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/rfc/rfc6122.txt&url2=http://www.ietf.org/id/draft-saintandre-xmpp-6122bis-01.txt From chengang@chinamobile.com Wed Jul 13 03:07:16 2011 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 7687E11E8072 for ; Wed, 13 Jul 2011 03:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.551 X-Spam-Level: * X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4tnVoZlPgZW for ; Wed, 13 Jul 2011 03:07:12 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7121F8788 for ; Wed, 13 Jul 2011 03:07:11 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E706AA49A for ; Wed, 13 Jul 2011 18:07:09 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id D33F4A495 for ; Wed, 13 Jul 2011 18:07:09 +0800 (CST) Received: from LENOVO1E4798BB ([10.2.2.228]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011071318070760-17085 ; Wed, 13 Jul 2011 18:07:07 +0800 From: "ChenGang" To: Date: Wed, 13 Jul 2011 18:07:05 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcxBRJ5C9EO/zwf+R1y6MdNf6FQARw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-13 18:07:07, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-13 18:07:09, Serialize complete at 2011-07-13 18:07:09 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01CC4187.AC8B9140" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18256.006 X-TM-AS-Result: No--25.316-7.0-31-10 X-imss-scan-details: No--25.316-7.0-31-10;No--25.316-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-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, 13 Jul 2011 10:07:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01CC4187.AC8B9140 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Dear all, I would like to provide a short description to explain the reasons we propose this work in XMPP area. Always-on applications are quite prevalent in current mobile network. These applications are based on TCP/IP. And, application flows require one long-lived TCP connection between clients and servers. In order to keep application session going, frequent notifications are transmitted. A number of notifications will occupy significant part of air resources and also cause battery consumption of mobile terminals. Furthermore, it will affect establishment of normal voice call. We would like adopt XMPP architecture to resolve the problems. We noticed XMPP suits well for wireless environments in terms of using persistent TCP connections. For now several other and different IM/Presence technologies are available. XMPP pubsub fits well in such environment to facilitate the interoperability. I'm also aware of proposed work is not in the current XMPP work group charter. However the requirements is existing and waiting for the solution. We are expecting a lightweight and XMPP extensible solution to advance such work in IETF. So, we would like to take this chance to discuss further. Comments are welcome Many thanks Gang _____ * From: Peter Saint-Andre < stpeter at stpeter.im> * To: XMPP < xmpp at ietf.org> * Date: Mon, 04 Jul 2011 10:38:35 -0600
FYI. -------- Original Message -------- Subject: I-D Action: draft-chen-xmpp-pubsub-extension-00.txt Date: Mon, 04 Jul 2011 09:22:55 -0700 From: internet-drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : XMPP Pubsub Extenstion for Long-lived TCP Services Author(s) : Gang Chen Filename : draft-chen-xmpp-pubsub-extension-00.txt Pages : 5 Date : 2011-07-04 This memo defines extensions to pubsub features of the Extensible Messaging and Presence Protocol (XMPP) that will address issues encountered by a long-lived TCP connection in mobile environments. Network resources consumption issues are happenned when there are frequent notification messages have been transmitted periodically. Depending on raised issues, the extension for XMPP pubsub protocol could be considered to optimize network quality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-xmpp-pubsub-extension-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-chen-xmpp-pubsub-extension-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at 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 ------=_NextPart_000_0074_01CC4187.AC8B9140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII"

Dear all,

 

I would like to provide a short description to = explain the reasons we propose this work in XMPP = area.

Always-on applications are quite prevalent in = current mobile network. These applications are based on TCP/IP. =

And, application flows require one long-lived = TCP connection between clients and servers.

In order to keep application session going, = frequent notifications are transmitted.

A number of notifications will occupy = significant part of air resources and also cause battery consumption of mobile = terminals.

Furthermore, it will affect establishment of = normal voice call.

 

We would like adopt XMPP architecture to = resolve the problems.

We noticed XMPP suits well for wireless = environments in terms of using persistent TCP connections. =

For now several other and different IM/Presence technologies are available.

XMPP pubsub fits well in such environment to facilitate the interoperability.

 

I’m also aware of proposed = work is not in the current XMPP work group charter. =

However the requirements is existing and = waiting for the solution.

We are expecting a lightweight and XMPP = extensible solution to advance such work in IETF.

So, we would like to take this chance to = discuss further.

Comments are = welcome

 

Many thanks

 

Gang

 

<hr size=3D2 width=3D"100%" align=3Dcenter> 

FYI.
 
-------- Original Message =
--------
Subject: I-D Action: =
draft-chen-xmpp-pubsub-extension-00.txt
Date: Mon, 04 Jul 2011 09:22:55 = -0700
From: internet-drafts at =
ietf.org
Reply-To: internet-drafts at =
ietf.org
To: i-d-announce at =
ietf.org
 
A New Internet-Draft is available from the =
on-line Internet-Drafts
directories.
 
        =
Title           : XMPP =
Pubsub Extenstion for Long-lived TCP =
Services
        =
Author(s)       : Gang =
Chen
        =
Filename        : =
draft-chen-xmpp-pubsub-extension-00.txt
        = Pages           : = 5
        =
Date            : =
2011-07-04
<=
font
size=3D3 face=3D宋体> 
   This memo defines extensions to =
pubsub features of the =
Extensible
   Messaging and Presence Protocol =
(XMPP) that will address issues
   encountered by a long-lived TCP =
connection in mobile =
environments.
   Network resources consumption =
issues are happenned when there =
are
   frequent notification messages =
have been transmitted =
periodically.
   Depending on raised issues, the =
extension for XMPP pubsub =
protocol
   could be considered to optimize =
network quality.
 
 
A URL for this Internet-Draft =
is:
http://www.ietf.org/internet-drafts/draft-chen-xmpp-pubsub-ex=
tension-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-chen-xmpp-pubsub-exte=
nsion-00.txt
______________________________________________=
_
I-D-Announce mailing =
list
I-D-Announce at =
ietf.org
https://www.i=
etf.org/mailman/listinfo/i-d-announce
<= pre>Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt

 

 

 

------=_NextPart_000_0074_01CC4187.AC8B9140-- From dave@cridland.net Wed Jul 13 03:32:41 2011 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 7A31621F8AF1 for ; Wed, 13 Jul 2011 03:32:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWfGdwTlvKtA for ; Wed, 13 Jul 2011 03:32:36 -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 0F36321F8A4D for ; Wed, 13 Jul 2011 03:32:35 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8DB6B1168087; Wed, 13 Jul 2011 11:32:30 +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 WaEtbZ0QpFQg; Wed, 13 Jul 2011 11:32:23 +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 F10D41168067; Wed, 13 Jul 2011 11:32:22 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <24069.1310553142.988452@puncture> Date: Wed, 13 Jul 2011 11:32:22 +0100 From: Dave Cridland To: ChenGang , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-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, 13 Jul 2011 10:32:41 -0000 On Wed Jul 13 11:07:05 2011, ChenGang wrote: > I'm also aware of proposed work is not in the current XMPP work > group > charter. > > However the requirements is existing and waiting for the solution. I actually think you'd be best raising this in the XSF, rather than IETF. I understand what you're aiming to do, but the expertise you need will be found within the XSF, and this specification will be extending XEP-0060 anyway, so will be simpler to do as a XEP. Also, I think your design is slightly wrong. What you should do is have users subscribe normally, using their bare jid, but have the server bunch the notifications. I think I could probably implement this relatively easily, whereas if each pubsub node has to be individually configured with timing information, I need to coordinate that timing across all pubsub services for it to be of the same benefit. 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 chengang@chinamobile.com Thu Jul 14 21:22:34 2011 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 5374911E8070 for ; Thu, 14 Jul 2011 21:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RXewBcyR5CN for ; Thu, 14 Jul 2011 21:22:30 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0C228011 for ; Thu, 14 Jul 2011 21:22:24 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 9BAE09FF0; Fri, 15 Jul 2011 12:22:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id A2EE7A93B; Fri, 15 Jul 2011 12:21:03 +0800 (CST) Received: from LENOVO1E4798BB ([10.2.0.88]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011071512205429-8289 ; Fri, 15 Jul 2011 12:20:54 +0800 From: "ChenGang" To: "'Dave Cridland'" , "'XMPP Working Group'" References: <24069.1310553142.988452@puncture> Date: Fri, 15 Jul 2011 12:20:49 +0800 Message-ID: <766A88003B1E484F9213698200B7C032@LENOVO1E4798BB> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <24069.1310553142.988452@puncture> Thread-Index: AcxBSC3f1xWlc8KERq+A/EnA14JZ4wBXSedg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-15 12:20:54, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-15 12:21:04, Serialize complete at 2011-07-15 12:21:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18262.004 X-TM-AS-Result: No--15.146-7.0-31-10 X-imss-scan-details: No--15.146-7.0-31-10;No--15.146-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-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: Fri, 15 Jul 2011 04:22:34 -0000 Hello Dave, I agree that is a way to advance such works in XSF. The original motivation to put this effort in IETF is we would like to implement XMPP-based solution conforming to RFC6120. We are not targeting to deploy pure XMPP pubsub solution. A lightweight & XMPP CORE compatible solution is more preferred. So, I think that is helpful to get comments from IETF community. Many thanks Gang -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, July 13, 2011 6:32 PM To: ChenGang; XMPP Working Group Subject: Re: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-00.txt On Wed Jul 13 11:07:05 2011, ChenGang wrote: > I'm also aware of proposed work is not in the current XMPP work > group > charter. > > However the requirements is existing and waiting for the solution. I actually think you'd be best raising this in the XSF, rather than IETF. I understand what you're aiming to do, but the expertise you need will be found within the XSF, and this specification will be extending XEP-0060 anyway, so will be simpler to do as a XEP. Also, I think your design is slightly wrong. What you should do is have users subscribe normally, using their bare jid, but have the server bunch the notifications. I think I could probably implement this relatively easily, whereas if each pubsub node has to be individually configured with timing information, I need to coordinate that timing across all pubsub services for it to be of the same benefit. 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 dave@cridland.net Fri Jul 15 01:16:59 2011 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 A3ACE21F876C for ; Fri, 15 Jul 2011 01:16:59 -0700 (PDT) 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_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDY9lG738udF for ; Fri, 15 Jul 2011 01:16:54 -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 42B1121F875E for ; Fri, 15 Jul 2011 01:16:54 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 5FF161168087; Fri, 15 Jul 2011 09:16:51 +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 y6F+9vphBK35; Fri, 15 Jul 2011 09:16:48 +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 36E321168067; Fri, 15 Jul 2011 09:16:48 +0100 (BST) References: <24069.1310553142.988452@puncture> <766A88003B1E484F9213698200B7C032@LENOVO1E4798BB> In-Reply-To: <766A88003B1E484F9213698200B7C032@LENOVO1E4798BB> MIME-Version: 1.0 Message-Id: <16793.1310717808.224278@puncture> Date: Fri, 15 Jul 2011 09:16:48 +0100 From: Dave Cridland To: ChenGang , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] Fwd: I-D Action: draft-chen-xmpp-pubsub-extension-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: Fri, 15 Jul 2011 08:16:59 -0000 On Fri Jul 15 05:20:49 2011, ChenGang wrote: > I agree that is a way to advance such works in XSF. > The original motivation to put this effort in IETF is we would like > to > implement XMPP-based solution conforming to RFC6120. > We are not targeting to deploy pure XMPP pubsub solution. A > lightweight & > XMPP CORE compatible solution is more preferred. > So, I think that is helpful to get comments from IETF community. Well, first off, I have to say you should be considering some form of XEP-0060, even if it's a fairly lightweight profile. The deployment of PEP has basically proven that model works. Secondly, I think you're after the same kind of technical solution as google:queue (and I hear there's other forms of that deployed as well). I've a XEP written up for google:queue; I should really polish this off and submit. Then we can use that as the basis for a standards-based, more rigorous solution. You'd be more than welcome to join that effort, both the XSF and IETF constantly lack mobile expertise. 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 Fri Jul 15 12:28:02 2011 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 5366E21F8B4A for ; Fri, 15 Jul 2011 12:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl3bFSrw-sWC for ; Fri, 15 Jul 2011 12:27:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6E21F8B24 for ; Fri, 15 Jul 2011 12:27:57 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 743BF410E8 for ; Fri, 15 Jul 2011 13:28:26 -0600 (MDT) Message-ID: <4E2094BB.8090101@stpeter.im> Date: Fri, 15 Jul 2011 13:27:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] draft slides for 6122bis 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, 15 Jul 2011 19:28:02 -0000 Folks, I've created *draft* slides about 6122bis for the meeting in Quebec City: http://www.saint-andre.com/ietf/ietf81-xmpp-6122bis.pdf Feedback is welcome. I'll try to start threads about the open issues today. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 12:44:33 2011 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 95E1D21F8C62 for ; Fri, 15 Jul 2011 12:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km45krOQdig1 for ; Fri, 15 Jul 2011 12:44:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39321F8C5F for ; Fri, 15 Jul 2011 12:44:29 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3F33D410E8 for ; Fri, 15 Jul 2011 13:44:58 -0600 (MDT) Message-ID: <4E20989B.1030709@stpeter.im> Date: Fri, 15 Jul 2011 13:44:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: Unicode versions 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, 15 Jul 2011 19:44:33 -0000 The good thing about the post-stringprep world is that we have agility with regard to Unicode versions (a.k.a. "Unicode agility"). No more being stuck at Unicode 3.2! The bad thing is that we have Unicode agility. What if my client (or your server) has Unicode 5.0 but my server has Unicode 6.0? The parties might differ in their interpretation of certain code points, causing problems with authentication, stanza routing, etc. We might be able to mitigate these problems if we had a way to discover which version of Unicode the other side supports. Using XEP-0030 or stream features, we'd want a URI for each Unicode version, such as: http://www.unicode.org/versions/Unicode6.0.0/ (the web page for 6.0) or: urn:unicode:versions:6.0.0 Two questions: 1. Do we think that a service discovery feature would be useful here? 2. If so, do we think the URLs from http://www.unicode.org/ are stable enough, or would people like to have a URN? (I've asked someone from the Unicode Consortium about a URN namespace for Unicode, but if we don't think we'll need it then I won't pursue it further.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 13:04:51 2011 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 3F87C21F8C5F for ; Fri, 15 Jul 2011 13:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WZlDgc2ltRq for ; Fri, 15 Jul 2011 13:04:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49C21F8C50 for ; Fri, 15 Jul 2011 13:04:47 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BF68F410E8 for ; Fri, 15 Jul 2011 14:05:15 -0600 (MDT) Message-ID: <4E209D5D.1090105@stpeter.im> Date: Fri, 15 Jul 2011 14:04:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: error handling 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, 15 Jul 2011 20:04:51 -0000 As far as I can see, most i18n-related error conditions fall into the following categories: 1. Initiating entity includes a non-conforming JID in the 'from' or 'to' attribute of a stream header. Handle via stream error? 2. [I assume that TLS-related errors will be handled at that layer.] 3. Client includes a non-conforming authcid or authzid in a SASL authentication request. Handle via SASL error, or do we need a new condition? 4. Client attempts to bind a non-conforming resourcepart. Handle via stanza error, or should the server generate a conforming resourcepart? (The latter is more friendly.) 5. Server or client includes a non-conforming 'to' or 'from' address on a stanza. Handle via stanza error? 6. Client includes a non-conforming JID in a JID slot that is not used for routing purposes (e.g., 'jid' attribute of roster set). Handle via stanza error? Is checking of such JID slots a MUST or a SHOULD or a MAY on the part of the server? Do we leave this up to the relevant XMPP extension? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 13:18:32 2011 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 0E5A121F8AE1 for ; Fri, 15 Jul 2011 13:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3atlk37zwMY for ; Fri, 15 Jul 2011 13:18:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DAC8C21F8AD9 for ; Fri, 15 Jul 2011 13:18:27 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3CE5410E8 for ; Fri, 15 Jul 2011 14:18:56 -0600 (MDT) Message-ID: <4E20A092.90905@stpeter.im> Date: Fri, 15 Jul 2011 14:18:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: fullwidth and halfwidth characterrs 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, 15 Jul 2011 20:18:32 -0000 As noted at the interim meeting or at IETF 80 or both, some East Asian scripts have fullwidth and halfwidth characters that are compatibility variants for the standard characters. Although this is bad, it's not clear to me that it is an XMPP-specific issue and I think we need to take it up in the PRECIS WG, so I'll post about it there... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 13:23:07 2011 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 26A4D21F8C71 for ; Fri, 15 Jul 2011 13:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar3rqvVJJp37 for ; Fri, 15 Jul 2011 13:23:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 559EA21F8C72 for ; Fri, 15 Jul 2011 13:23:03 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6BBC040327 for ; Fri, 15 Jul 2011 14:23:29 -0600 (MDT) Message-ID: <4E20A1A3.7090905@stpeter.im> Date: Fri, 15 Jul 2011 14:22:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: compliance / enforcement 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, 15 Jul 2011 20:23:07 -0000 RFC 3920 was unclear about what entities need to enforce compliance with the address format, and RFC 6120 didn't really clarify the matter. If we improve the error handling then perhaps this isn't such a big deal, but at the least we need to say whether clients MUST or SHOULD comply (and what that means for each possible JID slot). I think we have agreement that, at a minimum, the server MUST enforce the rules (for some JID slots, anyway). BTW http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-03#section-7 has more details about JID slots. Do people here think it would be helpful to include that text in 6122bis, perhaps just as an informative appendix? Peter -- Peter Saint-Andre https://stpeter.im/ From mamille2@cisco.com Fri Jul 15 13:24:55 2011 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 CEE9B21F8CA5 for ; Fri, 15 Jul 2011 13:24: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3CcLy8LST-E for ; Fri, 15 Jul 2011 13:24:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A197821F8C7D for ; Fri, 15 Jul 2011 13:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5410; q=dns/txt; s=iport; t=1310761491; x=1311971091; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=gX8QsYjuCWijO7N1uAFbPOU4CzpO00vS7x8n5fGzvig=; b=P+t+QzkJ1/VSwe432fMwVwtCnjG8hx08+qWy67RBBRN9mQ3XI5jQeDUr m3MbpchF+fgZgAVEXfBCHUAE+8V/Zo28ZFApgsLgwjT13ULIf1JH722pB tguFVT4DoCy6Y4x/2Ugmv1YT408r6hB9vGbkScyAil8pvzMo5d/nLFRGQ I=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAyhIE6rRDoI/2dsb2JhbABUp293iHqkNJ4mhVtfBIdUixKQcg X-IronPort-AV: E=Sophos;i="4.67,210,1309737600"; d="p7s'?scan'208";a="3421094" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 15 Jul 2011 20:24:51 +0000 Received: from dhcp-64-101-72-203.cisco.com (dhcp-64-101-72-203.cisco.com [64.101.72.203]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6FKOo00010834; Fri, 15 Jul 2011 20:24:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-9--405665824; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <4E20989B.1030709@stpeter.im> Date: Fri, 15 Jul 2011 14:24:59 -0600 Message-Id: References: <4E20989B.1030709@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 15 Jul 2011 20:24:55 -0000 --Apple-Mail-9--405665824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2011, at 13:44, Peter Saint-Andre wrote: > The good thing about the post-stringprep world is that we have agility > with regard to Unicode versions (a.k.a. "Unicode agility"). No more > being stuck at Unicode 3.2! >=20 > The bad thing is that we have Unicode agility. What if my client (or > your server) has Unicode 5.0 but my server has Unicode 6.0? The = parties > might differ in their interpretation of certain code points, causing > problems with authentication, stanza routing, etc. >=20 > We might be able to mitigate these problems if we had a way to = discover > which version of Unicode the other side supports. Using XEP-0030 or > stream features, we'd want a URI for each Unicode version, such as: >=20 > http://www.unicode.org/versions/Unicode6.0.0/ (the web page for 6.0) >=20 > or: >=20 > urn:unicode:versions:6.0.0 >=20 > Two questions: >=20 > 1. Do we think that a service discovery feature would be useful here? >=20 I do think some form of announcing or indicating support is worthwhile, = but I think a service discovery feature would be too late in the = process. A client (or initiating server) cannot reliably disco the = (receiving) server until after it gets through TLS, SASL, and resource = bind. It's not exactly a stream feature, but maybe that's the best = place for fit this? > 2. If so, do we think the URLs from http://www.unicode.org/ are stable > enough, or would people like to have a URN? (I've asked someone from = the > Unicode Consortium about a URN namespace for Unicode, but if we don't > think we'll need it then I won't pursue it further.) I personally don't care either way, as long as we have *something* (-: >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-9--405665824 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcxNTIwMjQ1 OVowIwYJKoZIhvcNAQkEMRYEFA2WgPGnVO1HtaIQvGLfsxSOJY0wMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQB+lfBBUXXKsXPGNXU4ia6bCLgoYUO4Mf7bHcWND0c3HlETtSOIz1iYlDfC EsJ4LHCBzAzBD9XDjtB9AjwqkVH2gVT879jtIz3kV3nZTHtTJmWKixLUGo+Z94yVpCwgwfK2+A+E hjMImjc0oKEYgWhQ1j1G8IojLg+WzWkepCq6hnCL5gVPYBVRtqZlYLdzPJd9QclpUfPahL6CZ9Pp 8x2xEhP/VJ+89skiRzjCv9fsV7n9QdtXcPA++8/8ahGNlphplL23nTcVPeh0Tb7bFMMDvvnEEgaV Op4ibhGEssXc6qi7IyMhbA3X8PBMSzzBbrberTDckZabXiuSAOLXmdWfAAAAAAAA --Apple-Mail-9--405665824-- From stpeter@stpeter.im Fri Jul 15 13:31:45 2011 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 A6B0921F85C4 for ; Fri, 15 Jul 2011 13:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHOTyw+lrVvY for ; Fri, 15 Jul 2011 13:31:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 153DD21F8696 for ; Fri, 15 Jul 2011 13:31:10 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D989410E8 for ; Fri, 15 Jul 2011 14:31:39 -0600 (MDT) Message-ID: <4E20A38C.6040507@stpeter.im> Date: Fri, 15 Jul 2011 14:31:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: servers as "registrars" 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, 15 Jul 2011 20:31:45 -0000 In IDNA, certain aspects of the technology are enforced by domain registrars (e.g., the Hungarian registrars probably won't allow you to register domain names containing Korean code points). In XMPP, a server functions somewhat like a registrar, in the sense that it could define what localparts can be registered (XEP-0077) or provisioned as account names, and define what domains it will host in a virtual hosting setup. Do we want to recommend that servers explicitly define such policies? Do we want to provide suggestions about what such policies contain (e.g., "don't allow registration of localparts or domainparts whose script you don't understand")? If so, do we need to define new error conditions to handle "registrar"-related problems, or can we use existing conditions like or ? Naturally, one policy might be "anything goes" -- i.e., we could define a small set of policies from which a service administrator could choose, where some policies are more restrictive than others. (It might also help if the policy were discoverable.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 13:37:00 2011 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 0916921F8B44 for ; Fri, 15 Jul 2011 13:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgYpaa05VhTz for ; Fri, 15 Jul 2011 13:36:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 40C2F21F8B47 for ; Fri, 15 Jul 2011 13:36:25 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6AE81410E8 for ; Fri, 15 Jul 2011 14:36:54 -0600 (MDT) Message-ID: <4E20A4C8.9020401@stpeter.im> Date: Fri, 15 Jul 2011 14:36:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] 6122bis: migration 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, 15 Jul 2011 20:37:00 -0000 We've talked before about whether we need some kind of network-wide migration plan, perhaps even a flag day (ick). My recollection from the interim meeting or IETF 80 is that we thought it's not really necessary to define such a plan, as long as we clearly define error handling so that old-style XMPP entities that support 3920/6122 can interact with new-style XMPP entities that support 6122bis. Does anyone disagree? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 15 13:37:55 2011 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 BD1EB21F8B81 for ; Fri, 15 Jul 2011 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uVU1qqnGsxX for ; Fri, 15 Jul 2011 13:37:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 930C121F8B64 for ; Fri, 15 Jul 2011 13:37:54 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2D63410E8 for ; Fri, 15 Jul 2011 14:38:23 -0600 (MDT) Message-ID: <4E20A521.5040001@stpeter.im> Date: Fri, 15 Jul 2011 14:37:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP References: <4E2094BB.8090101@stpeter.im> In-Reply-To: <4E2094BB.8090101@stpeter.im> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] draft slides for 6122bis 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, 15 Jul 2011 20:37:55 -0000 On 7/15/11 1:27 PM, Peter Saint-Andre wrote: > I'll try to start threads about the open issues today. Done. If you know of other open issues, please start a separate thread for each. Peter -- Peter Saint-Andre https://stpeter.im/ From rbarnes@bbn.com Fri Jul 15 14:45:55 2011 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 6DC7A21F8AEA for ; Fri, 15 Jul 2011 14:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8tHgHKvhwkK for ; Fri, 15 Jul 2011 14:45:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F40EA21F8ADE for ; Fri, 15 Jul 2011 14:45:54 -0700 (PDT) Received: from [128.89.253.107] (port=49423 helo=[192.168.1.101]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QhqCo-0009oX-Fj for xmpp@ietf.org; Fri, 15 Jul 2011 17:45:54 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 17:45:53 -0400 Message-Id: To: XMPP Working Group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [xmpp] DNA/S2S Part 1: Overview 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, 15 Jul 2011 21:45:55 -0000 Hey all, As has been noted before, there are two sub-problems of the general = "DNA" problem of making server-to-server connections more secure and = scalable: 1. How to verify that a domain has been delegated 2. How to set up a connection and mux in multiple domains There have been some side conversations going on since the Prague = meeting with regard to these questions, and the chairs have asked me to = summarize this discussion to the list. =20 This message will be followed by a message on each topic summarizing the = discussion to date as a starting point for discussion on the list. = Please comment in these threads if you care about these issues. I think = the chairs also plan to have some discussion on these topics in Quebec. =20= --Richard From rbarnes@bbn.com Fri Jul 15 14:46:27 2011 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 9084521F8ADE for ; Fri, 15 Jul 2011 14:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV+oI9FToOq8 for ; Fri, 15 Jul 2011 14:46:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 525C621F856D for ; Fri, 15 Jul 2011 14:46:17 -0700 (PDT) Received: from [128.89.253.107] (port=49423 helo=[192.168.1.101]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QhqDA-0009oX-Qa for xmpp@ietf.org; Fri, 15 Jul 2011 17:46:17 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 17:46:16 -0400 Message-Id: <9841FBF8-11D1-4A81-953E-920EEDA00208@bbn.com> To: XMPP Working Group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [xmpp] DNA/S2S Part 2: Authentication 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, 15 Jul 2011 21:46:27 -0000 One challenge for server-to-server connections is how a server = initiating a connection can verify that the server it connects to is = authorized to represent a delegated domain, without requiring the server = to have a general certificate for that domain. (For more detail, see = draft-ietf-xmpp-dna-01.) The current document focuses on the use of DNSSEC-signed SRV records for = this purpose. Ekr mentioned at the last IETF meeting that he would = prefer a system that didn't rely on DNSSEC. He followed up recently = with a more concrete suggestion, based on having servers certificates = with only the xmppId Subject Alternative Name, and no Common Name. = These certs would thus be usable only for XMPP, not other services = (SMTP, HTTP) for the delegated domain. (I'll leave it to Ekr to provide = more detail.) Given that, some of the trade-offs between the two approaches are: - Issuance: Signing a zone vs. Getting a CA to issue an XMPP cert - Verification: Validating DNSSEC vs. Validating PKIX - Revocation: Limited by DNS TTLs vs. PKIX revocation (CRL/OCSP)=20 Also, in the PKIX-based approach, the server still uses the target = (customer/outsourced) domain name, instead of its own name, so there's = not necessarily a need to update the authentication procedure in RFC = 6120. There is may also be some interaction here with the XMPP dialback = mechanism (XEP-220). In the current document, when a server receives a = dialback request, it uses DNSSEC to verify the remote server's = authorization for a given domain, rather than a dialback "verify" = transaction. In the PKIX-based option, the server would presumably = still use the "verify" transaction, but the authenticated identity of = the server that responds to the "verify" request could be different than = the identity of the server that sent the dialback request. =20 Init. Recv/a.com Recv/b.com | | | |<-------| | |<---------[ auth as b.com ]------->| |<--------------------->| In either case, there's a chance that there will be a change in how a = server responds to a message. So there's a question of = whether this behavior should be specified in the base dialback = specification (either a XEP or an RFC, to be coordinated with XSF). QUESTION-1: Does the group find DNSSEC-signed SRV records or XMPP-only = certificates to be the preferable solution to the problem of providing = authenticating that a given server is authorized to use a domain? = Should this process be integrated with the dialback specification?= From rbarnes@bbn.com Fri Jul 15 14:47:45 2011 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 044DA21F8ADE for ; Fri, 15 Jul 2011 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPiPRriJsEzz for ; Fri, 15 Jul 2011 14:47:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42BFD21F856D for ; Fri, 15 Jul 2011 14:47:40 -0700 (PDT) Received: from [128.89.253.107] (port=49436 helo=[192.168.1.101]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QhqEV-0009pD-PF for xmpp@ietf.org; Fri, 15 Jul 2011 17:47:39 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 17:47:39 -0400 Message-Id: To: XMPP Working Group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [xmpp] DNA/S2S Part 3: Connection management 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, 15 Jul 2011 21:47:45 -0000 One challenge for server-to-server connections is how to manage what how = a connection between two servers is used, in particular, which domains' = stanzas can be carried on the connection. When a domain is delegated to = a server in a different domain, it may also be desirable to modify the = RFC 6120 connection process so that the initiating server connects to = the server's domain instead of the target domain. (For more detail, see = draft-ietf-xmpp-dna-01.) The current document specifies that an initiating server connects to the = remote server's domain, rather than to the "target domain" that it's = actually trying to reach. The initiating server then uses the XMPP = dialback mechanism to request permission to send stanzas for the target = domain.=20 On the other hand, if you look closely at the specification for XMPP = bidirectional server-to-server connection (XEP-0288), you can see that = there's some overlap. While the main purpose of XEP-0288 is to enable a = connection for "a.com->b.com" to also carry stanzas for "b.com->a.com", = in principle, the usage of dialback in XEP-0288 could also be used to = request permission to send stanzas for completely unrelated domain pairs = -- a general connection muxing function. Supposing a general mechanism is developed for binding domain pairs to = connections, it seems like having the initial connection go to the = server itself (as in the current DNA document) might simplify the = overall s2s process, especially in delegation cases. So one could imagine a general "XMPP server-to-server connections" = document that re-defines the RFC6120 server-to-server connection process = in a way that cleanly separates the connection from the domain pair = whose stanzas it carries. This document would define a "connection = management" extension that would facilitate the binding of domain pairs = to a connection, plus any other changes to the s2s connection process = (e.g., connecting to the server first). For the sake of discussion, I've created a skeleton of what such a draft = might look like, supposing it integrated dialback and/or bidi: QUESTION: Should this group develop a more general update to how = server-to-server connections are managed? Should this document subsume = part or all of the current draft of XEP-288? =20= From ben@nostrum.com Fri Jul 15 14:52:13 2011 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 78D8521F8B2A for ; Fri, 15 Jul 2011 14:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMEQ5taA-ipP for ; Fri, 15 Jul 2011 14:52:13 -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 A3D5021F8B4C for ; Fri, 15 Jul 2011 14:52:06 -0700 (PDT) Received: from dn3-227.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 p6FLq2qw090716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 16:52:02 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Fri, 15 Jul 2011 16:52:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7CA082-4EC1-4210-ABC3-A04FFA794FC6@nostrum.com> References: To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] DNA/S2S Part 1: Overview 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, 15 Jul 2011 21:52:13 -0000 Richard: Thanks! All: This subject is in fact the better part of our agenda for Quebec. = But please don't wait until then to discuss it! :-) Thanks, Ben. On Jul 15, 2011, at 4:45 PM, Richard L. Barnes wrote: > Hey all, >=20 > As has been noted before, there are two sub-problems of the general = "DNA" problem of making server-to-server connections more secure and = scalable: > 1. How to verify that a domain has been delegated > 2. How to set up a connection and mux in multiple domains >=20 > There have been some side conversations going on since the Prague = meeting with regard to these questions, and the chairs have asked me to = summarize this discussion to the list. =20 >=20 > This message will be followed by a message on each topic summarizing = the discussion to date as a starting point for discussion on the list. = Please comment in these threads if you care about these issues. I think = the chairs also plan to have some discussion on these topics in Quebec. =20= >=20 > --Richard >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From fippo@mail.symlynx.com Sat Jul 16 00:59:18 2011 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 72A5B21F8620 for ; Sat, 16 Jul 2011 00:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_SKANOVA=0.66] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4lKpwUq-gos for ; Sat, 16 Jul 2011 00:59:18 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 05C2621F861E for ; Sat, 16 Jul 2011 00:59:16 -0700 (PDT) Received: from [192.168.0.65] (h191n7c1o1124.bredband.skanova.com [81.228.158.191]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6G7uXCs016162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jul 2011 09:56:34 +0200 Message-ID: <4E2144C5.40106@mail.symlynx.com> Date: Sat, 16 Jul 2011 09:59:01 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Richard L. Barnes" , XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] DNA/S2S Part 3: Connection management X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 07:59:18 -0000 Richard L. Barnes wrote: > On the other hand, if you look closely at the specification for XMPP bidirectional server-to-server connection (XEP-0288), you can see that there's some overlap. While the main purpose of XEP-0288 is to enable a connection for "a.com->b.com" to also carry stanzas for "b.com->a.com", in principle, the usage of dialback in XEP-0288 could also be used to request permission to send stanzas for completely unrelated domain pairs -- a general connection muxing function. I think the "general connection muxing function" already exists, it was called "piggybacking" in RFC 3920 and is described in the "Multiplexing" section of XEP-0220 (version 0.5 at least). bidi (0288) has an interesting impact on the rules for multiplexing target domains as defined in 220 - it looks as if it simplifies things. There are some notes about that in my working copy already, I'll poke my co-author again for review + approval. From bernard.aboba@gmail.com Sat Jul 16 09:50:33 2011 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 69ABD21F86EE for ; Sat, 16 Jul 2011 09:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgw-OOdb3G-n for ; Sat, 16 Jul 2011 09:50:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0F21F86EC for ; Sat, 16 Jul 2011 09:50:31 -0700 (PDT) Received: by wwe5 with SMTP id 5so1427919wwe.13 for ; Sat, 16 Jul 2011 09:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MItxIfm5eiraKMp+KlJ29m5CnPn2hll0jL58IjHUy/0=; b=cN+VWIavgBaNBUOvSJr8GuGF547l+Z3O93A/fyBNoQq36RIQrHYk7wCSy+F8QbcJnu ATonWaz4XHfHuHybJwNG+Ivm6oEXn5rKYvPri6wBcfezdDLvmtEgxA0ni3cDvbqNF0o0 p3VPQsYwu/ifL/VsBphBExBEYsRDHFs008qY8= Received: by 10.216.221.6 with SMTP id q6mr4174009wep.12.1310835031126; Sat, 16 Jul 2011 09:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.18.71 with HTTP; Sat, 16 Jul 2011 09:50:11 -0700 (PDT) In-Reply-To: <4E20A38C.6040507@stpeter.im> References: <4E20A38C.6040507@stpeter.im> From: Bernard Aboba Date: Sat, 16 Jul 2011 09:50:11 -0700 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=0016e658635c63b42a04a83290ff Cc: XMPP Subject: Re: [xmpp] 6122bis: servers as "registrars" X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 16:50:33 -0000 --0016e658635c63b42a04a83290ff Content-Type: text/plain; charset=ISO-8859-1 I would suggest that there is an important distinction between the role of a registrar in IDNA and the role of an XMPP server. The "Hungarian Registrar" you speak about below is a human, not a software component. The registrar can decide whether to allow a domain name registration based on a number of criteria (e.g. trademarks, etc.) which may not be easily replicated in software, and the existence of these policies does not necessarily imply changes to software. For example, a DNS server can allow RRs to be entered and served which would violate registrar policies (e.g. a label containing Korean code points within the Hungarian CC tld). Given this, I'd be careful to separate discussions of mechanism and policy, and also to be clear when policy can be applied and when it should not be. For example, who gets to decide whether a username can utilize mixed scipts? Is this only the local server creating the username, or can any XMPP client or server interacting with the JID also have its own policies. IMHO, allowing all entities to create (potentially incompatible) policies is probably not a good idea. It is one thing for the Hungarian Registrar to prohibit Koren codepoints within the Hungarian CCTLD; it is another thing for an XMPP server in Hungary to decidde not to accept Korean code points in JIDs, even when the user is hosted on an XMPP server in Korea. On Fri, Jul 15, 2011 at 1:31 PM, Peter Saint-Andre wrote: > In IDNA, certain aspects of the technology are enforced by domain > registrars (e.g., the Hungarian registrars probably won't allow you to > register domain names containing Korean code points). In XMPP, a server > functions somewhat like a registrar, in the sense that it could define > what localparts can be registered (XEP-0077) or provisioned as account > names, and define what domains it will host in a virtual hosting setup. > > Do we want to recommend that servers explicitly define such policies? Do > we want to provide suggestions about what such policies contain (e.g., > "don't allow registration of localparts or domainparts whose script you > don't understand")? If so, do we need to define new error conditions to > handle "registrar"-related problems, or can we use existing conditions > like or ? > > Naturally, one policy might be "anything goes" -- i.e., we could define > a small set of policies from which a service administrator could choose, > where some policies are more restrictive than others. (It might also > help if the policy were discoverable.) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --0016e658635c63b42a04a83290ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would suggest that there is an important distinction between the role of = a registrar in IDNA and the role of an XMPP server.=A0=A0 The "Hungari= an Registrar" you speak about below is a human, not a software compone= nt.=A0 The registrar can decide whether to allow a domain name registration= based on a number of criteria (e.g. trademarks, etc.) which may not be eas= ily replicated in software, and the existence of these policies does not ne= cessarily imply changes to software.=A0 For example, a DNS server can allow= RRs to be entered and served which would violate registrar policies (e.g. = a label containing Korean code points within the Hungarian CC tld).=A0

Given this, I'd be careful to separate discussions of mechanism and= policy, and also to be clear when policy can be applied and when it should= not be.=A0=A0 For example, who gets to decide whether a username can utili= ze mixed scipts?=A0 Is this only the local server creating the username, or= can any XMPP client or server interacting with the JID also have its own p= olicies.=A0 IMHO, allowing all entities to create (potentially incompatible= ) policies is probably not a good idea. It is one thing for the Hungarian R= egistrar to prohibit Koren codepoints within the Hungarian CCTLD; it is ano= ther thing for an XMPP server in Hungary to decidde not to accept Korean co= de points in JIDs, even when the user is hosted on an XMPP server in Korea.=




On Fri, Jul 15, 2011 at 1:31 PM,= Peter Saint-Andre <stpeter@stpeter.im> wrote:
In IDNA, certain aspects of the technology are enforced by domain
registrars (e.g., the Hungarian registrars probably won't allow you to<= br> register domain names containing Korean code points). In XMPP, a server
functions somewhat like a registrar, in the sense that it could define
what localparts can be registered (XEP-0077) or provisioned as account
names, and define what domains it will host in a virtual hosting setup.

Do we want to recommend that servers explicitly define such policies? Do we want to provide suggestions about what such policies contain (e.g.,
"don't allow registration of localparts or domainparts whose scrip= t you
don't understand")? If so, do we need to define new error conditio= ns to
handle "registrar"-related problems, or can we use existing condi= tions
like <not-acceptable/> or <policy-violation/>?

Naturally, one policy might be "anything goes" -- i.e., we could = define
a small set of policies from which a service administrator could choose, where some policies are more restrictive than others. (It might also
help if the policy were discoverable.)

Peter

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

_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--0016e658635c63b42a04a83290ff-- From Peter.SaintAndre@webex.com Sat Jul 16 10:51:03 2011 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 724B221F87A5 for ; Sat, 16 Jul 2011 10:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.098 X-Spam-Level: X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txkEZ6hAiYo5 for ; Sat, 16 Jul 2011 10:51:02 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by ietfa.amsl.com (Postfix) with SMTP id 897FF21F877B for ; Sat, 16 Jul 2011 10:51:02 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Jul 2011 10:51:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC43E0.ECD0B61A" Date: Sat, 16 Jul 2011 10:51:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xmpp] 6122bis: servers as "registrars" Thread-Index: AcxD2H6q/WCqjWSoTmOJ2wX7Dp2ZSQACG4Tw From: "Peter Saint Andre" To: , X-OriginalArrivalTime: 16 Jul 2011 17:51:01.0450 (UTC) FILETIME=[ECFADAA0:01CC43E0] Cc: xmpp@ietf.org Subject: Re: [xmpp] 6122bis: servers as "registrars" X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 17:51:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC43E0.ECD0B61A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludC4gSSB0aGluayBvbmx5IHNlcnZlcnMgdGhhdCBhY2NlcHQgYWNjb3VudCByZWdp c3RyYXRpb25zIHdvdWxkIGhhdmUgc3VjaCBwb2xpY2llcy4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KRnJvbTogeG1wcC1ib3VuY2VzQGlldGYub3JnIDx4bXBwLWJvdW5j ZXNAaWV0Zi5vcmc+IA0KVG86IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+ IA0KQ2M6IFhNUFAgPHhtcHBAaWV0Zi5vcmc+IA0KU2VudDogU2F0IEp1bCAxNiAwOTo1MDoxMSAy MDExDQpTdWJqZWN0OiBSZTogW3htcHBdIDYxMjJiaXM6IHNlcnZlcnMgYXMgInJlZ2lzdHJhcnMi IA0KDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZXJlIGlzIGFuIGltcG9ydGFudCBkaXN0aW5j dGlvbiBiZXR3ZWVuIHRoZSByb2xlIG9mIGEgcmVnaXN0cmFyIGluIElETkEgYW5kIHRoZSByb2xl IG9mIGFuIFhNUFAgc2VydmVyLiAgIFRoZSAiSHVuZ2FyaWFuIFJlZ2lzdHJhciIgeW91IHNwZWFr IGFib3V0IGJlbG93IGlzIGEgaHVtYW4sIG5vdCBhIHNvZnR3YXJlIGNvbXBvbmVudC4gIFRoZSBy ZWdpc3RyYXIgY2FuIGRlY2lkZSB3aGV0aGVyIHRvIGFsbG93IGEgZG9tYWluIG5hbWUgcmVnaXN0 cmF0aW9uIGJhc2VkIG9uIGEgbnVtYmVyIG9mIGNyaXRlcmlhIChlLmcuIHRyYWRlbWFya3MsIGV0 Yy4pIHdoaWNoIG1heSBub3QgYmUgZWFzaWx5IHJlcGxpY2F0ZWQgaW4gc29mdHdhcmUsIGFuZCB0 aGUgZXhpc3RlbmNlIG9mIHRoZXNlIHBvbGljaWVzIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGltcGx5 IGNoYW5nZXMgdG8gc29mdHdhcmUuICBGb3IgZXhhbXBsZSwgYSBETlMgc2VydmVyIGNhbiBhbGxv dyBSUnMgdG8gYmUgZW50ZXJlZCBhbmQgc2VydmVkIHdoaWNoIHdvdWxkIHZpb2xhdGUgcmVnaXN0 cmFyIHBvbGljaWVzIChlLmcuIGEgbGFiZWwgY29udGFpbmluZyBLb3JlYW4gY29kZSBwb2ludHMg d2l0aGluIHRoZSBIdW5nYXJpYW4gQ0MgdGxkKS4gIA0KDQpHaXZlbiB0aGlzLCBJJ2QgYmUgY2Fy ZWZ1bCB0byBzZXBhcmF0ZSBkaXNjdXNzaW9ucyBvZiBtZWNoYW5pc20gYW5kIHBvbGljeSwgYW5k IGFsc28gdG8gYmUgY2xlYXIgd2hlbiBwb2xpY3kgY2FuIGJlIGFwcGxpZWQgYW5kIHdoZW4gaXQg c2hvdWxkIG5vdCBiZS4gICBGb3IgZXhhbXBsZSwgd2hvIGdldHMgdG8gZGVjaWRlIHdoZXRoZXIg YSB1c2VybmFtZSBjYW4gdXRpbGl6ZSBtaXhlZCBzY2lwdHM/ICBJcyB0aGlzIG9ubHkgdGhlIGxv Y2FsIHNlcnZlciBjcmVhdGluZyB0aGUgdXNlcm5hbWUsIG9yIGNhbiBhbnkgWE1QUCBjbGllbnQg b3Igc2VydmVyIGludGVyYWN0aW5nIHdpdGggdGhlIEpJRCBhbHNvIGhhdmUgaXRzIG93biBwb2xp Y2llcy4gIElNSE8sIGFsbG93aW5nIGFsbCBlbnRpdGllcyB0byBjcmVhdGUgKHBvdGVudGlhbGx5 IGluY29tcGF0aWJsZSkgcG9saWNpZXMgaXMgcHJvYmFibHkgbm90IGEgZ29vZCBpZGVhLiBJdCBp cyBvbmUgdGhpbmcgZm9yIHRoZSBIdW5nYXJpYW4gUmVnaXN0cmFyIHRvIHByb2hpYml0IEtvcmVu IGNvZGVwb2ludHMgd2l0aGluIHRoZSBIdW5nYXJpYW4gQ0NUTEQ7IGl0IGlzIGFub3RoZXIgdGhp bmcgZm9yIGFuIFhNUFAgc2VydmVyIGluIEh1bmdhcnkgdG8gZGVjaWRkZSBub3QgdG8gYWNjZXB0 IEtvcmVhbiBjb2RlIHBvaW50cyBpbiBKSURzLCBldmVuIHdoZW4gdGhlIHVzZXIgaXMgaG9zdGVk IG9uIGFuIFhNUFAgc2VydmVyIGluIEtvcmVhLiANCg0KDQoNCg0KDQpPbiBGcmksIEp1bCAxNSwg MjAxMSBhdCAxOjMxIFBNLCBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPiB3 cm90ZToNCg0KDQoJSW4gSUROQSwgY2VydGFpbiBhc3BlY3RzIG9mIHRoZSB0ZWNobm9sb2d5IGFy ZSBlbmZvcmNlZCBieSBkb21haW4NCglyZWdpc3RyYXJzIChlLmcuLCB0aGUgSHVuZ2FyaWFuIHJl Z2lzdHJhcnMgcHJvYmFibHkgd29uJ3QgYWxsb3cgeW91IHRvDQoJcmVnaXN0ZXIgZG9tYWluIG5h bWVzIGNvbnRhaW5pbmcgS29yZWFuIGNvZGUgcG9pbnRzKS4gSW4gWE1QUCwgYSBzZXJ2ZXINCglm dW5jdGlvbnMgc29tZXdoYXQgbGlrZSBhIHJlZ2lzdHJhciwgaW4gdGhlIHNlbnNlIHRoYXQgaXQg Y291bGQgZGVmaW5lDQoJd2hhdCBsb2NhbHBhcnRzIGNhbiBiZSByZWdpc3RlcmVkIChYRVAtMDA3 Nykgb3IgcHJvdmlzaW9uZWQgYXMgYWNjb3VudA0KCW5hbWVzLCBhbmQgZGVmaW5lIHdoYXQgZG9t YWlucyBpdCB3aWxsIGhvc3QgaW4gYSB2aXJ0dWFsIGhvc3Rpbmcgc2V0dXAuDQoJDQoJRG8gd2Ug d2FudCB0byByZWNvbW1lbmQgdGhhdCBzZXJ2ZXJzIGV4cGxpY2l0bHkgZGVmaW5lIHN1Y2ggcG9s aWNpZXM/IERvDQoJd2Ugd2FudCB0byBwcm92aWRlIHN1Z2dlc3Rpb25zIGFib3V0IHdoYXQgc3Vj aCBwb2xpY2llcyBjb250YWluIChlLmcuLA0KCSJkb24ndCBhbGxvdyByZWdpc3RyYXRpb24gb2Yg bG9jYWxwYXJ0cyBvciBkb21haW5wYXJ0cyB3aG9zZSBzY3JpcHQgeW91DQoJZG9uJ3QgdW5kZXJz dGFuZCIpPyBJZiBzbywgZG8gd2UgbmVlZCB0byBkZWZpbmUgbmV3IGVycm9yIGNvbmRpdGlvbnMg dG8NCgloYW5kbGUgInJlZ2lzdHJhciItcmVsYXRlZCBwcm9ibGVtcywgb3IgY2FuIHdlIHVzZSBl eGlzdGluZyBjb25kaXRpb25zDQoJbGlrZSA8bm90LWFjY2VwdGFibGUvPiBvciA8cG9saWN5LXZp b2xhdGlvbi8+Pw0KCQ0KCU5hdHVyYWxseSwgb25lIHBvbGljeSBtaWdodCBiZSAiYW55dGhpbmcg Z29lcyIgLS0gaS5lLiwgd2UgY291bGQgZGVmaW5lDQoJYSBzbWFsbCBzZXQgb2YgcG9saWNpZXMg ZnJvbSB3aGljaCBhIHNlcnZpY2UgYWRtaW5pc3RyYXRvciBjb3VsZCBjaG9vc2UsDQoJd2hlcmUg c29tZSBwb2xpY2llcyBhcmUgbW9yZSByZXN0cmljdGl2ZSB0aGFuIG90aGVycy4gKEl0IG1pZ2h0 IGFsc28NCgloZWxwIGlmIHRoZSBwb2xpY3kgd2VyZSBkaXNjb3ZlcmFibGUuKQ0KCQ0KCVBldGVy DQoJDQoJLS0NCglQZXRlciBTYWludC1BbmRyZQ0KCWh0dHBzOi8vc3RwZXRlci5pbS8NCgkNCgkN CglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCXhtcHAg bWFpbGluZyBsaXN0DQoJeG1wcEBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8veG1wcA0KCQ0KDQoNCg== ------_=_NextPart_001_01CC43E0.ECD0B61A Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KR29vZCBwb2ludC4gSSB0 aGluayBvbmx5IHNlcnZlcnMgdGhhdCBhY2NlcHQgYWNjb3VudCByZWdpc3RyYXRpb25zIHdvdWxk IGhhdmUgc3VjaCBwb2xpY2llcy48L2ZvbnQ+PC9kaXY+DQo8YnI+PGRpdj48aHIgc2l6ZT0yIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBz aXplPTI+DQo8Yj5Gcm9tPC9iPjogeG1wcC1ib3VuY2VzQGlldGYub3JnICZsdDt4bXBwLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5UbzwvYj46IFBldGVyIFNhaW50LUFuZHJlICZsdDtzdHBl dGVyQHN0cGV0ZXIuaW0mZ3Q7DTxicj48Yj5DYzwvYj46IFhNUFAgJmx0O3htcHBAaWV0Zi5vcmcm Z3Q7DTxicj48Yj5TZW50PC9iPjogU2F0IEp1bCAxNiAwOTo1MDoxMSAyMDExPGJyPjxiPlN1Ympl Y3Q8L2I+OiBSZTogW3htcHBdIDYxMjJiaXM6IHNlcnZlcnMgYXMgJnF1b3Q7cmVnaXN0cmFycyZx dW90Ow08YnI+PC9mb250Pjxicj48L2Rpdj4NCkkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZXJlIGlz IGFuIGltcG9ydGFudCBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSByb2xlIG9mIGEgcmVnaXN0cmFy IGluIElETkEgYW5kIHRoZSByb2xlIG9mIGFuIFhNUFAgc2VydmVyLsKgwqAgVGhlICZxdW90O0h1 bmdhcmlhbiBSZWdpc3RyYXImcXVvdDsgeW91IHNwZWFrIGFib3V0IGJlbG93IGlzIGEgaHVtYW4s IG5vdCBhIHNvZnR3YXJlIGNvbXBvbmVudC7CoCBUaGUgcmVnaXN0cmFyIGNhbiBkZWNpZGUgd2hl dGhlciB0byBhbGxvdyBhIGRvbWFpbiBuYW1lIHJlZ2lzdHJhdGlvbiBiYXNlZCBvbiBhIG51bWJl ciBvZiBjcml0ZXJpYSAoZS5nLiB0cmFkZW1hcmtzLCBldGMuKSB3aGljaCBtYXkgbm90IGJlIGVh c2lseSByZXBsaWNhdGVkIGluIHNvZnR3YXJlLCBhbmQgdGhlIGV4aXN0ZW5jZSBvZiB0aGVzZSBw b2xpY2llcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbXBseSBjaGFuZ2VzIHRvIHNvZnR3YXJlLsKg IEZvciBleGFtcGxlLCBhIEROUyBzZXJ2ZXIgY2FuIGFsbG93IFJScyB0byBiZSBlbnRlcmVkIGFu ZCBzZXJ2ZWQgd2hpY2ggd291bGQgdmlvbGF0ZSByZWdpc3RyYXIgcG9saWNpZXMgKGUuZy4gYSBs YWJlbCBjb250YWluaW5nIEtvcmVhbiBjb2RlIHBvaW50cyB3aXRoaW4gdGhlIEh1bmdhcmlhbiBD QyB0bGQpLsKgIDxicj4NCg0KPGJyPkdpdmVuIHRoaXMsIEkmIzM5O2QgYmUgY2FyZWZ1bCB0byBz ZXBhcmF0ZSBkaXNjdXNzaW9ucyBvZiBtZWNoYW5pc20gYW5kIHBvbGljeSwgYW5kIGFsc28gdG8g YmUgY2xlYXIgd2hlbiBwb2xpY3kgY2FuIGJlIGFwcGxpZWQgYW5kIHdoZW4gaXQgc2hvdWxkIG5v dCBiZS7CoMKgIEZvciBleGFtcGxlLCB3aG8gZ2V0cyB0byBkZWNpZGUgd2hldGhlciBhIHVzZXJu YW1lIGNhbiB1dGlsaXplIG1peGVkIHNjaXB0cz/CoCBJcyB0aGlzIG9ubHkgdGhlIGxvY2FsIHNl cnZlciBjcmVhdGluZyB0aGUgdXNlcm5hbWUsIG9yIGNhbiBhbnkgWE1QUCBjbGllbnQgb3Igc2Vy dmVyIGludGVyYWN0aW5nIHdpdGggdGhlIEpJRCBhbHNvIGhhdmUgaXRzIG93biBwb2xpY2llcy7C oCBJTUhPLCBhbGxvd2luZyBhbGwgZW50aXRpZXMgdG8gY3JlYXRlIChwb3RlbnRpYWxseSBpbmNv bXBhdGlibGUpIHBvbGljaWVzIGlzIHByb2JhYmx5IG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgb25l IHRoaW5nIGZvciB0aGUgSHVuZ2FyaWFuIFJlZ2lzdHJhciB0byBwcm9oaWJpdCBLb3JlbiBjb2Rl cG9pbnRzIHdpdGhpbiB0aGUgSHVuZ2FyaWFuIENDVExEOyBpdCBpcyBhbm90aGVyIHRoaW5nIGZv ciBhbiBYTVBQIHNlcnZlciBpbiBIdW5nYXJ5IHRvIGRlY2lkZGUgbm90IHRvIGFjY2VwdCBLb3Jl YW4gY29kZSBwb2ludHMgaW4gSklEcywgZXZlbiB3aGVuIHRoZSB1c2VyIGlzIGhvc3RlZCBvbiBh biBYTVBQIHNlcnZlciBpbiBLb3JlYS4gPGJyPg0KDQo8YnI+PGJyPjxicj48YnI+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSnVsIDE1LCAyMDExIGF0IDE6MzEgUE0sIFBldGVyIFNh aW50LUFuZHJlIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnN0cGV0ZXJAc3Rw ZXRlci5pbSI+c3RwZXRlckBzdHBldGVyLmltPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+DQoNCkluIElETkEsIGNl cnRhaW4gYXNwZWN0cyBvZiB0aGUgdGVjaG5vbG9neSBhcmUgZW5mb3JjZWQgYnkgZG9tYWluPGJy Pg0KcmVnaXN0cmFycyAoZS5nLiwgdGhlIEh1bmdhcmlhbiByZWdpc3RyYXJzIHByb2JhYmx5IHdv biYjMzk7dCBhbGxvdyB5b3UgdG88YnI+DQpyZWdpc3RlciBkb21haW4gbmFtZXMgY29udGFpbmlu ZyBLb3JlYW4gY29kZSBwb2ludHMpLiBJbiBYTVBQLCBhIHNlcnZlcjxicj4NCmZ1bmN0aW9ucyBz b21ld2hhdCBsaWtlIGEgcmVnaXN0cmFyLCBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBjb3VsZCBkZWZp bmU8YnI+DQp3aGF0IGxvY2FscGFydHMgY2FuIGJlIHJlZ2lzdGVyZWQgKFhFUC0wMDc3KSBvciBw cm92aXNpb25lZCBhcyBhY2NvdW50PGJyPg0KbmFtZXMsIGFuZCBkZWZpbmUgd2hhdCBkb21haW5z IGl0IHdpbGwgaG9zdCBpbiBhIHZpcnR1YWwgaG9zdGluZyBzZXR1cC48YnI+DQo8YnI+DQpEbyB3 ZSB3YW50IHRvIHJlY29tbWVuZCB0aGF0IHNlcnZlcnMgZXhwbGljaXRseSBkZWZpbmUgc3VjaCBw b2xpY2llcz8gRG88YnI+DQp3ZSB3YW50IHRvIHByb3ZpZGUgc3VnZ2VzdGlvbnMgYWJvdXQgd2hh dCBzdWNoIHBvbGljaWVzIGNvbnRhaW4gKGUuZy4sPGJyPg0KJnF1b3Q7ZG9uJiMzOTt0IGFsbG93 IHJlZ2lzdHJhdGlvbiBvZiBsb2NhbHBhcnRzIG9yIGRvbWFpbnBhcnRzIHdob3NlIHNjcmlwdCB5 b3U8YnI+DQpkb24mIzM5O3QgdW5kZXJzdGFuZCZxdW90Oyk/IElmIHNvLCBkbyB3ZSBuZWVkIHRv IGRlZmluZSBuZXcgZXJyb3IgY29uZGl0aW9ucyB0bzxicj4NCmhhbmRsZSAmcXVvdDtyZWdpc3Ry YXImcXVvdDstcmVsYXRlZCBwcm9ibGVtcywgb3IgY2FuIHdlIHVzZSBleGlzdGluZyBjb25kaXRp b25zPGJyPg0KbGlrZSAmbHQ7bm90LWFjY2VwdGFibGUvJmd0OyBvciAmbHQ7cG9saWN5LXZpb2xh dGlvbi8mZ3Q7Pzxicj4NCjxicj4NCk5hdHVyYWxseSwgb25lIHBvbGljeSBtaWdodCBiZSAmcXVv dDthbnl0aGluZyBnb2VzJnF1b3Q7IC0tIGkuZS4sIHdlIGNvdWxkIGRlZmluZTxicj4NCmEgc21h bGwgc2V0IG9mIHBvbGljaWVzIGZyb20gd2hpY2ggYSBzZXJ2aWNlIGFkbWluaXN0cmF0b3IgY291 bGQgY2hvb3NlLDxicj4NCndoZXJlIHNvbWUgcG9saWNpZXMgYXJlIG1vcmUgcmVzdHJpY3RpdmUg dGhhbiBvdGhlcnMuIChJdCBtaWdodCBhbHNvPGJyPg0KaGVscCBpZiB0aGUgcG9saWN5IHdlcmUg ZGlzY292ZXJhYmxlLik8YnI+DQo8YnI+DQpQZXRlcjxicj4NCjxicj4NCi0tPGJyPg0KUGV0ZXIg U2FpbnQtQW5kcmU8YnI+DQo8YSBocmVmPSJodHRwczovL3N0cGV0ZXIuaW0vIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9zdHBldGVyLmltLzwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnhtcHAgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnhtcHBAaWV0Zi5vcmciPnhtcHBAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby94bXBw IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby94 bXBwPC9hPjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+DQo= ------_=_NextPart_001_01CC43E0.ECD0B61A-- From waqas20@gmail.com Sat Jul 16 12:28:50 2011 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 8B55F21F86EE for ; Sat, 16 Jul 2011 12:28:50 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zN1Ez3SOIKC for ; Sat, 16 Jul 2011 12:28:49 -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 74D5921F86B9 for ; Sat, 16 Jul 2011 12:28:49 -0700 (PDT) Received: by yxp4 with SMTP id 4so1092845yxp.31 for ; Sat, 16 Jul 2011 12:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9HDSLpq7KUAz2fTkUzqgK48PSLvLcG1nfRSroIPUaVI=; b=GuTiMqv98rg4m9701mTSOQL04GTuICop7S/Gg03O/QHqVolITkg3c7DXdIZBvrp4U8 aEyFzWT2H1Na6sTC3ASttn3R9eMZN8T88/ezmJNFSDluSrSwfkaxbBxQtmogam9r0UvG 1yzWghPh8iTTxz2czgSxS07SHvM5F88cuWceg= Received: by 10.151.105.17 with SMTP id h17mr4043742ybm.244.1310844527050; Sat, 16 Jul 2011 12:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Sat, 16 Jul 2011 12:28:27 -0700 (PDT) In-Reply-To: <4E209D5D.1090105@stpeter.im> References: <4E209D5D.1090105@stpeter.im> From: Waqas Hussain Date: Sun, 17 Jul 2011 00:28:27 +0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Subject: Re: [xmpp] 6122bis: error handling X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 19:28:50 -0000 On Sat, Jul 16, 2011 at 1:04 AM, Peter Saint-Andre wrote: > As far as I can see, most i18n-related error conditions fall into the > following categories: > > 1. Initiating entity includes a non-conforming JID in the 'from' or 'to' > attribute of a stream header. Handle via stream > error? +1, that seems appropriate > 2. [I assume that TLS-related errors will be handled at that layer.] +1 > 3. Client includes a non-conforming authcid or authzid in a SASL > authentication request. Handle via SASL error, or do > we need a new condition? I don't think we need a new condition. > 4. Client attempts to bind a non-conforming resourcepart. Handle via > stanza error, or should the server generate a > conforming resourcepart? (The latter is more friendly.) Both. The choice should be left to implementations/deployments. Prosody currently does the latter I believe. > 5. Server or client includes a non-conforming 'to' or 'from' address on > a stanza. Handle via stanza error? +1 > 6. Client includes a non-conforming JID in a JID slot that is not used > for routing purposes (e.g., 'jid' attribute of roster set). Handle via > stanza error? Is checking of such JID slots a MUST or a > SHOULD or a MAY on the part of the server? Do we leave this up to the > relevant XMPP extension? I'm for if the JID is expected to be used for routing in the future. A JID being stored in the roster may not be used for routing when it's being added, but is expected to be used for routing in the future. Rather than validating every time there's a roster broadcast, I prefer not letting invalid data in the system at all (though an invalid JID would have a hard time getting a subscription, but that's besides the point). There is the question of who enforces this. Only the entity actually processing the data should return an error, and any intermediate entities which are simply routing it should not. > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ From waqas20@gmail.com Sat Jul 16 12:54:39 2011 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 5B14221F87C6 for ; Sat, 16 Jul 2011 12:54:39 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXSvYhL9BjbU for ; Sat, 16 Jul 2011 12:54:38 -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 9C4E621F87BD for ; Sat, 16 Jul 2011 12:54:34 -0700 (PDT) Received: by ywp31 with SMTP id 31so1033608ywp.31 for ; Sat, 16 Jul 2011 12:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hb+kW/sFJWo7aX7ruPlpgU0HSxmu9+E5K9h3vwJHaz8=; b=hPx66CUll5X5cRWfyF8zj2J996PjvpEW800549b/+DQOxWqDSLbjxo8JOFr8oiepym /3BeuMZZ09v9Rvk/NNZQs1vvwQOSFYeWdptbHWjdBsEbCooooV1J5CSpoEpc9cNlI4J9 Yxl6clZ8n/H2XyMU009NbH/0Ghbf/aKix9ydQ= Received: by 10.151.79.14 with SMTP id g14mr1861265ybl.187.1310846074088; Sat, 16 Jul 2011 12:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Sat, 16 Jul 2011 12:54:14 -0700 (PDT) In-Reply-To: <4E20989B.1030709@stpeter.im> References: <4E20989B.1030709@stpeter.im> From: Waqas Hussain Date: Sun, 17 Jul 2011 00:54:14 +0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 19:54:39 -0000 On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre wrote: > The good thing about the post-stringprep world is that we have agility > with regard to Unicode versions (a.k.a. "Unicode agility"). No more > being stuck at Unicode 3.2! > > The bad thing is that we have Unicode agility. What if my client (or > your server) has Unicode 5.0 but my server has Unicode 6.0? The parties > might differ in their interpretation of certain code points, causing > problems with authentication, stanza routing, etc. > > We might be able to mitigate these problems if we had a way to discover > which version of Unicode the other side supports. That's the discussion I'm interested in. How can we mitigate Unicode version incompatibility? And also, stringprep and post-stringprep incompatability? Has there been anything written on this that I can read? I don't really see there being a good solution. The best we might reasonably be able to do is handle errors and just accept that either two incompatible entities wont be able to communicate at all, or one entity might see the other entity as multiple JIDs. A recommendation that servers prep JIDs on all outgoing stanzas might fix the latter. -- Waqas Hussain From jehan.marmottard@gmail.com Sun Jul 17 02:56:41 2011 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 97D0921F85F5 for ; Sun, 17 Jul 2011 02:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rEhqbgkoMuf for ; Sun, 17 Jul 2011 02:56:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3F021F85EC for ; Sun, 17 Jul 2011 02:56:39 -0700 (PDT) Received: by wyj26 with SMTP id 26so745912wyj.31 for ; Sun, 17 Jul 2011 02:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mDj1CFhE1kRlhpKkDqW5lFE59klDvLZaxD03eqarANo=; b=NUV+qHFyRAc8UMBmNzZ9UJ4dQ5qf3XSBdNLO+pwIbQMORl/2AooEcfuCjl5Ed3gO1C SE47w1cL4bcgSg7dWTDbvGtVICKLy/lyNn8eVUsICFRD0gmOInIqhPrNngKUMlHEf1al M4VOoLNdem2yDxUzV6OpejtboRfoenXUBL2Xo= MIME-Version: 1.0 Received: by 10.216.229.222 with SMTP id h72mr4549300weq.34.1310896597335; Sun, 17 Jul 2011 02:56:37 -0700 (PDT) Received: by 10.216.85.148 with HTTP; Sun, 17 Jul 2011 02:56:37 -0700 (PDT) In-Reply-To: References: <4E20A38C.6040507@stpeter.im> Date: Sun, 17 Jul 2011 18:56:37 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: XMPP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [xmpp] Fwd: 6122bis: servers as "registrars" 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, 17 Jul 2011 09:56:41 -0000 Oups, error in the recipient! The below email is a response to the mailing list, not Peter only, of course! :-) ---------- Forwarded message ---------- From: Jehan Pag=C3=A8s Date: 2011/7/17 Subject: Re: [xmpp] 6122bis: servers as "registrars" To: Peter Saint-Andre Hi, On Sat, Jul 16, 2011 at 5:31 AM, Peter Saint-Andre wro= te: > In IDNA, certain aspects of the technology are enforced by domain > registrars (e.g., the Hungarian registrars probably won't allow you to > register domain names containing Korean code points). In XMPP, a server > functions somewhat like a registrar, in the sense that it could define > what localparts can be registered (XEP-0077) or provisioned as account > names, and define what domains it will host in a virtual hosting setup. Indeed. > Do we want to recommend that servers explicitly define such policies? Do > we want to provide suggestions about what such policies contain (e.g., > "don't allow registration of localparts or domainparts whose script you > don't understand")? If so, do we need to define new error conditions to > handle "registrar"-related problems, or can we use existing conditions > like or ? I think that we obviously must not *enforce* any policy on the XSF level, because every server deployment could have very different rules compared to another, depending on their use case. Defining policy is only valid when there are some risks, in particular security risks (impersonation of other users, or simply errors when contacting one user whose address really looks like another user, etc.). If you have a private server for your personal domain name with just a few user (you, a few friends or family) for instance, you don't need any policy and there is no reason for you to forbid Korean characters (even though you might be French), or even mixing Korean, Japanese, French, for fun, and so on. Even a company server is some kind of private server as a new employee may have an exotic JID as long as the human administrator does not find any security problem or risk of mistakes. On this point, I guess it rejoins what was saying Bernard Aboba. But we should definitely, in my opinion, propose *suggestions* for *public* services, based on the Internet experience (experience that the domain name registrars indeed collected for years) of various scams or possible errors. Also I agree (it seems even obvious to me) that no implementation must refuse to contact any other JID because it uses strange characters or mixes. BUT there are still 2 other kinds of recommendations we could do: 1/ remind deployment servers, when writing their policy, that there is another risk to take into account (=3D other than impersonation scam and confusion between various users): do the user needs to be joinable easily all over the world? If you are a very locale Hungarian server, you don't mind Hungarian characters, but if users wish to be easily contactable from all over the world, do not forget that you may not be if your correspondent cannot easily write your name. Of course if he can copy-paste, this is nice, but if you gave him a business card and your JID has hungarian characters, a French contact may not know how to write it. Do we have a "alias" XEP? That could solve a lot of similar problem, for instance if I had my main JID jehan.pag=C3=A8s@example.net, I could create an alias jehan.pages@example.net =C2=A0which would redirect to jehan.pag=C3=A8s@ (actually a "clever" implementation could even automatically create it for me, or at least "reserve" it. This is one of many security recommendation we should do). 2/ Neither clients nor servers implementations must block other server's JID with other policy (as Bernard Aboba reminds), which means that my French server, even though it may refuse me to create a JID with Japanese characters, must obviously definitely not refuse me to contact my friend =E9=9B=85=E5=AD=90=EF=BC=A0=E4=BE=8B=E3=81=88.=E3=83=86= =E3=82=B9=E3=83=88. But a secure client could provide some kind of warning system, the same way that browsers sometimes warn on dangerous looking domain name. For instance if you are contacted by an unknown JID (not in your roster) using mixed (usually incompatible) characters, or strange characters (for instance =E1=8E=AB=E1=8E=AC=E1=8E=BB=E1=8E=AA=E1=8F=81@exam= ple.fr, so cherookee characters, especially while using a .fr tld!), the user should definitely be warned by a big red banner that this can be a risk of impersonation. The client could also provide a way for the user to check a "this specific JID is secure, don't warn me again" box, or even a =C2=A0general checkbox in the configuration if the user does not ever want to be warned. But in any case, the default should be to warn of every "strange" JID or combination. For this client side also, I think recommendations of implementation should definitely be written. As a conclusion, yes I definitely think we have a lot of recommendations to do in the matter, because we could gather the wide knowledge in this centralized place (and update it regularly as new forms of risks are discovered). I summarize the recommendations: (1) Advice for servers, especially for those using a public registration system without any kind of human verification, in order to help them define safe policies (depending on their expected users in particular); (2) Advice for servers to enforce additional "dynamic" restrictions based on existing users (for instance your policy might authorize both 'e' and '=C3=A8' characters on a French server, but if a user registered 'pag=C3=A8s@', future registrations of 'pages@' should be restricted. (3) Recommendations for clients to warn users of risks, where we would define as exhaustively as possible, the many known kind of risks: characters mixes; locale name's characters not corresponding to the domain name's characters and the TLD location; common known "looking-alike" character maps between various syllabaries, like cheerokee or cyrillic to assume occidental alphabets, and so on. Also remind that apart from this, a client or server must accept any contact but may provide appropriate warning and maybe an alias XEP (if not already existing) could be in order. Note that I remember that the XSF roadmap has an item about preparing us to work on these kind of security considerations: spam, scam, phishing, etc. This kind of discussion could definitely enter as an item in such a working group. Are we creating it? Jehan > Naturally, one policy might be "anything goes" -- i.e., we could define > a small set of policies from which a service administrator could choose, > where some policies are more restrictive than others. (It might also > help if the policy were discoverable.) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > From jehan.marmottard@gmail.com Sun Jul 17 03:26:49 2011 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 089A921F8599 for ; Sun, 17 Jul 2011 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C6SO2Esh6GH for ; Sun, 17 Jul 2011 03:26:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A02A21F8584 for ; Sun, 17 Jul 2011 03:26:47 -0700 (PDT) Received: by wyj26 with SMTP id 26so754670wyj.31 for ; Sun, 17 Jul 2011 03:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w6VjWAwoJwdwYlyAGDDL2zEvLK8gJy6qHkkW++y6vSQ=; b=IP3pbW/JOkHMRSyHXkOWWgzO+eUQO+McZtmnDwGZY5OMZs972SAY+UuOlTDYoSSnF5 wSGFTQvm35PAqyyvluTL9piEDcf5jUx6cSIYm/VrdZSo0SnVU6HdCYmf/rzyVjqs9Brl PIdkeMkVFQZV2HQKESL5u19eLkhocnOVAGaHg= MIME-Version: 1.0 Received: by 10.216.142.6 with SMTP id h6mr1997361wej.19.1310898405885; Sun, 17 Jul 2011 03:26:45 -0700 (PDT) Received: by 10.216.85.148 with HTTP; Sun, 17 Jul 2011 03:26:45 -0700 (PDT) In-Reply-To: <4E20989B.1030709@stpeter.im> References: <4E20989B.1030709@stpeter.im> Date: Sun, 17 Jul 2011 19:26:45 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 17 Jul 2011 10:26:49 -0000 Hi, On Sat, Jul 16, 2011 at 4:44 AM, Peter Saint-Andre wrote: > The good thing about the post-stringprep world is that we have agility > with regard to Unicode versions (a.k.a. "Unicode agility"). No more > being stuck at Unicode 3.2! > > The bad thing is that we have Unicode agility. What if my client (or > your server) has Unicode 5.0 but my server has Unicode 6.0? The parties > might differ in their interpretation of certain code points, causing > problems with authentication, stanza routing, etc. > > We might be able to mitigate these problems if we had a way to discover > which version of Unicode the other side supports. Using XEP-0030 or > stream features, we'd want a URI for each Unicode version, such as: > > http://www.unicode.org/versions/Unicode6.0.0/ (the web page for 6.0) > > or: > > urn:unicode:versions:6.0.0 > > Two questions: > > 1. Do we think that a service discovery feature would be useful here? As said ny Matt, the service discovery might be too late. It would be ok if the only problem was in exchanged stanza. But if the incompatibility occurs in the JID, then having a service discovery is no use. So I guess that should indeed be a stream feature. We could consider that a client would "negotiate" its known Unicode version with the one of one's server. Note also that probably the best way would be that servers would be able to "re-encode" on the fly contents from one Unicode version to another, if needed. We cannot expect any user's OS to embed several versions of Unicode and might indeed end-up in broken link where 2 entities have errors in their communication, or worse cannot communicate with each other at all (if the inconsistency occurs in the JID in particular). That's definitely bad. On the other side, it is easier to push server deployments into being able to rencode from one version of unicode to another (are there already libraries doing conversion from UTF-8 to UTF-8, but with different Unicode version)? That said, I think a good flow could be that: (1) a client (let's call him a@example.net) would see the "unicode version" stream feature announced by example.net before authentication (and after TLS); it negotiate this feature by indicating its own unicode version (this feature negotiation part basically has no reason to fail). That way the server knows the unicode version that this client will use to authenticate, send its stanzas, and so on. From there, this user wants to contact b@example.com. (2) example.net contacts example.com. In s2s, the unicode version feature takes another form: they agree on the unicode version they will always use over the current s2s stream (whereas in c2s, the client chooses, because we consider it may not be able to convert from one version to another as easily). (3) The stanza contents and the recipient jid (b@example.com) sent by a@example.net is converted (if necessary) to the s2s-chosen unicode version, then example.com receives the stanza. (4) As example.com normally knows the unicode version used by b@example.com (when this one made the same step (1) as a@example.net before authenticating), it converts as well (if necessarily) stanza contents and JID before finally sending to the finale recipient. This way, most of the complexity is pushed on the servers (they have to convert from one unicode version to another, only when necessary), while the clients have nothing to do other than advertizing (before authentication) the unicode version they will use during all the file of the c2s stream. This is pretty good in the XMPP design and I think it deals most of the issue. What do you think of this flow? I could write this XEP (that would be my first own XEP!). > 2. If so, do we think the URLs from http://www.unicode.org/ are stable > enough, or would people like to have a URN? (I've asked someone from the > Unicode Consortium about a URN namespace for Unicode, but if we don't > think we'll need it then I won't pursue it further.) I think that we are not the one to ask the question about the URL being stable. We should ask the Unicode consortium if they have any politics on URL stability which allows us to consider them stable. If they are not, then yes URN may be better solution. Jehan From dave@cridland.net Mon Jul 18 02:44:03 2011 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 9DCF421F8B11 for ; Mon, 18 Jul 2011 02:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNM1SMGPUJUm for ; Mon, 18 Jul 2011 02:43:57 -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 C209521F8B45 for ; Mon, 18 Jul 2011 02:43:56 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BFF0B1168087; Mon, 18 Jul 2011 10:43:55 +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 kdiNg-XhHNEQ; Mon, 18 Jul 2011 10:43:45 +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 61F781168067; Mon, 18 Jul 2011 10:43:45 +0100 (BST) References: <4E2144C5.40106@mail.symlynx.com> In-Reply-To: <4E2144C5.40106@mail.symlynx.com> MIME-Version: 1.0 Message-Id: <9031.1310982225.395182@puncture> Date: Mon, 18 Jul 2011 10:43:45 +0100 From: Dave Cridland To: Philipp Hancke , "Richard L\. Barnes" , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] DNA/S2S Part 3: Connection management 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, 18 Jul 2011 09:44:03 -0000 On Sat Jul 16 08:59:01 2011, Philipp Hancke wrote: > Richard L. Barnes wrote: >> On the other hand, if you look closely at the specification for >> XMPP bidirectional server-to-server connection (XEP-0288), you can >> see that there's some overlap. While the main purpose of XEP-0288 >> is to enable a connection for "a.com->b.com" to also carry stanzas >> for "b.com->a.com", in principle, the usage of dialback in >> XEP-0288 could also be used to request permission to send stanzas >> for completely unrelated domain pairs -- a general connection >> muxing function. > > I think the "general connection muxing function" already exists, it > was called "piggybacking" in RFC 3920 and is described in the > "Multiplexing" section of XEP-0220 (version 0.5 at least). > > bidi (0288) has an interesting impact on the rules for multiplexing > target domains as defined in 220 - it looks as if it simplifies > things. There are some notes about that in my working copy already, > I'll poke my co-author again for review + approval. Right - XEP-0288 intentionally simplifies the XEP-0220 muxing, and in XMPP, muxing *itself* is a solved problem - the issue is purely limited to authentication. 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 dave@cridland.net Mon Jul 18 03:32:50 2011 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 9124821F8BC8 for ; Mon, 18 Jul 2011 03:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu5VNSRCNEfb for ; Mon, 18 Jul 2011 03:32:42 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62521F8B59 for ; Mon, 18 Jul 2011 03:32:42 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C23021168087; Mon, 18 Jul 2011 11:32:19 +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 6B869mtcQFea; Mon, 18 Jul 2011 11:32:12 +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 7534E1168067; Mon, 18 Jul 2011 11:32:12 +0100 (BST) References: <9841FBF8-11D1-4A81-953E-920EEDA00208@bbn.com> In-Reply-To: <9841FBF8-11D1-4A81-953E-920EEDA00208@bbn.com> MIME-Version: 1.0 Message-Id: <9031.1310985132.470776@puncture> Date: Mon, 18 Jul 2011 11:32:12 +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] DNA/S2S Part 2: Authentication 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, 18 Jul 2011 10:32:50 -0000 On Fri Jul 15 22:46:16 2011, Richard L. Barnes wrote: > QUESTION-1: Does the group find DNSSEC-signed SRV records or > XMPP-only certificates to be the preferable solution to the problem > of providing authenticating that a given server is authorized to > use a domain? Should this process be integrated with the dialback > specification? There's only one question, and it has multiple questions. Positively theological. So, my answer are: It's not clear to me that we need an actual decision, here. I think one of the original suggestions, albeit using attribute certificates in lieu of public key certificates, was that you'd proceed using DNSSEC if you could, and drop back to using ACs if you couldn't. I don't think this is much different. It'd be possible to have the same number of RTTs whether or not using PKIX, I think, but what unnerves me somewhat is that DNSSEC *should* allow us to connect directly without any PKIX overhead, and I'm not clear that's possible without having an additional RTT. I wouldn't want to abandon DNSSEC entirely - I think it's a sensible direction, and although "CA's are free these days", there is a certain degree of getting what one pays for, and it seems to me that DNSSEC should dilute in this manner to a lesser degree. In general terms, though, whatever system we use will be made substantially easier if integrated into XEP-0220, which is by far the most common authentication form in deployment. 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 rbarnes@bbn.com Mon Jul 18 07:10:23 2011 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 5394521F8639 for ; Mon, 18 Jul 2011 07:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFvhBBD2l90h for ; Mon, 18 Jul 2011 07:10:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0F21F85BB for ; Mon, 18 Jul 2011 07:10:17 -0700 (PDT) Received: from [128.89.253.11] (port=56992 helo=[192.168.1.13]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QioWH-000CPn-JN; Mon, 18 Jul 2011 10:10:02 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <9031.1310982225.395182@puncture> Date: Mon, 18 Jul 2011 10:09:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <018DE6C4-7A50-4863-81D3-506A805986E6@bbn.com> References: <4E2144C5.40106@mail.symlynx.com> <9031.1310982225.395182@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1082) Cc: XMPP Working Group Subject: Re: [xmpp] DNA/S2S Part 3: Connection management 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, 18 Jul 2011 14:10:23 -0000 Dave, Philipp, Thanks for this feedback. I had been trying to work through all the XSF = prior art, and apparently didn't dig back far enough :) Given the existing mechanisms for muxing, would it make sense to pare = the DNA document back to just the following? 1. For the PKIX case: Recommend using XmppAddr, possibly amending this = paragraph of RFC 6120: " o Support for the XmppAddr identifier type (specified under=20 Section 13.7.1.4) is encouraged in XMPP client and server software implementations for the sake of backward-compatibility, but is no longer encouraged in certificates issued by certification authorities or requested by XMPP service providers. " 2. Define an update to XEP-0220 that defines how DNSSEC interacts with = the transaction. =20 --Richard On Jul 18, 2011, at 5:43 AM, Dave Cridland wrote: > On Sat Jul 16 08:59:01 2011, Philipp Hancke wrote: >> Richard L. Barnes wrote: >>> On the other hand, if you look closely at the specification for XMPP = bidirectional server-to-server connection (XEP-0288), you can see that = there's some overlap. While the main purpose of XEP-0288 is to enable a = connection for "a.com->b.com" to also carry stanzas for "b.com->a.com", = in principle, the usage of dialback in XEP-0288 could also be used to = request permission to send stanzas for completely unrelated domain pairs = -- a general connection muxing function. >> I think the "general connection muxing function" already exists, it = was called "piggybacking" in RFC 3920 and is described in the = "Multiplexing" section of XEP-0220 (version 0.5 at least). >> bidi (0288) has an interesting impact on the rules for multiplexing = target domains as defined in 220 - it looks as if it simplifies things. = There are some notes about that in my working copy already, I'll poke my = co-author again for review + approval. >=20 > Right - XEP-0288 intentionally simplifies the XEP-0220 muxing, and in = XMPP, muxing *itself* is a solved problem - the issue is purely limited = to authentication. >=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 From mamille2@cisco.com Mon Jul 18 07:19:06 2011 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 16EFD21F8888 for ; Mon, 18 Jul 2011 07:19:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIvOSwgvJLfU for ; Mon, 18 Jul 2011 07:19:05 -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 0F61B21F8BB1 for ; Mon, 18 Jul 2011 07:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6116; q=dns/txt; s=iport; t=1310998745; x=1312208345; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=0O3zM0FTrT5CvRN9lUpcti9ToAvdkGyUcN6xLaUMLYY=; b=U/sPU69BlFN34dFGXXgrN0jaG/hmx+6v91EwvJju7eKBFE6t1egLGSUr 2cNVUhaxldPXeBRmk2DYnoFVL/TNaub81nynOoXe2nOgFoKHpppGfG90s QFSORT5grUrOYMD1X2JcurAjslPWRoGH3LfIOrR2FpSyw4r7EAdbCYjtl 8=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKtAJE6rRDoI/2dsb2JhbABUp3R3iHykGZ16hV1fBIdUixKQdA X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="p7s'?scan'208";a="3958304" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2011 14:19:04 +0000 Received: from dhcp-64-101-72-203.cisco.com (dhcp-64-101-72-203.cisco.com [64.101.72.203]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6IEJ36k012460; Mon, 18 Jul 2011 14:19:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2--168404938; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <4E209D5D.1090105@stpeter.im> Date: Mon, 18 Jul 2011 08:19:20 -0600 Message-Id: <48743807-28DB-4396-A7EF-32CF34C12D54@cisco.com> References: <4E209D5D.1090105@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: XMPP Subject: Re: [xmpp] 6122bis: error handling 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, 18 Jul 2011 14:19:06 -0000 --Apple-Mail-2--168404938 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 15, 2011, at 14:04, Peter Saint-Andre wrote: > As far as I can see, most i18n-related error conditions fall into the > following categories: >=20 > 1. Initiating entity includes a non-conforming JID in the 'from' or = 'to' > attribute of a stream header. Handle via stream > error? Seems reasonable. >=20 > 2. [I assume that TLS-related errors will be handled at that layer.] Indubitably (-: >=20 > 3. Client includes a non-conforming authcid or authzid in a SASL > authentication request. Handle via SASL error, or do > we need a new condition? >=20 I'd rather use than something specific. > 4. Client attempts to bind a non-conforming resourcepart. Handle via > stanza error, or should the server generate a > conforming resourcepart? (The latter is more friendly.) For the most part, I think we can leave it up to implementations. I can = see a server, even if it disregards the requested resource, would want = to error the bind request because of "bad characters", with the = (possibly erroneous) reasoning that if the client sent bad data once, = it'll do it again. >=20 > 5. Server or client includes a non-conforming 'to' or 'from' address = on > a stanza. Handle via stanza error? >=20 Seems reasonable. > 6. Client includes a non-conforming JID in a JID slot that is not used > for routing purposes (e.g., 'jid' attribute of roster set). Handle via > stanza error? Is checking of such JID slots a MUST or = a > SHOULD or a MAY on the part of the server? Do we leave this up to the > relevant XMPP extension? There's two things here to consider: what implementations ought to do, = and how implementations ought to report the problem. For the first, I think it's mostly up to the individual specifications = the method of enforcement, although the majority of the time the server = MUST verify (or Very Bad Things=AE happen at inopportune times). I lean = toward leaving it to the relevant stewards to help do the Right Thing=99 = here. For the second...well, it depends on if we want to only = pertain to addressing, or for anywhere a JID is used. RFC 6120 =A7 = 8.3.3.8 only mentions resource binding and addressing as reasons to = return this error. I know some implementations will do different things = for different error conditions, so there might be some impact to = extending this error condition's reach. Personally, I'm fine with meaning "anywhere an XMPP = address is expected". - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-2--168404938 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcxODE0MTky MFowIwYJKoZIhvcNAQkEMRYEFH6zCsrqlC/w+lWj87BmOTYCXmSzMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCEya8/9PJb7m2T/P4cTxnN80rDW822jtpIGFb2ygYBAG48JF9O6p5yuc3+ Lslo5t8RG7RkrRxqLdb1W+QTnDN6PqfQfV1LooYTyBp0iD2a7AdoHubPf1QG9GTmra8vN8JpY47D ZgmpVPOLkUEDisa7fxM+3ctTm8CUDio6XXn7Hj93/m3ccCVgQJm4i0uh7+Fll8vxSd1SrDJVCgy9 wGAtFtMyec6I0GxO49VlQX0gPE+d1Wj30LHJ6jZbSKKf6o9U7fWOaOJ9hMVLdaWq2Ow84Vqk5CoR z2VlxjdHw+rAq+biFSr2zL6aeEObTg00wKmGTQ91t77R8A70VMznnDfBAAAAAAAA --Apple-Mail-2--168404938-- From dave@cridland.net Mon Jul 18 09:18:03 2011 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 8B85721F8A4E for ; Mon, 18 Jul 2011 09:18:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoR56DrQZ-PB for ; Mon, 18 Jul 2011 09:17:58 -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 0AFBA21F8AD6 for ; Mon, 18 Jul 2011 09:17:58 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C240C1168087; Mon, 18 Jul 2011 17:17:54 +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 TAtY3Wv1Q4Si; Mon, 18 Jul 2011 17:17:46 +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 6EEBF1168067; Mon, 18 Jul 2011 17:17:46 +0100 (BST) References: <4E2144C5.40106@mail.symlynx.com> <9031.1310982225.395182@puncture> <018DE6C4-7A50-4863-81D3-506A805986E6@bbn.com> In-Reply-To: <018DE6C4-7A50-4863-81D3-506A805986E6@bbn.com> MIME-Version: 1.0 Message-Id: <9031.1311005866.431490@puncture> Date: Mon, 18 Jul 2011 17:17:46 +0100 From: Dave Cridland To: "Richard L\. Barnes" , Philipp Hancke , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] DNA/S2S Part 3: Connection management 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, 18 Jul 2011 16:18:03 -0000 On Mon Jul 18 15:09:52 2011, Richard L. Barnes wrote: > Given the existing mechanisms for muxing, would it make sense to > pare the DNA document back to just the following? > > 1. For the PKIX case: Recommend using XmppAddr, possibly amending > this paragraph of RFC 6120: > " > o Support for the XmppAddr identifier type (specified under > Section 13.7.1.4) is encouraged in XMPP client and server > software > implementations for the sake of backward-compatibility, but is no > longer encouraged in certificates issued by certification > authorities or requested by XMPP service providers. > " > > There's also sRVName SANs, beginning _xmpp, which have the same properties (roughly), at least for S2S sessions. But the real problem is that you don't want one certificate with (in GTalk's case) several thousand SANs in, so what we need is multiple certificates. I can conceive of solutions at the TLS layer, but nothing that's likely to be deployable within the next year or more. So in the case whereby a server cannot use DNSSEC to verify a domain, and the SAN is not present in the TLS certificate of the peer, then it needs to get some nonces of itself and the peer, and exchange signatures. I'd like to get this as part of dialback - I'd really like to essentially deprecate SASL EXTERNAL, because having multiple ways to achieve the same end-goal is irritating - so I suppose we're looking at an extended dialback along the lines of: <.../> The syntax for which is triggered off a stream feature. > 2. Define an update to XEP-0220 that defines how DNSSEC interacts > with the transaction. My impression is we essentially know what to do here, and being a "dialback without dialback" case, there's no syntactic changes needed. 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 Mon Jul 18 09:21:14 2011 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 B022C21F842E for ; Mon, 18 Jul 2011 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_SKANOVA=0.66] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErkoiTrEzORI for ; Mon, 18 Jul 2011 09:21:13 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA121F8AD6 for ; Mon, 18 Jul 2011 09:21:06 -0700 (PDT) Received: from [192.168.0.65] (h116n6c1o1124.bredband.skanova.com [81.228.157.116]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6IGI2DN031015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2011 18:18:06 +0200 Message-ID: <4E245D58.8020704@mail.symlynx.com> Date: Mon, 18 Jul 2011 18:20:40 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4E2144C5.40106@mail.symlynx.com> <9031.1310982225.395182@puncture> <018DE6C4-7A50-4863-81D3-506A805986E6@bbn.com> In-Reply-To: <018DE6C4-7A50-4863-81D3-506A805986E6@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] DNA/S2S Part 3: Connection management 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, 18 Jul 2011 16:21:15 -0000 Richard L. Barnes wrote: > Dave, Philipp, > > Thanks for this feedback. I had been trying to work through all the XSF prior art, and apparently didn't dig back far enough :) heh, the most important stuff is really well hidden in a chatroom log: http://logs.jabber.org/jdev@conference.jabber.org/2009-04-14.html#15:00:34 > Given the existing mechanisms for muxing, would it make sense to pare the DNA document back to just the following? > > 1. For the PKIX case: Recommend using XmppAddr, possibly amending this paragraph of RFC 6120: > " > o Support for the XmppAddr identifier type (specified under > Section 13.7.1.4) is encouraged in XMPP client and server software > implementations for the sake of backward-compatibility, but is no > longer encouraged in certificates issued by certification > authorities or requested by XMPP service providers. > " > > 2. Define an update to XEP-0220 that defines how DNSSEC interacts with the transaction. Let's see if I understood DNA... Upon receiving a the receiving server does a SRV lookup for sender.tld (or _xmpp-server._tcp.sender.tld?). This lookup returns xmpp1.originating.tld. Now, since the originating server uses a trusted certificate for xmpp1.originating.tld, the receiving server skips the dial-back and immediately answers with If that is correct, I think it is much easier to describe DNA as another dialback-without-dialback technique as described by Dave either in the chat log above or at http://blog.dave.cridland.net/?p=116 From stpeter@stpeter.im Mon Jul 18 14:59:23 2011 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 2CCD121F86E5 for ; Mon, 18 Jul 2011 14:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdEKQSbDjVly for ; Mon, 18 Jul 2011 14:59:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 512A221F86DE for ; Mon, 18 Jul 2011 14:59:19 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D72140E24; Mon, 18 Jul 2011 15:59:56 -0600 (MDT) Message-ID: <4E24ACB4.8000104@stpeter.im> Date: Mon, 18 Jul 2011 15:59:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= References: <4E20A38C.6040507@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: XMPP Subject: Re: [xmpp] Fwd: 6122bis: servers as "registrars" 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, 18 Jul 2011 21:59:23 -0000 On 7/17/11 3:56 AM, Jehan Pagès wrote: > Oups, error in the recipient! The below email is a response to the > mailing list, not Peter only, of course! :-) > > > ---------- Forwarded message ---------- > From: Jehan Pagès > Date: 2011/7/17 > Subject: Re: [xmpp] 6122bis: servers as "registrars" > To: Peter Saint-Andre > > > Hi, > > On Sat, Jul 16, 2011 at 5:31 AM, Peter Saint-Andre wrote: >> In IDNA, certain aspects of the technology are enforced by domain >> registrars (e.g., the Hungarian registrars probably won't allow you to >> register domain names containing Korean code points). In XMPP, a server >> functions somewhat like a registrar, in the sense that it could define >> what localparts can be registered (XEP-0077) or provisioned as account >> names, and define what domains it will host in a virtual hosting setup. > > Indeed. > >> Do we want to recommend that servers explicitly define such policies? Do >> we want to provide suggestions about what such policies contain (e.g., >> "don't allow registration of localparts or domainparts whose script you >> don't understand")? If so, do we need to define new error conditions to >> handle "registrar"-related problems, or can we use existing conditions >> like or? > > I think that we obviously must not *enforce* any policy on the XSF > level, because every server deployment could have very different rules > compared to another, depending on their use case. Defining policy is > only valid when there are some risks, in particular security risks > (impersonation of other users, or simply errors when contacting one > user whose address really looks like another user, etc.). If you have > a private server for your personal domain name with just a few user > (you, a few friends or family) for instance, you don't need any policy > and there is no reason for you to forbid Korean characters (even > though you might be French), or even mixing Korean, Japanese, French, > for fun, and so on. Even a company server is some kind of private > server as a new employee may have an exotic JID as long as the human > administrator does not find any security problem or risk of mistakes. > > On this point, I guess it rejoins what was saying Bernard Aboba. > > But we should definitely, in my opinion, propose *suggestions* for > *public* services, based on the Internet experience (experience that > the domain name registrars indeed collected for years) of various > scams or possible errors. > > Also I agree (it seems even obvious to me) that no implementation must > refuse to contact any other JID because it uses strange characters or > mixes. BUT there are still 2 other kinds of recommendations we could > do: > > 1/ remind deployment servers, when writing their policy, that there is > another risk to take into account (= other than impersonation scam and > confusion between various users): do the user needs to be joinable > easily all over the world? If you are a very locale Hungarian server, > you don't mind Hungarian characters, but if users wish to be easily > contactable from all over the world, do not forget that you may not be > if your correspondent cannot easily write your name. Of course if he > can copy-paste, this is nice, but if you gave him a business card and > your JID has hungarian characters, a French contact may not know how > to write it. > Do we have a "alias" XEP? That could solve a lot of similar problem, > for instance if I had my main JID jehan.pagès@example.net, I could > create an alias jehan.pages@example.net which would redirect to > jehan.pagès@ (actually a "clever" implementation could even > automatically create it for me, or at least "reserve" it. This is one > of many security recommendation we should do). > > 2/ Neither clients nor servers implementations must block other > server's JID with other policy (as Bernard Aboba reminds), which means > that my French server, even though it may refuse me to create a JID > with Japanese characters, must obviously definitely not refuse me to > contact my friend é›…å­ï¼ ä¾‹ãˆ.テスト. But a secure client could provide some > kind of warning system, the same way that browsers sometimes warn on > dangerous looking domain name. > For instance if you are contacted by an unknown JID (not in your > roster) using mixed (usually incompatible) characters, or strange > characters (for instance ᎫᎬᎻᎪá@example.fr, so cherookee characters, > especially while using a .fr tld!), the user should definitely be > warned by a big red banner that this can be a risk of impersonation. > The client could also provide a way for the user to check a "this > specific JID is secure, don't warn me again" box, or even a general > checkbox in the configuration if the user does not ever want to be > warned. But in any case, the default should be to warn of every > "strange" JID or combination. > For this client side also, I think recommendations of implementation > should definitely be written. > > As a conclusion, yes I definitely think we have a lot of > recommendations to do in the matter, because we could gather the wide > knowledge in this centralized place (and update it regularly as new > forms of risks are discovered). I summarize the recommendations: > (1) Advice for servers, especially for those using a public > registration system without any kind of human verification, in order > to help them define safe policies (depending on their expected users > in particular); > (2) Advice for servers to enforce additional "dynamic" restrictions > based on existing users (for instance your policy might authorize both > 'e' and 'è' characters on a French server, but if a user registered > 'pagès@', future registrations of 'pages@' should be restricted. > (3) Recommendations for clients to warn users of risks, where we would > define as exhaustively as possible, the many known kind of risks: > characters mixes; locale name's characters not corresponding to the > domain name's characters and the TLD location; common known > "looking-alike" character maps between various syllabaries, like > cheerokee or cyrillic to assume occidental alphabets, and so on. > > Also remind that apart from this, a client or server must accept any > contact but may provide appropriate warning and maybe an alias XEP (if > not already existing) could be in order. > > Note that I remember that the XSF roadmap has an item about preparing > us to work on these kind of security considerations: spam, scam, > phishing, etc. This kind of discussion could definitely enter as an > item in such a working group. Are we creating it? We already have some on these matters here: http://tools.ietf.org/html/draft-blanchet-precis-framework-02#section-10.3 http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01#section-4.3.2 However, I think we probably want to add more detailed guidance for both service providers and client developers. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 18 15:17:02 2011 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 445DA21F865B for ; Mon, 18 Jul 2011 15:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.689 X-Spam-Level: X-Spam-Status: No, score=-103.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z+I5QqAG6+S for ; Mon, 18 Jul 2011 15:16:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 61BCF21F863E for ; Mon, 18 Jul 2011 15:16:58 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BBBB140E24; Mon, 18 Jul 2011 16:17:35 -0600 (MDT) Message-ID: <4E24B0D8.90808@stpeter.im> Date: Mon, 18 Jul 2011 16:16:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Waqas Hussain References: <4E20989B.1030709@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 18 Jul 2011 22:17:02 -0000 On 7/16/11 1:54 PM, Waqas Hussain wrote: > On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre wrote: >> The good thing about the post-stringprep world is that we have agility >> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >> being stuck at Unicode 3.2! >> >> The bad thing is that we have Unicode agility. What if my client (or >> your server) has Unicode 5.0 but my server has Unicode 6.0? The parties >> might differ in their interpretation of certain code points, causing >> problems with authentication, stanza routing, etc. >> >> We might be able to mitigate these problems if we had a way to discover >> which version of Unicode the other side supports. > > That's the discussion I'm interested in. How can we mitigate Unicode > version incompatibility? And also, stringprep and post-stringprep > incompatability? Has there been anything written on this that I can > read? So far, I am not too concerned about incompatibilities between Unicode versions. See for example: https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ As you can see from that document, only three rather obscure code points changed in backward-incompatible ways between Unicode 5.0 and Unicode 6.0. Naturally, the changes between Unicode 3.2 (hardcoded into stringprep) and Unicode 6.0 were more substantial. Most of those changes were new code points, not code points that changed in backward-incompatible ways. During the transition from IDNA2003 to IDNA2008, in practice the most troublesome code points were: 00DF (LATIN SMALL LETTER SHARP S) 03C2 (GREEK SMALL LETTER FINAL SIGMA) See http://tools.ietf.org/html/rfc5894#section-7.2 for details (there are other troublesome characters, but those were the worst because they were more widely deployed). Domain registrars know about those code points and probably have special processes for dealing with them. > I don't really see there being a good solution. The best we might > reasonably be able to do is handle errors and just > accept that either two incompatible entities wont be able to > communicate at all, Unfortunate, but possible in a small number of cases. > or one entity might see the other entity as > multiple JIDs. How so? > A recommendation that servers prep JIDs on all outgoing > stanzas might fix the latter. s/recommendation/requirement/ :) But yes. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 18 15:34:34 2011 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 6D16821F880C for ; Mon, 18 Jul 2011 15:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.729 X-Spam-Level: X-Spam-Status: No, score=-102.729 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1F3zZY5xL4v for ; Mon, 18 Jul 2011 15:34:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E931D21F87ED for ; Mon, 18 Jul 2011 15:34:33 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2841240E24; Mon, 18 Jul 2011 16:35:11 -0600 (MDT) Message-ID: <4E24B4F8.9080700@stpeter.im> Date: Mon, 18 Jul 2011 16:34:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Matt Miller References: <4E209D5D.1090105@stpeter.im> <48743807-28DB-4396-A7EF-32CF34C12D54@cisco.com> In-Reply-To: <48743807-28DB-4396-A7EF-32CF34C12D54@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: XMPP Subject: Re: [xmpp] 6122bis: error handling 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, 18 Jul 2011 22:34:34 -0000 Hi Matt, Your feedback seems consistent with what Waqas posted a few days ago. I'll work on appropriate text for the next version of 6122bis. Peter On 7/18/11 8:19 AM, Matt Miller wrote: > > On Jul 15, 2011, at 14:04, Peter Saint-Andre wrote: > >> As far as I can see, most i18n-related error conditions fall into >> the following categories: >> >> 1. Initiating entity includes a non-conforming JID in the 'from' or >> 'to' attribute of a stream header. Handle via >> stream error? > > Seems reasonable. > >> >> 2. [I assume that TLS-related errors will be handled at that >> layer.] > > Indubitably (-: > >> >> 3. Client includes a non-conforming authcid or authzid in a SASL >> authentication request. Handle via SASL error, or >> do we need a new condition? >> > > I'd rather use than something specific. > >> 4. Client attempts to bind a non-conforming resourcepart. Handle >> via stanza error, or should the server generate >> a conforming resourcepart? (The latter is more friendly.) > > For the most part, I think we can leave it up to implementations. I > can see a server, even if it disregards the requested resource, would > want to error the bind request because of "bad characters", with the > (possibly erroneous) reasoning that if the client sent bad data once, > it'll do it again. > >> >> 5. Server or client includes a non-conforming 'to' or 'from' >> address on a stanza. Handle via stanza error? >> > > Seems reasonable. > >> 6. Client includes a non-conforming JID in a JID slot that is not >> used for routing purposes (e.g., 'jid' attribute of roster set). >> Handle via stanza error? Is checking of such JID >> slots a MUST or a SHOULD or a MAY on the part of the server? Do we >> leave this up to the relevant XMPP extension? > > There's two things here to consider: what implementations ought to > do, and how implementations ought to report the problem. > > For the first, I think it's mostly up to the individual > specifications the method of enforcement, although the majority of > the time the server MUST verify (or Very Bad Things® happen at > inopportune times). I lean toward leaving it to the relevant > stewards to help do the Right Thingâ„¢ here. > > For the second...well, it depends on if we want to > only pertain to addressing, or for anywhere a JID is used. RFC 6120 > § 8.3.3.8 only mentions resource binding and addressing as reasons to > return this error. I know some implementations will do different > things for different error conditions, so there might be some impact > to extending this error condition's reach. > > Personally, I'm fine with meaning "anywhere an XMPP > address is expected". From waqas20@gmail.com Mon Jul 18 16:13:08 2011 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 9272B21F87ED for ; Mon, 18 Jul 2011 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6cS6if5cLX8 for ; Mon, 18 Jul 2011 16:13:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D99B621F8784 for ; Mon, 18 Jul 2011 16:13:05 -0700 (PDT) Received: by gyd5 with SMTP id 5so1764237gyd.31 for ; Mon, 18 Jul 2011 16:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TuXQqC2RrJhchmnEHHI0XCbeGViZCJoZyd9pi8SJ9ms=; b=mqzpoAfHIIJxZ3NG91u9cRs7khPY2OejAPjWbNM/ZQ7tE8KRet+KG1pXnxsR8T7Zmv UY4+do48hm1GJFne3ZY1CMcOMhEB1Ikj4Vykaqvrl8bjXBreA18vRmhgkLzDbhJAKaOV JmL3f/bL/06E0S7fn2MFM14zyhbAnA99JfWRE= Received: by 10.151.137.1 with SMTP id p1mr6560086ybn.415.1311030785246; Mon, 18 Jul 2011 16:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Mon, 18 Jul 2011 16:12:45 -0700 (PDT) In-Reply-To: <4E24B0D8.90808@stpeter.im> References: <4E20989B.1030709@stpeter.im> <4E24B0D8.90808@stpeter.im> From: Waqas Hussain Date: Tue, 19 Jul 2011 04:12:45 +0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 18 Jul 2011 23:13:08 -0000 On Tue, Jul 19, 2011 at 3:16 AM, Peter Saint-Andre wro= te: > On 7/16/11 1:54 PM, Waqas Hussain wrote: >> >> On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre >> =A0wrote: >>> >>> The good thing about the post-stringprep world is that we have agility >>> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >>> being stuck at Unicode 3.2! >>> >>> The bad thing is that we have Unicode agility. What if my client (or >>> your server) has Unicode 5.0 but my server has Unicode 6.0? The parties >>> might differ in their interpretation of certain code points, causing >>> problems with authentication, stanza routing, etc. >>> >>> We might be able to mitigate these problems if we had a way to discover >>> which version of Unicode the other side supports. >> >> That's the discussion I'm interested in. How can we mitigate Unicode >> version incompatibility? And also, stringprep and post-stringprep >> incompatability? Has there been anything written on this that I can >> read? > > So far, I am not too concerned about incompatibilities between Unicode > versions. See for example: > > https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ > > As you can see from that document, only three rather obscure code points > changed in backward-incompatible ways between Unicode 5.0 and Unicode 6.0= . That's reassuring. > Naturally, the changes between Unicode 3.2 (hardcoded into stringprep) an= d > Unicode 6.0 were more substantial. Most of those changes were new code > points, not code points that changed in backward-incompatible ways. Durin= g > the transition from IDNA2003 to IDNA2008, in practice the most troublesom= e > code points were: > > =A0 00DF (LATIN SMALL LETTER SHARP S) > =A0 03C2 (GREEK SMALL LETTER FINAL SIGMA) > > See http://tools.ietf.org/html/rfc5894#section-7.2 for details (there are > other troublesome characters, but those were the worst because they were > more widely deployed). Domain registrars know about those code points and > probably have special processes for dealing with them. I was mainly concerned about things like Jehan's suggestion of 're-encoding'. I don't think that's somewhere we want to go. >> I don't really see there being a good solution. The best we might >> reasonably be able to do is handle =A0errors and just >> accept that either two incompatible entities wont be able to >> communicate at all, > > Unfortunate, but possible in a small number of cases. > >> or one entity might see the other entity as >> multiple JIDs. > > How so? See below. >> A recommendation that servers prep JIDs on all outgoing >> stanzas might fix the latter. > > s/recommendation/requirement/ :) > > But yes. Note what I mean here is that some servers while verifying JIDs on outgoing stanzas don't actually replace the to/from unprepped values with the prepped ones in what gets sent over the wire. So the JID ABC@example.com is sent as ABC@example.com over the wire, not as abc@example.com. This will interact badly with IDNA2003 and IDNA2008 having different outputs for a given input. Effectively, if given unprepped JID string X, which IDNA2008 preps to string Y, but IDNA2003 accepts without prepping, and given the above server behavior, a client could receive stanzas from both X and Y, and treat them as the different JIDs when they are in fact the same (that's just one example, others, e.g., the reverse could also be possible). I haven't verified that this is actually possible, but IIRC the two specs don't have the same transformations in many cases. How compatible are the IDNA2003 vs IDNA2008 transformations? -- Waqas Hussain From stpeter@stpeter.im Mon Jul 18 19:52:57 2011 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 085A421F86F9 for ; Mon, 18 Jul 2011 19:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5oST7tCc5B8 for ; Mon, 18 Jul 2011 19:52:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2856021F86EE for ; Mon, 18 Jul 2011 19:52:54 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A952F4005A; Mon, 18 Jul 2011 20:53:31 -0600 (MDT) Message-ID: <4E24F184.3040505@stpeter.im> Date: Mon, 18 Jul 2011 20:52:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Waqas Hussain References: <4E20989B.1030709@stpeter.im> <4E24B0D8.90808@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 19 Jul 2011 02:52:57 -0000 On 7/18/11 5:12 PM, Waqas Hussain wrote: > On Tue, Jul 19, 2011 at 3:16 AM, Peter Saint-Andre wrote: >> On 7/16/11 1:54 PM, Waqas Hussain wrote: >>> >>> On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre >>> wrote: >>>> >>>> The good thing about the post-stringprep world is that we have agility >>>> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >>>> being stuck at Unicode 3.2! >>>> >>>> The bad thing is that we have Unicode agility. What if my client (or >>>> your server) has Unicode 5.0 but my server has Unicode 6.0? The parties >>>> might differ in their interpretation of certain code points, causing >>>> problems with authentication, stanza routing, etc. >>>> >>>> We might be able to mitigate these problems if we had a way to discover >>>> which version of Unicode the other side supports. >>> >>> That's the discussion I'm interested in. How can we mitigate Unicode >>> version incompatibility? And also, stringprep and post-stringprep >>> incompatability? Has there been anything written on this that I can >>> read? >> >> So far, I am not too concerned about incompatibilities between Unicode >> versions. See for example: >> >> https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ >> >> As you can see from that document, only three rather obscure code points >> changed in backward-incompatible ways between Unicode 5.0 and Unicode 6.0. > > That's reassuring. > >> Naturally, the changes between Unicode 3.2 (hardcoded into stringprep) and >> Unicode 6.0 were more substantial. Most of those changes were new code >> points, not code points that changed in backward-incompatible ways. During >> the transition from IDNA2003 to IDNA2008, in practice the most troublesome >> code points were: >> >> 00DF (LATIN SMALL LETTER SHARP S) >> 03C2 (GREEK SMALL LETTER FINAL SIGMA) >> >> See http://tools.ietf.org/html/rfc5894#section-7.2 for details (there are >> other troublesome characters, but those were the worst because they were >> more widely deployed). Domain registrars know about those code points and >> probably have special processes for dealing with them. > > I was mainly concerned about things like Jehan's suggestion of > 're-encoding'. I don't think that's somewhere we want to go. Agreed. >>> I don't really see there being a good solution. The best we might >>> reasonably be able to do is handle errors and just >>> accept that either two incompatible entities wont be able to >>> communicate at all, >> >> Unfortunate, but possible in a small number of cases. >> >>> or one entity might see the other entity as >>> multiple JIDs. >> >> How so? > > See below. > >>> A recommendation that servers prep JIDs on all outgoing >>> stanzas might fix the latter. >> >> s/recommendation/requirement/ :) >> >> But yes. > > Note what I mean here is that some servers while verifying JIDs on > outgoing stanzas don't actually replace the to/from unprepped values > with the prepped ones in what gets sent over the wire. So the JID > ABC@example.com is sent as ABC@example.com over the wire, not as > abc@example.com. This will interact badly with IDNA2003 and IDNA2008 > having different outputs for a given input. I see your point, and I agree that prepping all outbound JIDs would help to avoid this problem. Paradoxically, prepping inbound JIDs would hurt, not help (see below). > Effectively, if given unprepped JID string X, which IDNA2008 preps to > string Y, but IDNA2003 accepts without prepping, and given the above > server behavior, a client could receive stanzas from both X and Y, and > treat them as the different JIDs when they are in fact the same > (that's just one example, others, e.g., the reverse could also be > possible). I haven't verified that this is actually possible, but IIRC > the two specs don't have the same transformations in many cases. How > compatible are the IDNA2003 vs IDNA2008 transformations? As explained in RFC 5894, in fact there are few characters that are interpreted differently in IDNA2008 compared to IDNA2003: Eszett, Greek Final Sigma, Zero Width Joiner, and Zero Width Non-Joiner. So, for instance, in IDNA2003 you could register fussball.de but not fußball.de because ß was mapped to "ss" (see Appendix B of RFC 3454, i.e. "Table B.2" as invoked by Nameprep in RFC 3491). In IDNA2008, ß is a distinct, allowable character, so you can now register fußball.de. Clearly the registrar for .de needs to know this when accepting registrations, because it might want to reserve fußball.de if fussball.de is already registered, automatically assign fußball.de to the registrant for fussball.de, or apply some other policy. Now, the same is true for Nodeprep as used to stringprep the localpart of JIDs -- see Appendix A of RFC 3920. So in the current XMPP network (RFC 6122), you could register an account like fussball@example.com but if you tried to register fußball@example.com it would be stringprepped to fussball@example.com. If we migrate to 6122bis, fußball would be allowed as a username. Therefore a 6122bis-compliant server might allow both accounts to be registered and might route stanzas from both fussball@example.com and fußball@example.com over an s2s link to your server. But if your 6122-compliant server stringpreps JIDs on incoming stanzas then it would consider both of those JIDs to be the same, since it doesn't consider fußball@example.com to be valid (if your server doesn't stringprep JIDs on incoming stanzas then it would return a error instead). Clearly this opens up the possibility of some attacks -- if I know you are subscribed to fussball@example.com for the latest scores, I could register fußball@example.com and send you bogus information. As mentioned, this applies to four characters that are allowed in IDNA2008 and PRECIS (with the caveat that PRECIS isn't done yet!) but that are mapped to other characters (ß mapped to ss, Ï‚ mapped to σ) or to nothing (for Zero Width Joiner and Zero Width Non-Joiner) in IDNA2003 and Nodeprep. In these four cases, the post-stringprep technologies are more inclusive and we could have problems of the kind I've outlined above (not "double JIDs" but certain new JIDs registered with 6122bis-compliant servers that would be treated as equivalent to old JIDs by 6122-compliant software). Any migration plan we devise will need to provide guidelines for handling these cases. All of this is a lot easier if existing servers reject JIDs that they consider malformed, instead of prepping them. However, note that RFCs 3920 and 6120 don't say that a server MUST reject malformed JIDs, so some existing servers might be liberal in what they accept, which in this case leads to bad consequences. Peter -- Peter Saint-Andre https://stpeter.im/ From jehan.marmottard@gmail.com Mon Jul 18 21:22:53 2011 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 7C1B721F871E for ; Mon, 18 Jul 2011 21:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWR7+tKieZEs for ; Mon, 18 Jul 2011 21:22:53 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB33F21F8713 for ; Mon, 18 Jul 2011 21:22:52 -0700 (PDT) Received: by wwe5 with SMTP id 5so2568069wwe.13 for ; Mon, 18 Jul 2011 21:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VND4KZSshMx/ohhdM5QuKn3S0mKJITp3gKSYGRCN6eo=; b=HKcXnI6thVcYfPPF52d0DQ4UPvOSagYsqtLkP+pp9ZOAB3tnukaZIsQO8MVZztbxDv 30YDsR7GZijjVti0F5zDWLXJd50t/GIV0g8nhhtY8HD3cmZW3rc6HxASHuOxcYSbWESC wGyODMxuVlNs3P0bjfabV2haU3ytPbN7hdzxs= MIME-Version: 1.0 Received: by 10.216.229.222 with SMTP id h72mr6155204weq.34.1311049370460; Mon, 18 Jul 2011 21:22:50 -0700 (PDT) Received: by 10.216.85.148 with HTTP; Mon, 18 Jul 2011 21:22:50 -0700 (PDT) In-Reply-To: <4E24ACB4.8000104@stpeter.im> References: <4E20A38C.6040507@stpeter.im> <4E24ACB4.8000104@stpeter.im> Date: Tue, 19 Jul 2011 13:22:50 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] Fwd: 6122bis: servers as "registrars" 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, 19 Jul 2011 04:22:53 -0000 Hi, 2011/7/19 Peter Saint-Andre : > On 7/17/11 3:56 AM, Jehan Pag=E8s wrote: [...] >> Note that I remember that the XSF roadmap has an item about preparing >> us to work on these kind of security considerations: spam, scam, >> phishing, etc. This kind of discussion could definitely enter as an >> item in such a working group. Are we creating it? > > We already have some on these matters here: > > http://tools.ietf.org/html/draft-blanchet-precis-framework-02#section-10.= 3 > > http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01#section-4.3.2 > > However, I think we probably want to add more detailed guidance for both > service providers and client developers. > Yes I remember these texts. But as you say, I think we should have more detailed guidance, and probably also in separate documents. Like one document could be a guide for public server deployment. And one other could be a guide for client implementers. XMPP is great for identifying JIDs but it does not cover all issues, and especially those i18n matters, though necessary, create many hard-to-counter attacks (as you showed well with your example in the Unicode version thread). One day, if XMPP gets the attention it deserves (and that's the goal), we'll get there too (people trying to scam others, directly or setting bots for this, and so on). So let's prepare better than were other protocols (even though it is a never-ending preparation). Jehan From waqas20@gmail.com Mon Jul 18 22:49:53 2011 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 DC7AD21F86A1 for ; Mon, 18 Jul 2011 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or8CYeSwTiBg for ; Mon, 18 Jul 2011 22:49:49 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9E21F8680 for ; Mon, 18 Jul 2011 22:49:49 -0700 (PDT) Received: by gwb20 with SMTP id 20so1863881gwb.31 for ; Mon, 18 Jul 2011 22:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=elPLInBGSz36NNESO4ncmEQQWA3eS4ae2/MsbZX4pis=; b=dShAiZu13ZflzzbwN6+BVef8ColU6R5MF1+gCTLO7wM8XvvIAkEc0PiaOgeXx3E4CK Z0TDCzOJSXX6MpjGVPS7sG38zobO4rpKReiWkmHDn6v8ETfNZVm/nZXXV+ezn0YBgmGT fGkSS7Yi6nUSM1RAY3fUE630V6Rw81DKlZtR4= Received: by 10.150.117.23 with SMTP id p23mr5380512ybc.358.1311054588135; Mon, 18 Jul 2011 22:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Mon, 18 Jul 2011 22:49:28 -0700 (PDT) In-Reply-To: <4E24F184.3040505@stpeter.im> References: <4E20989B.1030709@stpeter.im> <4E24B0D8.90808@stpeter.im> <4E24F184.3040505@stpeter.im> From: Waqas Hussain Date: Tue, 19 Jul 2011 10:49:28 +0500 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 19 Jul 2011 05:49:54 -0000 On Tue, Jul 19, 2011 at 7:52 AM, Peter Saint-Andre wro= te: > On 7/18/11 5:12 PM, Waqas Hussain wrote: >> >> On Tue, Jul 19, 2011 at 3:16 AM, Peter Saint-Andre >> =C2=A0wrote: >>> >>> On 7/16/11 1:54 PM, Waqas Hussain wrote: >>>> >>>> On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre >>>> =C2=A0wrote: >>>>> >>>>> The good thing about the post-stringprep world is that we have agilit= y >>>>> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >>>>> being stuck at Unicode 3.2! >>>>> >>>>> The bad thing is that we have Unicode agility. What if my client (or >>>>> your server) has Unicode 5.0 but my server has Unicode 6.0? The parti= es >>>>> might differ in their interpretation of certain code points, causing >>>>> problems with authentication, stanza routing, etc. >>>>> >>>>> We might be able to mitigate these problems if we had a way to discov= er >>>>> which version of Unicode the other side supports. >>>> >>>> That's the discussion I'm interested in. How can we mitigate Unicode >>>> version incompatibility? And also, stringprep and post-stringprep >>>> incompatability? Has there been anything written on this that I can >>>> read? >>> >>> So far, I am not too concerned about incompatibilities between Unicode >>> versions. See for example: >>> >>> https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ >>> >>> As you can see from that document, only three rather obscure code point= s >>> changed in backward-incompatible ways between Unicode 5.0 and Unicode >>> 6.0. >> >> That's reassuring. >> >>> Naturally, the changes between Unicode 3.2 (hardcoded into stringprep) >>> and >>> Unicode 6.0 were more substantial. Most of those changes were new code >>> points, not code points that changed in backward-incompatible ways. >>> During >>> the transition from IDNA2003 to IDNA2008, in practice the most >>> troublesome >>> code points were: >>> >>> =C2=A0 00DF (LATIN SMALL LETTER SHARP S) >>> =C2=A0 03C2 (GREEK SMALL LETTER FINAL SIGMA) >>> >>> See http://tools.ietf.org/html/rfc5894#section-7.2 for details (there a= re >>> other troublesome characters, but those were the worst because they wer= e >>> more widely deployed). Domain registrars know about those code points a= nd >>> probably have special processes for dealing with them. >> >> I was mainly concerned about things like Jehan's suggestion of >> 're-encoding'. I don't think that's somewhere we want to go. > > Agreed. > >>>> I don't really see there being a good solution. The best we might >>>> reasonably be able to do is handle =C2=A0 =C2=A0errors= and just >>>> accept that either two incompatible entities wont be able to >>>> communicate at all, >>> >>> Unfortunate, but possible in a small number of cases. >>> >>>> or one entity might see the other entity as >>>> multiple JIDs. >>> >>> How so? >> >> See below. >> >>>> A recommendation that servers prep JIDs on all outgoing >>>> stanzas might fix the latter. >>> >>> s/recommendation/requirement/ :) >>> >>> But yes. >> >> Note what I mean here is that some servers while verifying JIDs on >> outgoing stanzas don't actually replace the to/from unprepped values >> with the prepped ones in what gets sent over the wire. So the JID >> ABC@example.com is sent as ABC@example.com over the wire, not as >> abc@example.com. This will interact badly with IDNA2003 and IDNA2008 >> having different outputs for a given input. > > I see your point, and I agree that prepping all outbound JIDs would help = to > avoid this problem. Paradoxically, prepping inbound JIDs would hurt, not > help (see below). It helps too: I could create the JID fussball@example.com on a IDNA2003 server, and send stanzas as both fu=C3=9Fball@example.com and fussball@example.com. If my server passes the 'from' attribute as-is, I can make myself seem like two entities to an IDNA2008 server/client. Not too worrying a problem I suppose. >> Effectively, if given unprepped JID string X, which IDNA2008 preps to >> string Y, but IDNA2003 accepts without prepping, and given the above >> server behavior, a client could receive stanzas from both X and Y, and >> treat them as the different JIDs when they are in fact the same >> (that's just one example, others, e.g., the reverse could also be >> possible). I haven't verified that this is actually possible, but IIRC >> the two specs don't have the same transformations in many cases. How >> compatible are the IDNA2003 vs IDNA2008 transformations? > > As explained in RFC 5894, in fact there are few characters that are > interpreted differently in IDNA2008 compared to IDNA2003: Eszett, Greek > Final Sigma, Zero Width Joiner, and Zero Width Non-Joiner. > > So, for instance, in IDNA2003 you could register fussball.de but not > fu=C3=9Fball.de because =C3=9F was mapped to "ss" (see Appendix B of RFC = 3454, i.e. > "Table B.2" as invoked by Nameprep in RFC 3491). In IDNA2008, =C3=9F is a > distinct, allowable character, so you can now register fu=C3=9Fball.de. C= learly > the registrar for .de needs to know this when accepting registrations, > because it might want to reserve fu=C3=9Fball.de if fussball.de is alread= y > registered, automatically assign fu=C3=9Fball.de to the registrant for > fussball.de, or apply some other policy. > > Now, the same is true for Nodeprep as used to stringprep the localpart of > JIDs -- see Appendix A of RFC 3920. So in the current XMPP network (RFC > 6122), you could register an account like fussball@example.com but if you > tried to register fu=C3=9Fball@example.com it would be stringprepped to > fussball@example.com. If we migrate to 6122bis, fu=C3=9Fball would be all= owed as > a username. Therefore a 6122bis-compliant server might allow both account= s > to be registered and might route stanzas from both fussball@example.com a= nd > fu=C3=9Fball@example.com over an s2s link to your server. But if your > 6122-compliant server stringpreps JIDs on incoming stanzas then it would > consider both of those JIDs to be the same, since it doesn't consider > fu=C3=9Fball@example.com to be valid (if your server doesn't stringprep J= IDs on > incoming stanzas then it would return a error instead). > Clearly this opens up the possibility of some attacks -- if I know you ar= e > subscribed to fussball@example.com for the latest scores, I could registe= r > fu=C3=9Fball@example.com and send you bogus information. This makes a bit nervous. I assume this affects more than just XMPP? I'm interested in hearing what non-XMPP folks might have to say on the matter. > As mentioned, this applies to four characters that are allowed in IDNA200= 8 > and PRECIS (with the caveat that PRECIS isn't done yet!) but that are map= ped > to other characters (=C3=9F mapped to ss, =CF=82 mapped to =CF=83) or to = nothing (for Zero > Width Joiner and Zero Width Non-Joiner) in IDNA2003 and Nodeprep. In thes= e > four cases, the post-stringprep technologies are more inclusive and we co= uld > have problems of the kind I've outlined above (not "double JIDs" but cert= ain > new JIDs registered with 6122bis-compliant servers that would be treated = as > equivalent to old JIDs by 6122-compliant software). Any migration plan we > devise will need to provide guidelines for handling these cases. +1. > All of this is a lot easier if existing servers reject JIDs that they > consider malformed, instead of prepping them. However, note that RFCs 392= 0 > and 6120 don't say that a server MUST reject malformed JIDs, so some > existing servers might be liberal in what they accept, which in this case > leads to bad consequences. I think that's what existing servers probably do. We can check/ask them. The ones which do stringprep anyway :) > Peter -- Waqas Hussain From stpeter@stpeter.im Tue Jul 19 09:22:30 2011 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 550611F0C39 for ; Tue, 19 Jul 2011 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.723 X-Spam-Level: X-Spam-Status: No, score=-103.723 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYlrWQ29ULQ2 for ; Tue, 19 Jul 2011 09:22:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C71A81F0C37 for ; Tue, 19 Jul 2011 09:22:25 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EB4564005A; Tue, 19 Jul 2011 10:23:04 -0600 (MDT) Message-ID: <4E25AF3F.5020400@stpeter.im> Date: Tue, 19 Jul 2011 10:22:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Waqas Hussain References: <4E20989B.1030709@stpeter.im> <4E24B0D8.90808@stpeter.im> <4E24F184.3040505@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: XMPP Subject: Re: [xmpp] 6122bis: Unicode versions 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, 19 Jul 2011 16:22:30 -0000 On 7/18/11 11:49 PM, Waqas Hussain wrote: > On Tue, Jul 19, 2011 at 7:52 AM, Peter Saint-Andre wrote: >> On 7/18/11 5:12 PM, Waqas Hussain wrote: >>> >>> On Tue, Jul 19, 2011 at 3:16 AM, Peter Saint-Andre >>> wrote: >>>> >>>> On 7/16/11 1:54 PM, Waqas Hussain wrote: >>>>> >>>>> On Sat, Jul 16, 2011 at 12:44 AM, Peter Saint-Andre >>>>> wrote: >>>>>> >>>>>> The good thing about the post-stringprep world is that we have agility >>>>>> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >>>>>> being stuck at Unicode 3.2! >>>>>> >>>>>> The bad thing is that we have Unicode agility. What if my client (or >>>>>> your server) has Unicode 5.0 but my server has Unicode 6.0? The parties >>>>>> might differ in their interpretation of certain code points, causing >>>>>> problems with authentication, stanza routing, etc. >>>>>> >>>>>> We might be able to mitigate these problems if we had a way to discover >>>>>> which version of Unicode the other side supports. >>>>> >>>>> That's the discussion I'm interested in. How can we mitigate Unicode >>>>> version incompatibility? And also, stringprep and post-stringprep >>>>> incompatability? Has there been anything written on this that I can >>>>> read? >>>> >>>> So far, I am not too concerned about incompatibilities between Unicode >>>> versions. See for example: >>>> >>>> https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ >>>> >>>> As you can see from that document, only three rather obscure code points >>>> changed in backward-incompatible ways between Unicode 5.0 and Unicode >>>> 6.0. >>> >>> That's reassuring. >>> >>>> Naturally, the changes between Unicode 3.2 (hardcoded into stringprep) >>>> and >>>> Unicode 6.0 were more substantial. Most of those changes were new code >>>> points, not code points that changed in backward-incompatible ways. >>>> During >>>> the transition from IDNA2003 to IDNA2008, in practice the most >>>> troublesome >>>> code points were: >>>> >>>> 00DF (LATIN SMALL LETTER SHARP S) >>>> 03C2 (GREEK SMALL LETTER FINAL SIGMA) >>>> >>>> See http://tools.ietf.org/html/rfc5894#section-7.2 for details (there are >>>> other troublesome characters, but those were the worst because they were >>>> more widely deployed). Domain registrars know about those code points and >>>> probably have special processes for dealing with them. >>> >>> I was mainly concerned about things like Jehan's suggestion of >>> 're-encoding'. I don't think that's somewhere we want to go. >> >> Agreed. >> >>>>> I don't really see there being a good solution. The best we might >>>>> reasonably be able to do is handle errors and just >>>>> accept that either two incompatible entities wont be able to >>>>> communicate at all, >>>> >>>> Unfortunate, but possible in a small number of cases. >>>> >>>>> or one entity might see the other entity as >>>>> multiple JIDs. >>>> >>>> How so? >>> >>> See below. >>> >>>>> A recommendation that servers prep JIDs on all outgoing >>>>> stanzas might fix the latter. >>>> >>>> s/recommendation/requirement/ :) >>>> >>>> But yes. >>> >>> Note what I mean here is that some servers while verifying JIDs on >>> outgoing stanzas don't actually replace the to/from unprepped values >>> with the prepped ones in what gets sent over the wire. So the JID >>> ABC@example.com is sent as ABC@example.com over the wire, not as >>> abc@example.com. This will interact badly with IDNA2003 and IDNA2008 >>> having different outputs for a given input. >> >> I see your point, and I agree that prepping all outbound JIDs would help to >> avoid this problem. Paradoxically, prepping inbound JIDs would hurt, not >> help (see below). > > It helps too: I could create the JID fussball@example.com on a > IDNA2003 server, and send stanzas as both fußball@example.com and > fussball@example.com. If my server passes the 'from' attribute as-is, > I can make myself seem like two entities to an IDNA2008 server/client. > Not too worrying a problem I suppose. Sorry, I was not clear: I meant prepping on inbound s2s stanzas. The principle is that the first server processing a stanza must enforce the rules. I think your example of the example.com server allowing a client to send stanzas from either fußball@example.com or fussball@example.com is wrong, because an XMPP server that implements Nodeprep would have to prep the fußball username to fussball when the client sends the stanza. >>> Effectively, if given unprepped JID string X, which IDNA2008 preps to >>> string Y, but IDNA2003 accepts without prepping, and given the above >>> server behavior, a client could receive stanzas from both X and Y, and >>> treat them as the different JIDs when they are in fact the same >>> (that's just one example, others, e.g., the reverse could also be >>> possible). I haven't verified that this is actually possible, but IIRC >>> the two specs don't have the same transformations in many cases. How >>> compatible are the IDNA2003 vs IDNA2008 transformations? >> >> As explained in RFC 5894, in fact there are few characters that are >> interpreted differently in IDNA2008 compared to IDNA2003: Eszett, Greek >> Final Sigma, Zero Width Joiner, and Zero Width Non-Joiner. >> >> So, for instance, in IDNA2003 you could register fussball.de but not >> fußball.de because ß was mapped to "ss" (see Appendix B of RFC 3454, i.e. >> "Table B.2" as invoked by Nameprep in RFC 3491). In IDNA2008, ß is a >> distinct, allowable character, so you can now register fußball.de. Clearly >> the registrar for .de needs to know this when accepting registrations, >> because it might want to reserve fußball.de if fussball.de is already >> registered, automatically assign fußball.de to the registrant for >> fussball.de, or apply some other policy. >> >> Now, the same is true for Nodeprep as used to stringprep the localpart of >> JIDs -- see Appendix A of RFC 3920. So in the current XMPP network (RFC >> 6122), you could register an account like fussball@example.com but if you >> tried to register fußball@example.com it would be stringprepped to >> fussball@example.com. If we migrate to 6122bis, fußball would be allowed as >> a username. Therefore a 6122bis-compliant server might allow both accounts >> to be registered and might route stanzas from both fussball@example.com and >> fußball@example.com over an s2s link to your server. But if your >> 6122-compliant server stringpreps JIDs on incoming stanzas then it would >> consider both of those JIDs to be the same, since it doesn't consider >> fußball@example.com to be valid (if your server doesn't stringprep JIDs on >> incoming stanzas then it would return a error instead). >> Clearly this opens up the possibility of some attacks -- if I know you are >> subscribed to fussball@example.com for the latest scores, I could register >> fußball@example.com and send you bogus information. > > This makes a bit nervous. Me too. But it's unavoidable if we decide to migrate from stringprep to PRECIS, and we already have this issue for domain names (it's just that we assume the zone administrators will take care of it for us). > I assume this affects more than just XMPP? I'm interested in hearing > what non-XMPP folks might have to say on the matter. Well, I think we have more deployment of stringprep than any other non-IDN application technology -- I don't hear about much problems with non-ASCII characters in the context of IMAP or POP using SASLprep, or of LDAPprep, or of the iSCSI stringprep profile. However, this is something that definitely needs to be discussed in the PRECIS WG. >> As mentioned, this applies to four characters that are allowed in IDNA2008 >> and PRECIS (with the caveat that PRECIS isn't done yet!) but that are mapped >> to other characters (ß mapped to ss, Ï‚ mapped to σ) or to nothing (for Zero >> Width Joiner and Zero Width Non-Joiner) in IDNA2003 and Nodeprep. In these >> four cases, the post-stringprep technologies are more inclusive and we could >> have problems of the kind I've outlined above (not "double JIDs" but certain >> new JIDs registered with 6122bis-compliant servers that would be treated as >> equivalent to old JIDs by 6122-compliant software). Any migration plan we >> devise will need to provide guidelines for handling these cases. > > +1. > >> All of this is a lot easier if existing servers reject JIDs that they >> consider malformed, instead of prepping them. However, note that RFCs 3920 >> and 6120 don't say that a server MUST reject malformed JIDs, so some >> existing servers might be liberal in what they accept, which in this case >> leads to bad consequences. > > I think that's what existing servers probably do. We can check/ask > them. The ones which do stringprep anyway :) Yes, it would be good to complete a survey of existing server implementations on this point. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 19 09:46:31 2011 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 32F7421F84DE for ; Tue, 19 Jul 2011 09:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.758 X-Spam-Level: X-Spam-Status: No, score=-102.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP+a5uNgp3vi for ; Tue, 19 Jul 2011 09:46:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0997321F84DB for ; Tue, 19 Jul 2011 09:46:27 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A31D4005A; Tue, 19 Jul 2011 10:47:06 -0600 (MDT) Message-ID: <4E25B4E1.7080907@stpeter.im> Date: Tue, 19 Jul 2011 10:46:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Richard L. Barnes" References: <9841FBF8-11D1-4A81-953E-920EEDA00208@bbn.com> In-Reply-To: <9841FBF8-11D1-4A81-953E-920EEDA00208@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] DNA/S2S Part 2: Authentication 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, 19 Jul 2011 16:46:31 -0000 A few thoughts on tradeoffs... On 7/15/11 3:46 PM, Richard L. Barnes wrote: > Given that, some of the trade-offs between the two approaches are: - > Issuance: Signing a zone vs. Getting a CA to issue an XMPP cert IMHO signing a zone is a lot easier than getting a CA to issue an XMPP-only certificate. As one data point, the XSF used to run an intermediate CA, and did convince the root CA we were working with at the time to issue certs containing id-on-XmppAddr fields. However, that required retooling at the CA and they did it because they were small and nimble. Convincing a larger CA to do that kind of thing might be a bit of a challenge because tooling changes might be necessary, and what CA wants to make such changes if they don't need to? By contrast, signing your own zone is relatively straightforward. Furthermore, a change to using XMPP-only certificates somewhat goes against what we mandate in RFC 6120 (Section 13.7.1.2), i.e., MUST support DNS-ID. > - Verification: Validating DNSSEC vs. Validating PKIX Assuming we're using "normal" PKIX certificates and not attribute certificates, here validating PKIK is probably easier, although we'd need to do some research into things like support for SRV-IDs in existing TLS libraries, vs. support for (and application access to) DNSSEC in common DNS libraries. > - Revocation: Limited by DNS TTLs vs. PKIX revocation (CRL/OCSP) Interesting question, given long-lived TCP connections in XMPP. It seems to me that in the DNSSEC case, you're generating your own credential and placing it in the DNS, so if you decide to rekey you could simply restart streams that are using the older key. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 19 12:02:19 2011 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 6A51511E8082 for ; Tue, 19 Jul 2011 12:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpz+PJphrRll for ; Tue, 19 Jul 2011 12:02:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BE21D11E8097 for ; Tue, 19 Jul 2011 12:01:30 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 743144005A for ; Tue, 19 Jul 2011 13:02:10 -0600 (MDT) Message-ID: <4E25D489.9020801@stpeter.im> Date: Tue, 19 Jul 2011 13:01:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: XMPP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 19 Jul 2011 19:02:19 -0000 FYI. This will mostly be a reprise of the tutorial I presented at the interim meeting in Brussels. -------- Original Message -------- Subject: [apps-discuss] i18n intro, Sunday 14:00-16:00 Date: Tue, 19 Jul 2011 12:48:39 -0600 From: Peter Saint-Andre To: apps-discuss@ietf.org You might have noticed a curious item on the agenda at 14:00 on Sunday: "Apps Area Preparatory Meeting for Internationalization Working Groups". At that time, I will present an introduction to internationalization, assisted by Pete Resnick (who will correct me where I go wrong). The intent of this session is to help apps-area folks learn more about internationalization, especially in preparation for the PRECIS WG meeting on Thursday. The room we've been assigned (2103) holds up to 60 people so we should have plenty of space, and there is no need to sign up if you want to attend. If this session goes well, Pete and I might offer a more general tutorial at a future IETF meeting. Consider Sunday's session a dry run. See you in Quebec City! Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From rbarnes@bbn.com Tue Jul 19 14:56:57 2011 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 0775621F858A; Tue, 19 Jul 2011 14:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a5S6Vb8TfRX; Tue, 19 Jul 2011 14:56:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8320721F8572; Tue, 19 Jul 2011 14:56:56 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:62851) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QjIHd-000D7r-Ni; Tue, 19 Jul 2011 17:56:53 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 17:56:48 -0400 Message-Id: To: XMPP Working Group , GEOPRIV WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [xmpp] Combining XMPP and GEOPRIV 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, 19 Jul 2011 21:56:57 -0000 Dear XMPP and GEOPRIV participants, A brief agenda update, which should be reflected on the official agenda = soon: In order to resolve the conflict between XMPP and GEOPRIV on Tuesday = morning of the IETF meeting, the chairs of the two groups have decided = to run their sessions in sequence instead of in parallel. The = 150-minute morning session will be divided into two 75-minute sessions. XMPP: 09:00 - 10:15 GEOPRIV: 10:15 - 12:30 Both session will be held in room 206A, the room previously assigned for = the GEOPRIV session. The agendas for the individual sessions will of = course be posted on the meeting materials pages. Sincerely, GEOPRIV and XMPP co-chairs= From jmpolk@cisco.com Tue Jul 19 15:27:43 2011 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 1578911E8092; Tue, 19 Jul 2011 15:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.774 X-Spam-Level: X-Spam-Status: No, score=-104.774 tagged_above=-999 required=5 tests=[AWL=-2.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd0DIf0IRdcG; Tue, 19 Jul 2011 15:27:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5703611E8095; Tue, 19 Jul 2011 15:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=949; q=dns/txt; s=iport; t=1311114462; x=1312324062; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=nhmXvI7af+aPh6ptfdwWZs7riypxy/CLt1OYYU6dz3I=; b=ma7FhyK712XfcNswEjRkg7pCP1oiAXSDanovAGEcetVtIsu5WzUDeUu5 qY2Z7+A5SjBE0DK3Evb1AOnavrlepUkaw5McJD7aEkjeao+memI5eHiuQ 75R9S5T/3O/81k27oNzkf/V2rKKCWcEZ90+Z65Z66PLLSe/12Rj7LeEkU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF0EJk6rRDoH/2dsb2JhbABUp1d3rkqeSIY8BIdUnAw X-IronPort-AV: E=Sophos;i="4.67,230,1309737600"; d="scan'208";a="4518685" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jul 2011 22:27:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6JMRemq032074; Tue, 19 Jul 2011 22:27:41 GMT Message-Id: <201107192227.p6JMRemq032074@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jul 2011 17:27:34 -0500 To: "Richard L. Barnes" , XMPP Working Group , GEOPRIV WG From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 19 Jul 2011 15:55:55 -0700 Subject: Re: [xmpp] [Geopriv] Combining XMPP and GEOPRIV 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, 19 Jul 2011 22:27:43 -0000 Richard ending at 12:30 or 11:30? James At 04:56 PM 7/19/2011, Richard L. Barnes wrote: >Dear XMPP and GEOPRIV participants, > >A brief agenda update, which should be reflected on the official agenda soon: > >In order to resolve the conflict between XMPP and GEOPRIV on Tuesday >morning of the IETF meeting, the chairs of the two groups have >decided to run their sessions in sequence instead of in >parallel. The 150-minute morning session will be divided into two >75-minute sessions. > >XMPP: 09:00 - 10:15 >GEOPRIV: 10:15 - 12:30 > >Both session will be held in room 206A, the room previously assigned >for the GEOPRIV session. The agendas for the individual sessions >will of course be posted on the meeting materials pages. > >Sincerely, >GEOPRIV and XMPP co-chairs >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www.ietf.org/mailman/listinfo/geopriv From ben@nostrum.com Tue Jul 19 15:58:11 2011 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 B0DCC11E8095; Tue, 19 Jul 2011 15:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwPvgRY7iUnH; Tue, 19 Jul 2011 15:58:11 -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 B41DC11E8092; Tue, 19 Jul 2011 15:58:10 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6JMw2aP015142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 17:58:03 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <201107192227.p6JMRemq032074@mtv-core-2.cisco.com> Date: Tue, 19 Jul 2011 17:58:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107192227.p6JMRemq032074@mtv-core-2.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: GEOPRIV WG , XMPP Working Group Subject: Re: [xmpp] [Geopriv] Combining XMPP and GEOPRIV 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, 19 Jul 2011 22:58:11 -0000 On Jul 19, 2011, at 5:27 PM, James M. Polk wrote: > Richard >=20 > ending at 12:30 or 11:30? >=20 I assume that to be a typo--It should say 1130. Thanks! Ben. > James >=20 > At 04:56 PM 7/19/2011, Richard L. Barnes wrote: >> Dear XMPP and GEOPRIV participants, >>=20 >> A brief agenda update, which should be reflected on the official = agenda soon: >>=20 >> In order to resolve the conflict between XMPP and GEOPRIV on Tuesday = morning of the IETF meeting, the chairs of the two groups have decided = to run their sessions in sequence instead of in parallel. The = 150-minute morning session will be divided into two 75-minute sessions. >>=20 >> XMPP: 09:00 - 10:15 >> GEOPRIV: 10:15 - 12:30 >>=20 >> Both session will be held in room 206A, the room previously assigned = for the GEOPRIV session. The agendas for the individual sessions will = of course be posted on the meeting materials pages. >>=20 >> Sincerely, >> GEOPRIV and XMPP co-chairs >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From florob@babelmonkeys.de Wed Jul 20 04:47:12 2011 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 BD79F21F880C for ; Wed, 20 Jul 2011 04:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9clY2o9pQylV for ; Wed, 20 Jul 2011 04:47:08 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id CA31F21F871E for ; Wed, 20 Jul 2011 04:47:07 -0700 (PDT) Received: from [134.130.62.164] by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QjVF1-000601-Oe for xmpp@ietf.org; Wed, 20 Jul 2011 13:47:03 +0200 Message-ID: <4E26C032.3090409@babelmonkeys.de> Date: Wed, 20 Jul 2011 13:46:58 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <4E20989B.1030709@stpeter.im> In-Reply-To: <4E20989B.1030709@stpeter.im> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis: Unicode versions 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, 20 Jul 2011 11:47:12 -0000 Am 15.07.2011 21:44, schrieb Peter Saint-Andre: > The good thing about the post-stringprep world is that we have agility > with regard to Unicode versions (a.k.a. "Unicode agility"). No more > being stuck at Unicode 3.2! > > The bad thing is that we have Unicode agility. What if my client (or > your server) has Unicode 5.0 but my server has Unicode 6.0? The parties > might differ in their interpretation of certain code points, causing > problems with authentication, stanza routing, etc. > First I'd like to say that I expect some guidance on this from the work of the PRECIS WG. I'd consider a lack of that at least as bad as being stuck with Unicode 3.2. Therefore I think part of this discussion should probably be held over there. Another thing is that I think we first need to understand what the possible problems are, before we try to avoid them. I think we should safely be able to assume that a valid localpart stays a valid localpart even with new Unicode versions (this should be possible by adding entries to a list of exception. We would of course hope/expect that this is not needed very often, if at all). What I consider more problematic is normalizaion. I don't know how probable it is, but there might be cases where NFC(A, Unicode5) == NFC(B, Unicode5), but NFC(A, Unicode6) != NFC(B, Unicode6), or NFC(A, Unicode5) != NFC(B, Unicode6), etc. And that is something we can't really fix. So we should look into problems that this get's us into. This is possibly the same problem as the stringprep vs. IDNA2008 discussion just in a different form. One of the problems this would yield is that two accounts that are different with Unicode 6 are registered on a server A. Another server B using Unicode 5 considers both the same. Now if a user on server B tries to send to either of the two accounts on server A messages will only end up at one of them, potentially the wrong one. Also in this case it's not usfull for server A to know that server B uses Unicode 5, because he still can't tell which of the two accounts B meant to send to, at best he could warn about this situation. Now maybe there are situations where having this information can be usfull, but I'd rather have them thought through before painting the bikeshed by choosing a URI. -- Florian Zeitz > We might be able to mitigate these problems if we had a way to discover > which version of Unicode the other side supports. Using XEP-0030 or > stream features, we'd want a URI for each Unicode version, such as: > > http://www.unicode.org/versions/Unicode6.0.0/ (the web page for 6.0) > > or: > > urn:unicode:versions:6.0.0 > > Two questions: > > 1. Do we think that a service discovery feature would be useful here? > > 2. If so, do we think the URLs from http://www.unicode.org/ are stable > enough, or would people like to have a URN? (I've asked someone from the > Unicode Consortium about a URN namespace for Unicode, but if we don't > think we'll need it then I won't pursue it further.) > > Peter > From stpeter@stpeter.im Wed Jul 20 20:22:06 2011 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 111D721F86F6 for ; Wed, 20 Jul 2011 20:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq-3Gd+kDvdf for ; Wed, 20 Jul 2011 20:22:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 793BE21F86E9 for ; Wed, 20 Jul 2011 20:22:05 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3BEB410EE for ; Wed, 20 Jul 2011 21:22:48 -0600 (MDT) Message-ID: <4E279B53.7070100@stpeter.im> Date: Wed, 20 Jul 2011 21:21:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: xmpp@ietf.org References: <4E20989B.1030709@stpeter.im> <4E26C032.3090409@babelmonkeys.de> In-Reply-To: <4E26C032.3090409@babelmonkeys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis: Unicode versions 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, 21 Jul 2011 03:22:06 -0000 On 7/20/11 5:46 AM, Florian Zeitz wrote: > Am 15.07.2011 21:44, schrieb Peter Saint-Andre: >> The good thing about the post-stringprep world is that we have agility >> with regard to Unicode versions (a.k.a. "Unicode agility"). No more >> being stuck at Unicode 3.2! >> >> The bad thing is that we have Unicode agility. What if my client (or >> your server) has Unicode 5.0 but my server has Unicode 6.0? The parties >> might differ in their interpretation of certain code points, causing >> problems with authentication, stanza routing, etc. >> > First I'd like to say that I expect some guidance on this from the work > of the PRECIS WG. I'd consider a lack of that at least as bad as being > stuck with Unicode 3.2. Therefore I think part of this discussion should > probably be held over there. I'm sure it will be. > Another thing is that I think we first need to understand what the > possible problems are, before we try to avoid them. > I think we should safely be able to assume that a valid localpart stays > a valid localpart even with new Unicode versions (this should be > possible by adding entries to a list of exception. We would of course > hope/expect that this is not needed very often, if at all). The Unicode Consortium tries hard to ensure that the essential properties of code points don't change across versions, but it does happen. > What I consider more problematic is normalizaion. I don't know how > probable it is, but there might be cases where > NFC(A, Unicode5) == NFC(B, Unicode5), but > NFC(A, Unicode6) != NFC(B, Unicode6), or > NFC(A, Unicode5) != NFC(B, Unicode6), etc. Again, we need to look at specific characters (code points). I don't know of any cases where that kind of problem occurs. > And that is something we can't really fix. So we should look into > problems that this get's us into. This is possibly the same problem as > the stringprep vs. IDNA2008 discussion just in a different form. The bigger challenge with normalization is the migration from NFKC to NFC. The IDNA2003 (stringrep) to IDNA2008 (non-stringprep) transition experienced this issue, because IDNA2003 used NFKC and IDNA2008 uses NFC. The IDNA folks solved this problem by prohibiting characters with compatibility equivalents in IDNA2008. > One of the problems this would yield is that two accounts that are > different with Unicode 6 are registered on a server A. Another server B > using Unicode 5 considers both the same. I know of no cases like the one you are worried about here, at least between recent Unicode versions. There are four cases to worry about between Unicode 3.2 and Unicode 5.0/6.0, especially eszett and Greek final sigma as we've already discussed. > Now if a user on server B tries > to send to either of the two accounts on server A messages will only end > up at one of them, potentially the wrong one. This is theoretically possible, but highly unlikely as far as I know. If such cases occur in the future, both IDNA and PRECIS have something called a BackwardCompatibility list. But it has not yet been used in IDNA, see https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ > Also in this case it's not usfull for server A to know that server B > uses Unicode 5, because he still can't tell which of the two accounts B > meant to send to, at best he could warn about this situation. Warnings are better than nothing. :) > Now maybe there are situations where having this information can be > usfull, but I'd rather have them thought through before painting the > bikeshed by choosing a URI. I think that a URI will be useful when a Unicode X entity is talking to a Unicode X-1 entity, because the Unicode X entity can provide warnings or consult a BackwardCompatibility list. However, in general I think that the Unicode X server will need to use preventive measures to avoid such problems in the first place (e.g., controlling the registration of JIDs that contain code points that have compatibility issues across Unicode versions). /psa From florob@babelmonkeys.de Thu Jul 21 01:51:51 2011 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 6C51721F8ACC for ; Thu, 21 Jul 2011 01:51:51 -0700 (PDT) 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_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA8Id9+gdqTO for ; Thu, 21 Jul 2011 01:51:50 -0700 (PDT) Received: from babelmonkeys.de (unknown [IPv6:2a01:4f8:140:9341:a2b3::ab]) by ietfa.amsl.com (Postfix) with ESMTP id 76CE221F8700 for ; Thu, 21 Jul 2011 01:51:50 -0700 (PDT) Received: from xdsl-87-79-169-84.netcologne.de ([87.79.169.84] helo=[192.168.234.167]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Qjoyv-0001lM-OS for xmpp@ietf.org; Thu, 21 Jul 2011 10:51:45 +0200 Message-ID: <4E27E89C.1090808@babelmonkeys.de> Date: Thu, 21 Jul 2011 10:51:40 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <4E20989B.1030709@stpeter.im> <4E26C032.3090409@babelmonkeys.de> <4E279B53.7070100@stpeter.im> In-Reply-To: <4E279B53.7070100@stpeter.im> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 6122bis: Unicode versions 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, 21 Jul 2011 08:51:51 -0000 Am 21.07.2011 05:21, schrieb Peter Saint-Andre: > On 7/20/11 5:46 AM, Florian Zeitz wrote: >> Another thing is that I think we first need to understand what the >> possible problems are, before we try to avoid them. >> I think we should safely be able to assume that a valid localpart stays >> a valid localpart even with new Unicode versions (this should be >> possible by adding entries to a list of exception. We would of course >> hope/expect that this is not needed very often, if at all). > > The Unicode Consortium tries hard to ensure that the essential > properties of code points don't change across versions, but it does happen. > >> What I consider more problematic is normalizaion. I don't know how >> probable it is, but there might be cases where >> NFC(A, Unicode5) == NFC(B, Unicode5), but >> NFC(A, Unicode6) != NFC(B, Unicode6), or >> NFC(A, Unicode5) != NFC(B, Unicode6), etc. > > Again, we need to look at specific characters (code points). I don't > know of any cases where that kind of problem occurs. > That's reassuring. >> And that is something we can't really fix. So we should look into >> problems that this get's us into. This is possibly the same problem as >> the stringprep vs. IDNA2008 discussion just in a different form. > > The bigger challenge with normalization is the migration from NFKC to > NFC. The IDNA2003 (stringrep) to IDNA2008 (non-stringprep) transition > experienced this issue, because IDNA2003 used NFKC and IDNA2008 uses > NFC. The IDNA folks solved this problem by prohibiting characters with > compatibility equivalents in IDNA2008. > Right, they solved this by prohibiting compatibly decomposable characters *cough*. However I consider that issue separate from Unicode versions which this thread is about, or am I missing something? >> One of the problems this would yield is that two accounts that are >> different with Unicode 6 are registered on a server A. Another server B >> using Unicode 5 considers both the same. > > I know of no cases like the one you are worried about here, at least > between recent Unicode versions. There are four cases to worry about > between Unicode 3.2 and Unicode 5.0/6.0, especially eszett and Greek > final sigma as we've already discussed. > >> Now if a user on server B tries >> to send to either of the two accounts on server A messages will only end >> up at one of them, potentially the wrong one. > > This is theoretically possible, but highly unlikely as far as I know. If > such cases occur in the future, both IDNA and PRECIS have something > called a BackwardCompatibility list. But it has not yet been used in > IDNA, see https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/ > >> Also in this case it's not usfull for server A to know that server B >> uses Unicode 5, because he still can't tell which of the two accounts B >> meant to send to, at best he could warn about this situation. > > Warnings are better than nothing. :) > >> Now maybe there are situations where having this information can be >> usfull, but I'd rather have them thought through before painting the >> bikeshed by choosing a URI. > > I think that a URI will be useful when a Unicode X entity is talking to > a Unicode X-1 entity, because the Unicode X entity can provide warnings > or consult a BackwardCompatibility list. However, in general I think > that the Unicode X server will need to use preventive measures to avoid > such problems in the first place (e.g., controlling the registration of > JIDs that contain code points that have compatibility issues across > Unicode versions). > I'm aware of the BackwardCompatibility list, however I was under the impression that this is only used for classification/validity checking and not for normalization. Am I mistaken here? And again, we can talk about preventing "issues" all we want, but I have not yet seen a single Unicode version issue (under the premisse that mine is rather theoretical). I'd like to at least have an idea of what could go wrong. -- Florian Zeitz From Joe.Hildebrand@webex.com Thu Jul 21 09:29:02 2011 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 D7E9421F86BE; Thu, 21 Jul 2011 09:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.082 X-Spam-Level: X-Spam-Status: No, score=-104.082 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPTjcFG3MUSS; Thu, 21 Jul 2011 09:29:02 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by ietfa.amsl.com (Postfix) with SMTP id 68DA721F858C; Thu, 21 Jul 2011 09:29:02 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 09:29:01 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Jul 2011 16:29:01 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 21 Jul 2011 10:28:59 -0600 From: Joe Hildebrand To: "Martin J. =?ISO-8859-1?B?RPxyc3Q=?=" , Peter Saint-Andre Message-ID: Thread-Topic: [apps-discuss] i18n intro, Sunday 14:00-16:00 Thread-Index: AcxHw0sJitjZtEfii0GYJg2U1Dy4Bw== In-Reply-To: <4E27CF30.5050205@it.aoyama.ac.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 21 Jul 2011 16:29:01.0589 (UTC) FILETIME=[4C946450:01CC47C3] Cc: xmpp@ietf.org, apps-discuss@ietf.org Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 21 Jul 2011 16:29:03 -0000 On 7/21/11 1:03 AM, "Martin J. D=FCrst" wrote: > Slide 123: Good to see that. By the way, I seem to remember both John and me > begging you for an explanation of why Jabber wants to use NFD a few months > ago, and I'm not sure I have seen an answer. Now might be a good time (if you > already sent one, a pointer would be appreciated). Let me try. First some assumptions: - Stringprep is currently one of the performance hotspots of some XMPP servers. - XMPP does not guarantee that the original form of the address that is entered by the user or sent on the first hop is transmitted without modification to other hops in the system. - As such, many XMPP servers optimize by performing canonicalization at the edges of their system and even store the canonical version for future comparison. - If the spec is written that clients SHOULD perform canonicalization, many in our community will, particularly if they know that they will get better performance from the server. The property of NFK?D that we like is that if you have a string of codepoints that is already in NFK?D, you can check that the string is in th= e correct normalization form without having to allocate memory. With NFK?C, you'll have to decompose (allocating memory), recompose (at some finite CPU cost), then recompose (possibly allocating *again*) just to check if you have already done the normalization. For the K portion, I have found John's argument compelling that codepoints with compatibility decompositions should just be prohibited in our localparts. In our resourceparts, I'm of the opinion that we don't need to compatibility map -- it's fine for all of those codepoints to stay distinct= . The idea is that clients SHOULD normalize, servers double-check inputs from non-trusted sources (like clients and other servers), then always store and forward the normalized version. --=20 Joe Hildebrand From derhoermi@gmx.net Thu Jul 21 09:56:40 2011 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 2944F21F8745 for ; Thu, 21 Jul 2011 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z86by+YeN5gv for ; Thu, 21 Jul 2011 09:56:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 16C0721F85EC for ; Thu, 21 Jul 2011 09:56:36 -0700 (PDT) Received: (qmail invoked by alias); 21 Jul 2011 16:56:35 -0000 Received: from dslb-094-223-187-169.pools.arcor-ip.net (EHLO HIVE) [94.223.187.169] by mail.gmx.net (mp046) with SMTP; 21 Jul 2011 18:56:35 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+MbhRYPi2MHqepkUvc+ojR4LsbnjjORBRWxQhKlR X/GRP6jgps6aeT From: Bjoern Hoehrmann To: Joe Hildebrand Date: Thu, 21 Jul 2011 18:57:02 +0200 Message-ID: References: <4E27CF30.5050205@it.aoyama.ac.jp> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, xmpp@ietf.org Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 21 Jul 2011 16:56:40 -0000 * Joe Hildebrand wrote: >The property of NFK?D that we like is that if you have a string of >codepoints that is already in NFK?D, you can check that the string is in the >correct normalization form without having to allocate memory. With NFK?C, >you'll have to decompose (allocating memory), recompose (at some finite CPU >cost), then recompose (possibly allocating *again*) just to check if you >have already done the normalization. The set of strings that is in Normalization Form C is a regular language see , so recognizing NFC strings is just as easy as recognizing NFD strings if ignore that automata for NFC are bigger and harder to make than for NFD. It's easier to use the simple heuristic in the specification and then do what you suggest above for complicated strings, but it's not necessary. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ben@nostrum.com Thu Jul 21 13:50:47 2011 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 6209B21F8793 for ; Thu, 21 Jul 2011 13:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-1UW3dh8vvF for ; Thu, 21 Jul 2011 13:50:46 -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 BB9AC21F8572 for ; Thu, 21 Jul 2011 13:50:43 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6LKoeFW076861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Jul 2011 15:50:42 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 15:50:40 -0500 References: To: XMPP Working Group Message-Id: <8FBA40FC-D268-4C1B-880A-BAFB4FE94537@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: [xmpp] Fwd: Combining XMPP and GEOPRIV 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, 21 Jul 2011 20:50:47 -0000 Hi Everyone Due to our shortened schedule, we will need to be as efficient as we can = in getting the meeting moving, changing speakers, etc. To that end: Presenters: Please get slides to the chairs as much in advance as you = can, so we can have everything up and ready on one laptop. Minutes: Can we get one or two volunteers for minutes in advance of the = meeting? This could could several minutes of time where the chairs = usually look hopefully at the participants until someone gives in :-) = For minutes, we primarily need a transcript of issues, major discussion = points, and issue resolutions. A blow-by-blow transcript is not required = (but doesn't hurt). Jabber Scribe: Can we get one or two jabber scribes. The jabber scribe = mainly needs to enter speaker information in the chatroom, and bring any = remote-participant comments to the microphone. (Note that we can combined the minutes taker and jabber scribe roles if = the jabber scribe enters sufficient detail.) Thanks! Ben. Begin forwarded message: > From: "Richard L. Barnes" > Subject: [xmpp] Combining XMPP and GEOPRIV > Date: July 19, 2011 4:56:48 PM CDT > To: XMPP Working Group , GEOPRIV WG >=20 > Dear XMPP and GEOPRIV participants, >=20 > A brief agenda update, which should be reflected on the official = agenda soon: >=20 > In order to resolve the conflict between XMPP and GEOPRIV on Tuesday = morning of the IETF meeting, the chairs of the two groups have decided = to run their sessions in sequence instead of in parallel. The = 150-minute morning session will be divided into two 75-minute sessions. >=20 > XMPP: 09:00 - 10:15 > GEOPRIV: 10:15 - 12:30 >=20 > Both session will be held in room 206A, the room previously assigned = for the GEOPRIV session. The agendas for the individual sessions will = of course be posted on the meeting materials pages. >=20 > Sincerely, > GEOPRIV and XMPP co-chairs > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From mamille2@cisco.com Thu Jul 21 16:32:31 2011 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 2356A21F8574 for ; Thu, 21 Jul 2011 16:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVs8rWtMzp3i for ; Thu, 21 Jul 2011 16:32:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 362CA21F858C for ; Thu, 21 Jul 2011 16:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=68123; q=dns/txt; s=iport; t=1311291148; x=1312500748; h=from:subject:date:message-id:cc:to:mime-version; bh=SQo6ZNOjuzbIUSbaE+RhmIa181M6/3sSKoUwDbofqLo=; b=F3xEktGV0PYVOF7S7uqYg4L4Mb+/T1fiCA99PUttVYG2ClDan/Wv09Fc ZQmZg0Tntrem2nwmrpd49MneKBeyOtJ7tlxfx5G//Id/FTLA7ELeyXxNy By60LvTv2DhWsvo0uX+KJ/0kQjU7bUJTWOpTZX72bhmmLCxlj6t/9ZH9h A=; X-Files: ietf81.3923bis.pdf, smime.p7s : 46988, 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFW2KE6Q/khN/2dsb2JhbABTp0J3pxieG4VgXwSHVYsZkH0 X-IronPort-AV: E=Sophos;i="4.67,244,1309737600"; d="pdf'?p7s'?scan'208";a="43809671" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Jul 2011 23:32:27 +0000 Received: from dhcp-64-101-72-203.cisco.com (dhcp-64-101-72-203.cisco.com [64.101.72.203]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6LNWPmp018237; Thu, 21 Jul 2011 23:32:25 GMT From: Matt Miller Content-Type: multipart/signed; boundary=Apple-Mail-8-123998412; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 21 Jul 2011 17:32:43 -0600 Message-Id: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> To: XMPP Group , Ben Campbell Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [xmpp] E2E 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: Thu, 21 Jul 2011 23:32:31 -0000 --Apple-Mail-8-123998412 Content-Type: multipart/mixed; boundary=Apple-Mail-7-123998376 --Apple-Mail-7-123998376 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Attached is the current version of my current slides. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-7-123998376 Content-Disposition: inline; filename=ietf81.3923bis.pdf Content-Type: application/pdf; name="ietf81.3923bis.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFU8Fu2zAMvesr3mmwgVohpViWryvSYQWGYYiAHYYdOjdJ U7TeGrsY8vejFctL0q47iaCe9B4fySd8wRMIhsBk5qicx26Fr2gxu+wYTQdG17xErEHaYTugTEQp /idyoGAi2LqGFxLj6IgkPidhoEikndoO+Jgo5FN56MoazSPeB/j5IS9nzbrmOTnwnBEeMbtiLVUg rPEN2aK9zUWiUVmRo5AAWf8zZvA3k0DIMF59TuAf9ylaNb3cfke4VosQ7fq/NsfaV8QGxlavaWt2 uSpMrT2y/a9+m6iSwDbJeZeC5YTZjErbKdNucjXIQ5Q3mU02mu3rt7yWDp55bWujDl5bd/BaTls6 zZ4qvFbOx0W4ShUkvZ7fsEwoxnYeUxBra12Nyr907NPYy5ux+L6/W+XgUjOy3+fcBzCyyaCHhJiC lfh/ahlpi+WlFHy2CUvMPsgebLrTfTCwMncye6W4q9ZxLE5yJysUJ/vIZwP2owOkiWTnQgOZlmEH CjlLMKs40iaNdBbunnfd7c3+AtfPD3sYvhCpLDaH+7HxfwBRss7aCmVuZHN0cmVhbQplbmRvYmoK NSAwIG9iago0MTcKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv UmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCAxMDI0IDc4OF0K Pj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4g L0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iagoxMiAwIG9iago8 PCAvVHlwZSAvRXh0R1N0YXRlIC9BQVBMOkFBIGZhbHNlID4+CmVuZG9iagoxMyAwIG9iago8PCAv TGVuZ3RoIDE0IDAgUiAvTiAxIC9BbHRlcm5hdGUgL0RldmljZUdyYXkgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBhVJPSBRRHP7NNhKEiEGFeIh3CgmVKaysoNp2dVmVbVuV0qIYZ9+6 o7Mz05vZNcWTBF2iPHUPomN07NChm5eiwKxL1yCpIAg8dej7zezqKIRveTvf+/39ft97RG2dpu87 KUFUc0OVK6Wnbk5Ni4MfKUUd1E5YphX46WJxjLHruZK/u9fWZ9LYst7HtXb79j21lWVgIeottrcQ +iGRZgAfmZ8oZYCzwB2Wr9g+ATxYDqwa8COiAw+auTDT0Zx0pbItkVPmoigqr2I7Sa77+bnGvou1 iYP+XI9m1o69s+qq0UzUtPdEobwPrkQZz19U9mw1FKcN45xIQxop8q7V3ytMxxGRKxBKBlI1ZLmf ak6ddeB1GLtdupPj+PYQpT7JYKiJtemymR2FfQB2KsvsEPAF6PGyYg/ngXth/1tRw5PAJ2E/ZId5 1q0f9heuU+B7hD014M4UrsXx2oofXi0BQ/dUI2iMc03E09c5c6SI7zHUGZj3RjmmCzF3lqoTN4A7 YR9ZqmYKsV37ruol7nsCd9PjO9GbOQtcoBxJcrEV2RTQPAlYFH2LsEkOPD7OHlXgd6iYwBy5idzN KPce1REbZ6NSgVZ6jVfGT+O58cX4ZWwYz4B+rHbXe3z/6eMVdde2Pjz5jXrcOa69nRtVYVZxZQvd /8cyhI/ZJzmmwdOhWVhr2HbkD5rMTLAMKMR/BT6X+pITVdzV7u24RRLMUD4sbCW6S1RuKdTqPYNK rBwr2AB2cJLELFocuFNrujl4d9giem35TVey64b++vZ6+9ryHm3KqCkoE82zRGaUsVuj5N142/1m kRGfODq+572KWsn+SUUQP4U5WiryFFX0VlDWxG9nDn4btn5cP6Xn9UH9PAk9rZ/Rr+ijEb4MdEnP wnNRH6NJ8LBpIeISoIqDM9ROVGONA+Ip8fK0W2SR/Q9AGf1mCmVuZHN0cmVhbQplbmRvYmoKMTQg MCBvYmoKNzA0CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDEzIDAgUiBdCmVuZG9iagoxNSAw IG9iago8PCAvTGVuZ3RoIDE2IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVM9rE0EU/jZuqdAiCFprDrJ4kCJJWatoRdQ2/RFi awzbH7ZFkGQzSdZuNuvuJrWliOTi0SreRe2hB/+AHnrwZC9KhVpFKN6rKGKhFy3xzW5MtqXqwM5+ 8943731vdt8ADXLSNPWABOQNx1KiEWlsfEJq/IgAjqIJQTQlVdvsTiQGQYNz+Xvn2HoPgVtWw3v7 d7J3rZrStpoHhP1A4Eea2Sqw7xdxClkSAog836Epx3QI3+PY8uyPOU55eMG1Dys9xFkifEA1Lc5/ TbhTzSXTQINIOJT1cVI+nNeLlNcdB2luZsbIEL1PkKa7zO6rYqGcTvYOkL2d9H5Os94+wiHCCxmt P0a4jZ71jNU/4mHhpObEhj0cGDX0+GAVtxqp+DXCFF8QTSeiVHHZLg3xmK79VvJKgnCQOMpkYYBz WkhP10xu+LqHBX0m1xOv4ndWUeF5jxNn3tTd70XaAq8wDh0MGgyaDUhQEEUEYZiwUECGPBoxNLJy PyOrBhuTezJ1JGq7dGJEsUF7Ntw9t1Gk3Tz+KCJxlEO1CJL8Qf4qr8lP5Xn5y1yw2Fb3lK2bmrry 4DvF5Zm5Gh7X08jjc01efJXUdpNXR5aseXq8muwaP+xXlzHmgjWPxHOw+/EtX5XMlymMFMXjVfPq S4R1WjE3359sfzs94i7PLrXWc62JizdWm5dn/WpI++6qvJPmVflPXvXx/GfNxGPiKTEmdornIYmX xS7xkthLqwviYG3HCJ2VhinSbZH6JNVgYJq89S9dP1t4vUZ/DPVRlBnM0lSJ93/CKmQ0nbkOb/qP 28f8F+T3iuefKAIvbODImbptU3HvEKFlpW5zrgIXv9F98LZua6N+OPwEWDyrFq1SNZ8gvAEcdod6 HugpmNOWls05Uocsn5O66cpiUsxQ20NSUtcl12VLFrOZVWLpdtiZ0x1uHKE5QvfEp0plk/qv8RGw /bBS+fmsUtl+ThrWgZf6b8C8/UUKZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iago3MzcKZW5kb2Jq CjggMCBvYmoKWyAvSUNDQmFzZWQgMTUgMCBSIF0KZW5kb2JqCjE4IDAgb2JqCjw8IC9MZW5ndGgg MTkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ1Uy27bMBC88yvmSAEJzaXe 1xpOgVyKwgJyKHpIHTtxEDuJZRXNB/W3+i1dklpVtuuLT6TXy93Z0ey84yveYeEsyLoMZVFht8Qd tphMW8KiBaFdnGasYE2Btc9yIUvR2UzfgqxFXhaouAnVbtQkPLfcwYZGplBrnx8C11yUH3pUiw0+ NaiyGOeTCmuoygqQy9FsMLkhw1OgWeEb9LTbJahNpTSfPJ1ebvdIGLSDnu/v+9u+axN8R3OLWcNM CFDiBx5oltsxUMVsjIHy+EdA89L2QEsylYtY49XVoLI05MqM0aoRWv07QfMcEZytl/XF+OQCVJTD yEx8HHn2a53gOkzIU4VzP0S2j31ISHjof7/256LbMEVtosJDyXpiptLcZNA/exrlnxfpxRnE/L5J z6VUNomKaIyk8uUf2WdH/R91LuePzdSpww99AXUus6fUjREOmOva1NA8LwvMy+YugZcctKhnIJdp 7kc9oVno3R7UYQz6i7Aymx+3V/pyplKXisjiSkR9XMBUSunAVNgrxXt1DHUUEVq2IgCRyh/RXrfr KVP6LFHdsKYiKKFws5SCb36nM/91Xnu9/hjkuNzIuwMOg82ZFPMpL+WR280x+cxe99iqA89zSEHe X3JvAqvgDoexsU0G9xpp2oEqFU3LGmvZwZoFKylaAp85iBfX25YT29LNU7drH+4/rnDbvXzA0RVD JfL2oKJB/QXeQTBDCmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKNTQ0CmVuZG9iagoxNyAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjAgMCBSIC9Db250ZW50 cyAxOCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoyMCAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAw IFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAv RjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa2Ty07DMBBF9/mKu7Ql6nqc9wqJp8QKRCQWiAWE lBZogaYV9IP4TyaO7T6gO1aOxuOZOydzP3CFD2gYDdImQZ4VmDe4wQzD45ZQtyC09e+MEbTKMOmy jM2KaG9m14K0RppnKLgJlWajiX2uuYO2jVQWTbp8GxhwUX7YqaqnOKpQJH2cTxMXqszTDGRSVFMM z0jxFKhGuIW4lCzQRGIuYRJVQrzZAMTDq8SAryCaaetihxJ3qC5wWjEOr5aYSac2STWrjRySX2qZ wY7aNNdObU6qML3g/tOUMBQrMnkSbUsW3xLVc69gb73EFeMzZwA6DnMz/X7uk+beDRXmnPiBZ0/u Cu789DchZTGGjCydqUSpCohlqLMIWe8h1vhSzezRFR34ou9vrlR4N1sw8TXpvXP+ya3I/osbr6GH H7idftVjTy5wWgvfJffCa2XxNBKUKoJYtTJaj2ZdpWJcH/Pv3zHXNYbnbK2ndttiBjEo4XVOu3Ub 2T3cim250pplA6ABeY9opTUbpqrZGc5FBimI+pUz3iWiGi/n7eP96gAXy9cVb+YBSyVaL+LVD8C7 4asKZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iago0MzIKZW5kb2JqCjIyIDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNSAwIFIgL0NvbnRlbnRzIDIzIDAgUiAv TWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0 R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAg UiA+PiA+PgplbmRvYmoKMjggMCBvYmoKPDwgL0xlbmd0aCAyOSAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBrVTLbhsxDLzrK+YoAfFa1D59TZoWTU+BF+ghyCFdrxMXsevso4U/ qP9Zrna5cfxo0aInCRRFcobkvOAWL7BwFmRdhDTJUJX4jA2mVzWhqEGoi2OPJWyQYNV5Oe+l6Kxn l4IsZ+AsGSeJYruXxH+3nMH6REGiVp2/N0w4KH+MU4tijcscKQWZ65/6q5uB0jQgl0bI15i+p4AT IV9C/zQq/4rr3EM8Ey8agvHJAShJD4LcQX8ySGwQKl0aUBwQ9A6G0TvodyuDib/Vg6WpRtOXthnv 34bnTf9T6QcxLIbL+ZAFfyYL/d10XdJlxTndLMi4DoN7ld/8AeIpylxsT1CmmDL8JWUusseUXW+K yiipcnuWB+ilgYciBFXCw3p4aJ97ipV+jbIdbEyGuJcbIXIiLdlKzLELm4bb9I+MhS78T4yFFB4z Nl8xX36SHmUyZESaljvuOy9DJqB/CNQRYfM09d+VPvUmhLSNRPCNGsfpVKOMuoeMmOxxnCZ+j2nm frfHrA4He8zqovo9zqJ+ifl0SRhEEfH2ufiYmMsRmxAjtX9cGOUZK4WprrtviuW1xfyKMx3I2xzT Dyxuj/WryCkWOYcQFCW85R2spdeNt7Z9XfRytQfQgbJepbgsa1lI84IxDTrmEINYlzqJcqNE5U9t VS8edhe4aZ93cHTBpRKNW6hufwHdwzISCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKNTIxCmVu ZG9iagoyNyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzAg MCBSIC9Db250ZW50cyAyOCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoz MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAv RjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9MZW5ndGgg MzQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AX1Ty27bMBC88yvmSAIxzaX1 PDZuWiCnFhbQAk0PhiInLholsaoC/qD+Z5evVpaTnCiQo9md3ZlnfMYzDKwBGZuhLCocOnxBj+V6 ILQDCEN7jtjB6AJ7h7IeJehVpCtBxiAvC1RchGo7KeJ/N1zB+EK6EHuH9xcLJuUfXVftAy4bVFm4 57Owuq4rk4NsjuYByw+kWQWaHb5Bvt8rLIy2Qg6KW7WQ7aNiMsjfyqmV3SEiIPu7CEE8N+PTE6P9 bwfmcfhfSnxHc42rhkeWFBG/OEVZbt5SxHOaKcpLI4KiknRlg6jwaWtYWmmyZTaTJf8oND9CB6/y ZZGMTyawZjUj4dmsnaRM15DvPiXFSfqNTHP7epUeF+EK0hDlN0rh/yDO24iLelFWVXhZ4nRbb8uK fDNZ7KREwsYLK0+Lfml53e1sxf+Wv0vKt0r4hffBH8d0zwbwfkn0yRije/BTbLuE3cYqff8Y2ca+ Pavd2W46Q59AvcJmzTbgUtMgbrD8OJC4G07jaLECZQUod7bbeT+e3k0T7IM12ZQFVdF9RhvD4Wpa TlFMnAVHimfqEmVTomRzPx6G2+3xAtfjzyM79IJbJXKGFCESfwEtB+pECmVuZHN0cmVhbQplbmRv YmoKMzQgMCBvYmoKNDYwCmVuZG9iagozMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMg MCBSIC9SZXNvdXJjZXMgMzUgMCBSIC9Db250ZW50cyAzMyAwIFIgL01lZGlhQm94ClswIDAgMTAy NCA3ODhdID4+CmVuZG9iagozNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEy IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjM4 IDAgb2JqCjw8IC9MZW5ndGggMzkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 AX1UTW/bMAy961e8owQ0CiXbsoPe+rEB3WVFDXTAukPmJm22Jl3jZEB+0P7W9ldGy5aSuElOIiSK 5Hvk4xtu8QaCJRiyKXJXYDnBPRYYXtYGVQ2DunrvMQVph1njZb2XMEc9mxSGCFnuUHASM7I7Sfx3 4gzkE2knZo2/vxhwUP7YVFXNcVGiSNt7Po0lnToasZGhnGP4wWhGgXKKr5BXM4UBaStkrbhUC7la dleQ39eraC+eund05ycFRzqBnCiYTBvIDYf4hvJGXJdMV0DD+T2aNKNTaJijHposJ9GiyVKd2xZQ a1pGk3O1Lsl7kOQfhfIHfAVH4yVdMD5drkepyxIYZ3uhmJ3PHdbrYATwD1KJhjbIL/Ft0DIJScYl D6rl4lglXZ8OIbNp6pGJ/WadRtbFO4TMJq4XipEtXjtoj905CdCmCiNdQAaHZXgYe08hXwLOaASP nwrW/90bCU/TOQ8JUTMlwflVCf+yiJnjrK0m8+D1axLzH4geORZ+2na1wNNzguPEFA3HRa/lzLE4 Pj0nOE4M9UIxx9XzOGAM4olYI/9bhf2tWoZZgpGJ0ITFuRLv+Gv1Ov0XvbdULrkTxNLcEXPsye9Q FfevkWs7on6/sZzvLpnF3pq7w/AjL7mnen/ZWbBsUsfqF7wLp17x27sdsfv96NfWjiQtTNhWpIl4 dZUV76iuhxYZjGnn1oZ9Jcvn9bJ+HG/OcLN+2cCaMy7VmK3kb/8DtjYxXQplbmRzdHJlYW0KZW5k b2JqCjM5IDAgb2JqCjU1NwplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDQwIDAgUiAvQ29udGVudHMgMzggMCBSIC9NZWRpYUJveApbMCAwIDEw MjQgNzg4XSA+PgplbmRvYmoKNDAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAx MiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iago0 MyAwIG9iago8PCAvTGVuZ3RoIDQ0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGtU8tOwzAQvPsr5phK1N118+qVCpC4oRpxQBxQaKGoFGiCUPkf/pN1bCelpTdOdjb7mBnvvOMK 7yAYApNJUeQlNnPcYI3RtGZUNRh1dZixAOkcS5dl2izFRzPdCCZCVuQoZQhPzM6QtpxkArWDdK6W Lr8NDKWpFDpU1QtOLcrUx+U0lOpMTjYZ7AtG56yFBOwCt0jO1tVmgKGZ6FIl27dmKR+kDZL140CQ y0XHyO7lDvYSZ1ZEiZhZlHGY04wEswrCHGAWJfYwZwUFzAXr0njY/momMDzWbIpU/UaefA9gnz2C o/3S0EzOwskw7ujLG3j6s+Y+0GxVICQNQuAz8u4kaZ7ivzrkSLXyan1Jn16Uo5D+pFjm/0VR9ibq 1FOcbzoGkezqgNvXPHJrXgO5GLi25wPll2IY68r4MyZXzbxTrlOnH+y2Kcij/M6QHmM2ldfec9QM owvx02P921cGY3CagzPniEW7dn1M7VmxdcjOIxhwNAZpInGJrcQPwToGGVg2wnnDaPLKJfbpY1M/ 3G9PcPmx2soinghU5n7vrn4ArCbfmAplbmRzdHJlYW0KZW5kb2JqCjQ0IDAgb2JqCjQyMQplbmRv YmoKNDIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDQ1IDAg UiAvQ29udGVudHMgNDMgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKNDUg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAg UiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVctu2zAQvPMr5kgBDkPSlCwV yCVuEiC5NLCAHpIcUlWOXceqYzuH9H/6n11RWonxo2iLnkSQqyVndnb2Bbd4gYbVMNo6jJIU6xKf UeF0vDEoNjDYFPsRU2iVYF5HWR8lzNHI+gqjNeJRgpQuMZkNLvG/a7pB+4tUIuZ1vN84oaT0Y/2q YonzHKlr9ulrtFPOuSGMjZEvcXppFKFAPsUdpIpwopUVvOh2ICfbeXMI+by3QETALORFVazp0GYq hXxb0S+izgdZPbUR7Q1BYtp5QH6Ni5xYZdDGGg/axToELYjZEDRRuQM6HhH9HvTIqNQ2uJulzZAZ ZeyI0OdLESCXPyPk35oXHM3n2mT0HTmkRFnLHtWwYe+KeSmrcv3YAt6WTM6Xjrfv7Vmx4LOiJVfI 1axc8+4iQkNlGcHEyhCnIVlHn3oIukmcxy742U3R/wG6id0+9rIqPnaQecE4zs54dX6Ag/E77PeS WTzE102ERKshZMhIqmtqBhGyTGWQiEQvqKMcvS+n1bUmdrph48sk5JbxVD94Ndmu7yN+KIH7gwsP FcWmyX8qiiWXYACdIC9JNq6mhAXXKatkIMWMS0ONS34mS5Yi5Kpr37Lactjqta9L5wgFnx5Q7IeG HeH7+2g59thJHIZx5tnpgHWSFX/TrUZnGLpsJwu5HWn2JhK7errrUD0wqk6+n9rGXXQxgeOJ2vF6 +RJRB9QaZA8E+1v9iMbPAsF6RFm6j6gvDVe8WASPEK2J1NLtFetnGfXUZExuuTPSJji9ooH2tHk/ 2CxogLiETEnQ3Jt62+73Asf2s9CPqKDyFoYnk1Za05jKC5pHjVfTN4YxjU1Znk0yn72uN18f3wa4 fn1+gzUDeqoxvW/f/gK8HJkrCmVuZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoKNjY2CmVuZG9iago0 NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNTAgMCBSIC9D b250ZW50cyA0OCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iago1MCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9D czIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5 IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjU0IDAgb2JqCjw8IC9MZW5ndGggNTUgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVUTW/bMAy961e83WQsVSTFHzFQ9LCu G9BdVtTADsMOges0WRsvjV0M2f/Z/xwlmbabLMCKnSxTFMn3SL4n3OAJGlbDaBsjS+fYVfiCGtPL xqBsYNCUxx5LaJVi7bys9xLmpKdLYbRGkqWYUxKT21ES/1xTBu0TqVSsnb83nFFQeuiqKjd4V2Ae Bzt9TZ6ruU4yGJug2GD6wShCgWKJr5AqwplWVvCht0Be1eWObi09h9xv2+ouIjAW8k2EbyiucVUQ K1y0IWpc0XGixcDMUdFExUHRSaa7ojOj5jbUHY42h0msMjaLxcvK5e8IxfdQwcl4cReMvhnxQB8O Qk0I8D93kBbdt3zg031nqcCHuvwUIdVqBllFVJgyREsTCc/JJALxnEOO3N9zrJYPfLkOrEPW7Y8u fLgSsmRD3b8avCtqyED9SeBHRKYxrKWC/59Io3NYMwxSz2TT4eirrn8dov7JqHtA7YoZ2Sw6Itty 1V/X3AT2ehiueBj56i0f2v2Weha64oz/wNdoUDw+oosnBUaESWEwlNdoSE5PDaHBlxXD5+9Q6IAh 1HTQcUhu+K5/w096Q83ZHwMe4VfvVf2fxZnv/wiZ2wFaJPGaRXL8zGbZQRQSkvPKVtOO9gvuxaiX VLkTmoE59jk9FUJuGfdf9pI7wHH4n5+4Qex7L7x80+reXpLAHKj4LaYfScPvm5dabjEj0Uhp050K L73SDbaRyHn596o86oiFYTHWSmtS5qIkCe7k2iKBIRFycmyVDlski9Xzrrlb7Ce4fn7c055NqFRj Bqm7+QMILl2vCmVuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKNjA0CmVuZG9iago1MiAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUzIDAgUiAvUmVzb3VyY2VzIDU2IDAgUiAvQ29udGVudHMg NTQgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKNTYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBS ID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0Yy LjAgMTEgMCBSID4+ID4+CmVuZG9iago1OSAwIG9iago8PCAvTGVuZ3RoIDYwIDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAF9VMtu2zAQvPMr5kgCNk3Seh5yafoAkkuDCMih6SFV 5Nh17DqSE8Af1P/skhQpW056ErFc7s7OzugFN3iBglHQyiTIswJtgztsMbvsNOoOGl19nrGAkhlW Nsu4LKY/zLQttFJI8wwFNdGlOWrinivqoFwjmbGVzXeBKRWlhxZVvcGnCkXi4/TVZSLLLC2gTYpq g9lXLWkKVAv8AP/c1K1gU1PKAvyw268Epkoa8O2TIOh0kCFyfPiJ6gpfKmIlgNZEjQWdpIoNzJyB JipGoNNc9aBzLQvjcfujKWH0XGqTJ+wUOf8rUP32CD6sl/TF6JsntLp5HJ+W4Mf/3g8Zx67X6EPN tr4WyJScgzcCOpWaGAq3++WDy2N8H0IbHwHf18um66uEy1ZY7fDmObAZS76FZ1uqxBzla0p2C4lJ h13Iikip4rCFcw6YF8K7nBaZ4zTS4dXwf077eiNOSamniyFJ/Yoz/ulJqNdjJtnA5EWgKOxiHUd0 4sQgznse2Nu1MentWrDxlgQKZdc1EShLWYKHHu8v9V5ELplXtN367SVpcWT4W8y+kd2fulPbG8yh k4xEYg27cKYYYkd+cH8KZ+CjjRno4FsllSITVzW5tXe2QQpNerXONVJ56fJq+dp2jw+HCa5enw9k kwlB1Xpwxc0/ag8AwwplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjUwMgplbmRvYmoKNTggMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MyAwIFIgL1Jlc291cmNlcyA2MSAwIFIgL0NvbnRl bnRzIDU5IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjYxIDAgb2JqCjw8 IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4 IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBS IC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKNjQgMCBvYmoKPDwgL0xlbmd0aCA2NSAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVRNb9swDL3rV7yjDKSKqPhLh12atgO6UxEP O6w7ZK7Tpm3S1HYP2f/Z/xxtSY77BQQ7iaAoUu89ks+4wjM0jAZpEyNLc9QVfmCL6bwhlA0ITfk+ YgWtUqy7KNNHCfo0sitBWiPJUuRchKwZFemfa66g+0IqFesuvneccFJ+2P2q3OC0QB47P582VrlJ KQOZBMUG0wtSjALFCj8hVYQTrYwIxuCBXLRrdwn5+M5AxMAM5FlV1nxprMoh9zt+Irp8kNtbH+Er jBKz5xeKS5wXzGoATUxtBzpO9Bi0YGbHoJnKN6CTTHvQGTFSh9uZxoJyq8hkMSMXI+Tyb4Ti3v3g 03yxT8YnJ6DMDvSxiI6+xoNsl97Y/gnWoq0DSV+CcToQ+eTjy4f5QNnurqqvZaD69wex3yKkWs0g qwiUKGLKI+S6MyYRrFVWSK51YPdIbMbkA7ahNaptebaMRK/mgO86Oir9R1LMiHopxOsm/A8pZpr5 9518jBSB/l3Qpg66VTdeBxci5Iq72cTKQgaFNuH19+IiaJMHXwgq26oNPpdbyLYe5qcbhoMo/Sph FRdzbtY3G2WB6VfeJ7fNYa8I3isGM1CcsujdcKz6qXntG6+ifkOMpDc8Bm5GWE2teUsUJa8DNyp8 JiBPqAmrQRZ3L3Vzs9xPcPnyuIehCX+VaBgbcfUP52ATkwplbmRzdHJlYW0KZW5kb2JqCjY1IDAg b2JqCjUxOQplbmRvYmoKNjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MyAwIFIgL1Jl c291cmNlcyA2NiAwIFIgL0NvbnRlbnRzIDY0IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0g Pj4KZW5kb2JqCjY2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+ IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKNjkgMCBvYmoK PDwgL0xlbmd0aCA3MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBlVTLbtsw ELzzK6Y3Ck1oLq3noSjQ9AHkFkRoD0UOjizHbmM3sWQUvvRv+kPtD3VFaWnZQYr2RGK53J0ZLucR V3iEhbMg62JkaY5tjU/YYHLREKoGhKZ6mrGANSlWXZbzWYqezexakLVIshQ5N6HCjZr465Y7WN/I pGrV5fvAORflix2qao03JfK4j/NKhTWUZwnIJSjXmLwnwyxQLvAZ2kQ4t8Yp2YQI9Nu62vKpK0wO vX9o63nEZBz0iwg3KC/xrmRVBDSxNB3oOLHqoMwT0CzFCegkswPojEzuetz91hWgvDDkslgdI9c/ I5RfegTP1ouHYrxmrENWBPr8CD39jxFSlgd6NnC77/WAXslGWEtGW2PI/S7ahdx2KWfNkBOO7obA JtTZsbosmq6DnMqLOX7Rv4vjUufFCbz6Z2Vx1H+K4xJ3UoRn45eHrPTXQGIjYgjNl7Jp9w9BlxAU qnyLmOg8Un5+hLdoJOuhjYgl1X+8kl31TXRsZ0O5w7V6+3s45fTDiP7jgEwtnUwZa7AO1QXTshUs t4Exn3UEBVu/Kibcfxi5UG8kYxeqvR4j9SZjpri+4CEYeU33o64x+cBOc9ccO47DFBSnoKTzioX/ j8exsUlZxSY10sPxBxt+nzXWsn+UFRvFMIIO7Br8VTrTcGIaulzuts18tj/D5e5+D0dnDJXoMHNX fwCOsxeeCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoKNTI3CmVuZG9iago2OCAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDUzIDAgUiAvUmVzb3VyY2VzIDcxIDAgUiAvQ29udGVudHMgNjkg MCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKNzEgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+ IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAg MTEgMCBSID4+ID4+CmVuZG9iago3NCAwIG9iago8PCAvTGVuZ3RoIDc1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtU8tuwjAQvPsr5phIYLzOk2tRqcQN4aqHqgeUhkcFVCRB FfxP/7ObxIZQyq2nWJvx7sx4Z48p9lDQCqR0iCROUeR4wQ6DUUnIShDK7BaxgJIx1jVKNyhBd5H1 CFIKURIj5SE01J0hzXXFE1QzSMZiXeObQp+b8sWaVbbFg0EatnX+6jiVKXckHcFsMRiTZBEwC7zC m6199JXUwlv6zFTD29kKn1xJthh43cMbzASPhn1xtInNqWmHkRIXb25osxm/aEeJsrQTkqlumbdH PYSmQJJOQnFN3vv2YT5aBnf7hbYZfxN2QgVnB/gZrAPV3CovWCZL8CrYwpfTfbakWrl/pcXwbdH6 duI+F1PuUvpTYhr/l0R+aOfTWaLjmhdnIU7z5kbiKXcSq0+rEVbisxk7eOpADpNVecVzLgY0eZEB ZiN+z05s6tWYYfDEoVmW1+HRCEAhb2pUr/2iWazrWjdvSnDeOjZrkNt+JZXiKJiMl97mQyMC8ZvX AdAuAJ5ZHYryfX7sYXLYHHnVekyVyBdus6Y/4Z7ZJAplbmRzdHJlYW0KZW5kb2JqCjc1IDAgb2Jq CjQwOQplbmRvYmoKNzMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MyAwIFIgL1Jlc291 cmNlcyA3NiAwIFIgL0NvbnRlbnRzIDc0IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4K ZW5kb2JqCjc2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9G b250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKNzkgMCBvYmoKPDwg L0xlbmd0aCA4MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVTLbtswELzz K+ZIAg7Npd6HXGq0BdJLAwvooekhcezYbaImklXA/Z/+Z1eUSNCNjQI5kVotd3ZmHy+4xgsMrAEZ m6LIS7RrfEGD+aIjrDoQutVrjw2MzrEbvKzzEnTWc4AgY5AVOUoGocpGIO65YQTjgHQudoO/M1xw UH44ZLV6wrsaZTra+aS81EWSJyCboX7C/ANpZoF6g6+QWuHCaCv8JVggl/vd+BPy8dUFiolZdgo+ D5Ol2SkxhIRsvGkCiWKz5RvqK7yvWVjPm1jdgXeamZi3YHFj3qzmP7yzwky8C9KlHamPV1vBUqLJ FimTFxF5+Ueh/j5mcDZeOgXjkwNYkwQFuY6jgovtz4m5P7vpe+1Fem6DSr8+KeRGJ5BrBco0QR6g hNNro1DpEtLHacP7/i5UIETyKNv1/YQ3ugv53N+dQIkVP8v3pH5l7vQTx83zFv24sX2QoJ/nEYj5 rmluJ177vlXD5Mkg6KVX5rNzEfJHeH2iIW+kb9//FEKhNJqEnHEhKl1Behif496n1Pz2t+W+vVGx tm5RcIGXC+7DaF8I3hdLzD/ytnjojreGBU9nmnM/DH2/cQNxbIsXjRG8aKIKWpAfe6ON4R1Qr3jY xyngMwNxrw6Db/3gy3rbt9397WGGq/7xwCMy41SJlPATcf0Xou0KSQplbmRzdHJlYW0KZW5kb2Jq CjgwIDAgb2JqCjUwNwplbmRvYmoKNzggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MyAw IFIgL1Jlc291cmNlcyA4MSAwIFIgL0NvbnRlbnRzIDc5IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0 IDc4OF0gPj4KZW5kb2JqCjgxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIg MCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKODQg MCBvYmoKPDwgL0xlbmd0aCA4NSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB jVVNb9swDL3rV7zdZKxVJMWfwLDDim1Ad1kRAz0MO3Su02Rt3DRxMGT/Z/9zlGzKidMWPRgSZIp8 fI+knnCFJ2hYDaNtjCzNsalxjQaTi61BtYXBtjq1mEOrFEtnZb2VMC9auhBGayRZipyCmMIeBPHX NUXQPpBKxdLZ+4NzckoXHapqhU8l8rg7p9WmsdJFlsHYBOUKky9GURYo5/gBqSKca2UFb8IJ5GzZ /YO8iygLC9nUt/3uXYSfKC/xuSRiGLchdhzuONFiIOcEN7Exwp1kusedGZXbDnq3tQXhzhR9sTgG L/9FKH93CF70F/fOaM2IUJMFBkiHjoHvfUo3/Vrd847TrtH/2vbriBghG77S7jaRKxJZE3duPYtQ FKqAHPto+Urzl3ezdhMJ0lGZZ+6td7++RUi1mnrnJnFWe/YaEDVzCqhyyMdIeM3IYlDqrTylaeDJ V4qgShlCtI89Dxy94oMmZDVY18TIAQLi3ZVwX7GvKJ9S6caFV/4YDILywlfe8/4OlDe6gJ0WIy+U EutJqDuyBi04tT/cAyGhdsH/VixcWy3C7+ZuIN4LcD/84u5hB+950+7XocjcYeBLvEUxn1+en+bH +Ciu0UJyeC5RTp/XAShVfoDwTLOKbsicNCtJNqVD16wjMEGybliMJOv9jSSbptSi43l1wPQDS8N5 dWwK+aG29aQv0Y9M8WtCrpmoce8LGSYe++FgfMVV/MCVfyWoRWcXlOLxYyFmmHylp+Jue/xkWExh 4hQmccN+7gk6Pjt8ZdzwPywKC8MzXyut6QEoK5qYPcEWCQ29jkXLU1+Wi91me3uzP8Pl7mEPa84I qjGR4HF69R/pf3HmCmVuZHN0cmVhbQplbmRvYmoKODUgMCBvYmoKNjQxCmVuZG9iago4MyAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUzIDAgUiAvUmVzb3VyY2VzIDg2IDAgUiAvQ29udGVu dHMgODQgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKODYgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDgg MCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIg L0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iago4OSAwIG9iago8PCAvTGVuZ3RoIDkwIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVk81y0zAUhfd6irOUZlLlXsW/WzrATNnQiYcu WhYljZsADamdLMz78J5cyZbjUDoMK9+Rr+7Pp3OecY1nEByBySXIswLNGjfYYX7ZMlYtGO3qZUYN shm2PsuFLMWvZvoWTIQ0z1BIEy7dpEm4TtKBQiObqa3PDwcXUlQu+qlWT3hToUj6c/m6hKxzWQZ2 KaonzN+xlS1Q1biF/mT8TctKr5utwYXkQtfdGO4ejWwgZzb+nAafUV3hbSVw4uwshPzsSUrqBOjF 7ELkj9nTnIbZc7aF68fvQ1fC8cKyyxN1voD+ZVB97Sd4tV4yFJNvLjhoMVKQt+gp3Iz7HjYYFr73 ZKD3+8YIQ1tC/xj+7E+kJCnQOaxhVIj2xy8fDDKyC+i1lEgtQ3ex6NhnF082scTuwWDgqQLN6cv+ g06RBTrjYv3zCh31v3REeueIRSMfw5JKfxunj6qRFU8s6u5OR5H8nYJBIVKDnhlVlp5ohNBGjCOM nzFaHpo7M5IZlObpLi8F0MSPXm5LzN+LGx/bc1c6LMCJOCD1fqqDWM/PpkYmJUaeqMmBo63IEonH qpWYaXgehxQsOvLGctFYutocm/bhvpvh6vi9E/nOZFTm03tc/wZiV+ywCmVuZHN0cmVhbQplbmRv YmoKOTAgMCBvYmoKNDcxCmVuZG9iago4OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUz IDAgUiAvUmVzb3VyY2VzIDkxIDAgUiAvQ29udGVudHMgODkgMCBSIC9NZWRpYUJveApbMCAwIDEw MjQgNzg4XSA+PgplbmRvYmoKOTEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAx MiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iago5 NSAwIG9iago8PCAvTGVuZ3RoIDk2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGtVE1z0zAQvetXPG7y0CrS+vvEDB3KTE8wdeHAcAiu0wYa09ruMOH/8Lf4Lawtr+MkhBMnyetd 7XtPq/eE93iCBVk4SxHSJENT4SNqLC5ah7KFQ1seZ6xgTYJ1n0VDlnInM/sWzlrEaYKMm7icZk2G cssd7NDIJGrd5w+Bcz6UC3tU5QavC2SRj/NKUWjCKMzgKEaxweLSGWaBYoVP0CbAuTWkZDNFoD8E /aHGQVfN2qdB/65uA6ZE0C8CfEZxhTcFayPQHQvUQ49iq3b6HEFnQQ6gx6kdoafOZOTR+y3lcFlu HKWR2sevfwUovnoEJ8+LxsN4TVnTNJ9E4KvwIjwuR05NO24qjJub4lKoZxL7Pv4ru6rzMaWlsNtJ Vd+NeVK3CpCbDFrqG/kxFS8DNWhb/2REO3VPcvubVpTQf9KKYjrW6l0AivuhEBYCXtZpVL489Hxj 6K3w3Hidle7Ke4l9m/JrmSz59VI23fZxupApKGdxlbPQUtwwPv6sBI6suzaza/mXxMq/pP3xCS3P zOEb+iETMvXoJnqll0npupMhm7Lqqnk1v+bBYkyI6wse/wOnucbiLfvMXav2/IYQwkUJXNw7xWp4 h/uxuUUNzjEbJuKHNdK0xlp2j6JkmxgthRDDjXRJLEMX989Ne7vcnuHq+WELcmcM1bn+ISpvBX8A v08XZAplbmRzdHJlYW0KZW5kb2JqCjk2IDAgb2JqCjUxNwplbmRvYmoKOTMgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA5NCAwIFIgL1Jlc291cmNlcyA5NyAwIFIgL0NvbnRlbnRzIDk1IDAg UiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjk3IDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAv RXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDEx IDAgUiA+PiA+PgplbmRvYmoKMTAwIDAgb2JqCjw8IC9MZW5ndGggMTAxIDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtlE1vm0AQhu/7K97jIsV4Z/m+NkorReohMlIPVQ8RwbFb mxIDav2D+j87LLtg/NFcemK0DO/MPOy8b3jCGxS0AikdIolTHEp8QYXlfUMoGhCa4jJjDeXH2PZZ 2mQJupnZlyClECUxUi5CmT4pYj5XXEGZQn4stn2+OViwKH/Yd1Xs8SFHGg7n/KQs9pMIpCPkeyw/ ks8zIF/jK+Rnj9vTkFtPLEzwe+FhiKoxcknPNrktNh6+IX/EQ85YXNfEbPquw0iJCc1F18zirOso UbbrhPxUD40Poc5ASeKTTkIxb17+8ZB/Hzq4qRdaMX4mDCJORgL8FwYCq60b+NWOV8EGbt7qxR64 Fw9VceCvdOankMe6hScMvF9OatRsN2M4yjZn8vvS6dZDRSGLH662a6o8JX5z3mv8dKT+Ez8dqiv8 urr+aScyUBRk60Z0g+09GFbdzhFqRy71zt29kQPr8F2SpZNx+l3/IvQzyKJ/N13BSyBiWINrQAId GCDjLMM2/PtCWb35hQooOBPhlVq9D0TId4DYFRyBlNXEa4qYgZgYGH/yA6zueYHObGqF5Sc2qddm blYaASiMQRHbjFibTZ6dzfzN2M4JaQ1ybqN8pdh68oJdxvqRBlsODUurnePIfNMdmpfn4x0eu90R mu64VaJplZ/+An0JJ2EKZW5kc3RyZWFtCmVuZG9iagoxMDEgMCBvYmoKNTA2CmVuZG9iago5OSAw IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDk0IDAgUiAvUmVzb3VyY2VzIDEwMiAwIFIgL0Nv bnRlbnRzIDEwMCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoxMDIgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAv Q3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAg OSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iagoxMDUgMCBvYmoKPDwgL0xlbmd0aCAxMDYg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1UwXKbMBC96yveEWZiWRIg4FpP 2pmckjEzPXR6SAhu3QbiGNwZ93/6n10kFoPd+NQTQrsrvX16+97wgDcoGAWtTIzUZthX+IwGy1Wr UbbQaMvLjA2UtNj2WcZlCf1uZn+FVgpJapHRJTo3k0tcuaIblLtIWrHt893Ggg6lwh5VWeNDgSz2 +/TViZVRriy0SVDUWH7UkrpAscEXBKvHEFEiYxH8Cvvugoo2lDQIOgyL23rXvQ7rfYivKO5wWxAh Dq+ma42DG+epgyscJxdwiYQpXKpLbD7ATbXMjEfslyYnMEpqk8Zijjn4E6L44QG8e148HEbftOdR jY0T/b7xNbdUV9xotz+0581vQywcHQ1n3TMt96FwEQ6MqfXuhavGvep5ytwlcOHf7Z9EpJEjYuzB P951Iobz5kQYG50dQgrgfg5Pl6jLhW9EBD9JHbnMSB8hKUpqBEfum4ncMXkcqDlCqnHS8gER8D8X cN6hD8QyR1COjzIy2HRVwwXD5km018m9orIotv9JZVFkR3JPKut4nJrfvGJ6Tp1tQjhumQfOaF4H iY2zWHLKRGNVV9HL5TKZvMluZJILuqrsSIRiPr5KRlivaPLOjG2N5SeytW/t3N4MIuiYrCShSRcb 5wCzvZkjOqOaSN1Asz8pqRSZVVGSKw0OZpBAaz/thh0qKL4f9u3z4/EGd4eXI4y+Iahanzzg4S+C ijGTCmVuZHN0cmVhbQplbmRvYmoKMTA2IDAgb2JqCjUzOAplbmRvYmoKMTA0IDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgOTQgMCBSIC9SZXNvdXJjZXMgMTA3IDAgUiAvQ29udGVudHMgMTA1 IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjEwNyAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIg Pj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIu MCAxMSAwIFIgPj4gPj4KZW5kb2JqCjExMCAwIG9iago8PCAvTGVuZ3RoIDExMSAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrZTLjhMxEEX3/oq7dEszTlX1MyskwkMzLGCUllgg FkNPZwiQZqY7kcgH8Vt8C9UPRw4hLEasbNll1z3XrnrEDR5BEAKTJMizAm2N92gwW3SMqgOjq04j ViCXYd1HyRBl+Gxkn4KJkOYZCk3CcwmSDMdJM9CQyGVm3ccPC5d6qR7sVVUbPC9RJOO6jkKxS+NC IyRFucHsFTulQLnCB9i3ES7JibEPdYNIxQrsVTdN/LirdfYR5TVelmqE18nqRq8zSSnUadSMUKfS /6EzzWnSmbMrZJQ6TmUOznPHkicq1gRi7c8I5ZdRwdn7kukyHfUCzvIDsfo+Ei/rze3E12zXIz5s 5eHfRMjIxbB1BE4dw+791tXdcM7YOjj4q269Tc9Ck85K/BuypDQgm+P3eQKyJHSK/A+mFwcHPMW2 PSx92nmDjP3uPfNuLPfN1hv54+noscT/CT3m+BR90eoLy9wV+o4PWw/hGd5NUJ6j+upn99POOjJ9 fcA2fsWfPc8/tAr9QsuF/uygYxjtGEvMXmu/uO+O+4YgBieZ/ri+klZDiR2vha2GjLaa4IMJ2Bc+ OSLtAmWl5T7WlY4pWH9/X/riS9+Wn3dtd3e7v8D17tsewhcqlTkyvsZufgOV2xBpCmVuZHN0cmVh bQplbmRvYmoKMTExIDAgb2JqCjQ3OQplbmRvYmoKMTA5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgOTQgMCBSIC9SZXNvdXJjZXMgMTEyIDAgUiAvQ29udGVudHMgMTEwIDAgUiAvTWVkaWFC b3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjExMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0 ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4g Pj4KZW5kb2JqCjExNSAwIG9iago8PCAvTGVuZ3RoIDExNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBnVZNb9swDL3rV/AoA40iybJkD8MOC7IBPa1LgA0Ydmgyp+nQpGk+tvYH 9X+OkixbttMl7cmCLFHk43skH+AKHoCD5CC4VGB0DtsSvsEahqOdgPkOBOzm/RML4EzDrT0l3Ski XjxpnxCcQ2Y05PiIKGT0iLvO8QXuHmKa3NrzbmOARvGi9Wq+go9TyJXfx6+UihkpDQiZwXQFw0+C YRQwXcAPoF/LRQIFywktt4kNj5breblL4CdML2E8xbiDWwL/WrdUxl/nVmZ45ZYRLJfeM7+UBZiC CWlU2vGNPidk+tt70AmzsacqY/g1CnTRsYHxfR9/STAFktBBAgNcAOVc83cYdMEKoOD+AvWngB5m d+HcbVggGu7isjJB6OQwC5vzbX1uVgZr72P8zvE+KwQrOIKgC9LL0XK/36DD3vth5Qx+mxRJxgth CgN/PdFGEwsy4TAZdTlSgVc/aFImM25SWOHbimmdY0rC3h1MfPpjlqEF4lnWhl+IvI//42qzQV4h w4CyEMN9FcP2JiEO2RBU+bgv1wHZGtdwvP4Tjj8Gy+VmkJAmu/VDy/0K09ngdDwVSB0hpYPBopAr lnNlSL33EgoVqSMUwl1oY0FQa/RDAif5fEwfkgsnkBpbrCDW3vMZ9iLXbJAF3owLAIkEApFAhMh6 Ahmv93VC9k+B6KPrBCsP0M11lclZfaivo8aALTAu8cFOWzAYoS1zVVU7KnfNORP8WFC2qkWKITSw Bb+nmBBZzQIfDJcsNxIrbOH3yPl8QP+k4m3QrX+NKshRVXhwguNnq8KLqaWKUPMwpa9TBXG+q4BC zWypqr3zUYju8k51e7MqUpk6VXTtvV4VqWhaj5fWS6rQaU8V2DZkxgR2zW2g9L2jNqFrlIbjeC2E QPbxn9BpG0WsbzqKCA1pmxBs4NipvF2g+7CYh0X8wAmGE5wN2kUh1bLDT4piPFmpIiNFzjJpUgVo qpOOthQhlqKDptFBrzsQit3hjTr4r85t74pc1oHhmTYs11giU13tnc9w1IoSoh/8cSnq9BVStO46 83VBSkXOcJ7L8Mlq73xHo7tdd2MpumGXpXZ86M28Exh+xon3ZtdMvgQnXwkpCKVBZHY4XLixob0X D8tuho26sQQcHtxQgTUMBzScJObYlKs2ICHDjuppiqOOH17pdHnY7n5dP13A5eHuCaS4wPlViJq8 5Oof3cJuvgplbmRzdHJlYW0KZW5kb2JqCjExNiAwIG9iago5MDYKZW5kb2JqCjExNCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDk0IDAgUiAvUmVzb3VyY2VzIDExNyAwIFIgL0NvbnRlbnRz IDExNSAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdIC9Bbm5vdHMgMTE5IDAgUiA+PgplbmRv YmoKMTE3IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9D czEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250 IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKMTE5IDAgb2JqClsgMTIw IDAgUiAxMjEgMCBSIDEyMiAwIFIgMTIzIDAgUiAxMjQgMCBSIDEyNSAwIFIgMTI2IDAgUiAxMjcg MCBSIDEyOCAwIFIKMTI5IDAgUiAxMzAgMCBSIDEzMSAwIFIgXQplbmRvYmoKMyAwIG9iago8PCAv VHlwZSAvUGFnZXMgL1BhcmVudCAxMzIgMCBSIC9Db3VudCA4IC9LaWRzIFsgMiAwIFIgMTcgMCBS IDIyIDAgUiAyNyAwIFIKMzIgMCBSIDM3IDAgUiA0MiAwIFIgNDcgMCBSIF0gPj4KZW5kb2JqCjUz IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDEzMiAwIFIgL0NvdW50IDggL0tpZHMgWyA1 MiAwIFIgNTggMCBSIDYzIDAgUiA2OCAwIFIKNzMgMCBSIDc4IDAgUiA4MyAwIFIgODggMCBSIF0g Pj4KZW5kb2JqCjk0IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDEzMiAwIFIgL0NvdW50 IDUgL0tpZHMgWyA5MyAwIFIgOTkgMCBSIDEwNCAwIFIgMTA5IDAgUgoxMTQgMCBSIF0gPj4KZW5k b2JqCjEzMiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgMTAyNCA3ODhdIC9D b3VudCAyMSAvS2lkcyBbIDMgMCBSIDUzIDAgUiA5NCAwIFIKXSA+PgplbmRvYmoKMTMzIDAgb2Jq Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAxMzIgMCBSID4+CmVuZG9iago5MiAwIG9iagpbIDg4 IDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKNjIgMCBvYmoKWyA1OCAwIFIgL1hZWiAwIDc4OCAw IF0KZW5kb2JqCjc3IDAgb2JqClsgNzMgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagozMSAwIG9i agpbIDI3IDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKMTAzIDAgb2JqClsgOTkgMCBSIC9YWVog MCA3ODggMCBdCmVuZG9iago1NyAwIG9iagpbIDUyIDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoK ODcgMCBvYmoKWyA4MyAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjUxIDAgb2JqClsgNDcgMCBS IC9YWVogMCA3ODggMCBdCmVuZG9iago3MiAwIG9iagpbIDY4IDAgUiAvWFlaIDAgNzg4IDAgXQpl bmRvYmoKMjEgMCBvYmoKWyAxNyAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjExOCAwIG9iagpb IDExNCAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjExMyAwIG9iagpbIDEwOSAwIFIgL1hZWiAw IDc4OCAwIF0KZW5kb2JqCjQ2IDAgb2JqClsgNDIgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagox MCAwIG9iagpbIDIgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iago5OCAwIG9iagpbIDkzIDAgUiAv WFlaIDAgNzg4IDAgXQplbmRvYmoKODIgMCBvYmoKWyA3OCAwIFIgL1hZWiAwIDc4OCAwIF0KZW5k b2JqCjQxIDAgb2JqClsgMzcgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagoyNiAwIG9iagpbIDIy IDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKNjcgMCBvYmoKWyA2MyAwIFIgL1hZWiAwIDc4OCAw IF0KZW5kb2JqCjEwOCAwIG9iagpbIDEwNCAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjM2IDAg b2JqClsgMzIgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagoxMzEgMCBvYmoKPDwgL1N1YnR5cGUg L0xpbmsgL0EgMTM0IDAgUiAvUmVjdCBbMTc0IDE1NCA0MTkgMTk4XSAvVHlwZSAvQW5ub3QgL0Jv cmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjEzNCAwIG9iago8PCAvVVJJIDEzNSAwIFIgL1R5cGUg L0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxMzUgMCBvYmoKKGh0dHA6Ly94bXBwLm9yZy9leHRl bnNpb25zL3hlcC0wMTYzLmh0bWwpCmVuZG9iagoxMzAgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsg L0EgMTM2IDAgUiAvUmVjdCBbMTc0IDE0OSA0MTkgMTU0XSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpb IDAgMCAwIF0gPj4KZW5kb2JqCjEzNiAwIG9iago8PCAvVVJJIDEzNSAwIFIgL1R5cGUgL0FjdGlv biAvUyAvVVJJID4+CmVuZG9iagoxMjkgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTM3IDAg UiAvUmVjdCBbMTk4IDIwMyA2NjggMjQ3XSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0g Pj4KZW5kb2JqCjEzNyAwIG9iago8PCAvVVJJIDEzNSAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJ ID4+CmVuZG9iagoxMjggMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTM4IDAgUiAvUmVjdCBb MTk4IDE5OCA2NjggMjAzXSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2Jq CjEzOCAwIG9iago8PCAvVVJJIDEzNSAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9i agoxMjcgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTM5IDAgUiAvUmVjdCBbMTc0IDMwMSA3 ODUgMzY5XSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjEzOSAwIG9i ago8PCAvVVJJIDE0MCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxNDAgMCBv YmoKKGh0dHA6Ly94bXBwLm9yZy9leHRlbnNpb25zL3hlcC0wMTE1Lmh0bWwpCmVuZG9iagoxMjYg MCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTQxIDAgUiAvUmVjdCBbMTc0IDI5NiA3ODUgMzAx XSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjE0MSAwIG9iago8PCAv VVJJIDE0MCAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxMjUgMCBvYmoKPDwg L1N1YnR5cGUgL0xpbmsgL0EgMTQyIDAgUiAvUmVjdCBbNzAwIDM3NCA4MDMgNDE4XSAvVHlwZSAv QW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjE0MiAwIG9iago8PCAvVVJJIDE0MCAw IFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxMjQgMCBvYmoKPDwgL1N1YnR5cGUg L0xpbmsgL0EgMTQzIDAgUiAvUmVjdCBbNzAwIDM2OSA4MDMgMzc0XSAvVHlwZSAvQW5ub3QgL0Jv cmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjE0MyAwIG9iago8PCAvVVJJIDE0MCAwIFIgL1R5cGUg L0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxMjMgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0Eg MTQ0IDAgUiAvUmVjdCBbMTc0IDQyMyA3ODUgNDkxXSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAg MCAwIF0gPj4KZW5kb2JqCjE0NCAwIG9iago8PCAvVVJJIDE0NSAwIFIgL1R5cGUgL0FjdGlvbiAv UyAvVVJJID4+CmVuZG9iagoxNDUgMCBvYmoKKGh0dHA6Ly94bXBwLm9yZy9leHRlbnNpb25zL3hl cC0wMDYwLmh0bWwpCmVuZG9iagoxMjIgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTQ2IDAg UiAvUmVjdCBbMTc0IDQxOCA3ODUgNDIzXSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0g Pj4KZW5kb2JqCjE0NiAwIG9iago8PCAvVVJJIDE0NSAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJ ID4+CmVuZG9iagoxMjEgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTQ3IDAgUiAvUmVjdCBb NjkxIDQ5NiA3OTUgNTQwXSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2Jq CjE0NyAwIG9iago8PCAvVVJJIDE0NSAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9i agoxMjAgMCBvYmoKPDwgL1N1YnR5cGUgL0xpbmsgL0EgMTQ4IDAgUiAvUmVjdCBbNjkxIDQ5MSA3 OTUgNDk2XSAvVHlwZSAvQW5ub3QgL0JvcmRlcgpbIDAgMCAwIF0gPj4KZW5kb2JqCjE0OCAwIG9i ago8PCAvVVJJIDE0NSAwIFIgL1R5cGUgL0FjdGlvbiAvUyAvVVJJID4+CmVuZG9iagoxNDkgMCBv YmoKPDwgL0xlbmd0aCAxNTAgMCBSIC9MZW5ndGgxIDE2NzU2IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Aa18CXxU1dn3OXebfebOmmWSzAxDCDAJEzKEIRDINSRhFSJCSICBACFC2MJu sNMQQ4wEECMmIvIitWgRF0ZECGgRBOuC1q18dnvVVm0/+xqlltoWmeH7nzsJYl/f5fv9OuHMPXc7 5znPec6z/J8zrF+7YQkxki2EJ8rilQsbifqx7CGE7lm8cb03eS7U4vwP9Y23rUyeSxMJ0WbdtqKp PnlufYOQYa8uXbKwLnlOruI4cikuJM/pCBwHLl25/vbkuXkp2stfsXpx331rPq7vXbnw9r7+yW9x 7l21cOWS5PM3VeI4sHH1uvXJc+V+HF9oXLuk73laTQgvJe/d8E1Rn0puJRpSRgTCEZkEyWFCuCe1 WRgvxR/IIOT+D2VlgaX4r9StVV9+4vZU9fjSC55HvtmQyNHu0oBeolOfZ3fwjqY6MRg8OIb7x7S7 rt9R38PX1B5yINBDugPKsdq3Gt/iat9sfJOTv6QPf0HzvzjyBUd6af4fqfwJrb1Ad52l+Wcrzzae 5eUztPZM4xku+HzJ89Of58lJ+SRnOeE5wf251e+51OrwfNqa7/kdyrnWOs/uzgJPV3ex5+HuI90v dvPtrQWeNpTPWoZ7jkSzPK8113leQTn9U5Pnw5YCTwvq0eYCT2tzhqexmcrNseYzzXxlM8263ZW5 yZWx0eXe4Epf70pb52p09WiJkpq5YrUrJWPF6hT3itVpy1e53MtXNa9Nb3Cwm9cy65c5nBn1y5zu +mVpS5Y63EuWtq1Jf3D8Fd8DKLtROlF2omxH2YbSjtKG0orSgtKMEkUpeHCe1vNAROvpQtmNeifK ztlaz3aUbSjt1VpPG0orSgvOm1GiKIsXaj2LUAoic7WeeSjVVVrPbJSFs7SeWpSCufiqQnGHnakj nc5Cp22E0xJyGgucuuFOKd/JB51kmDM3zzI0YB48xDIoxzww2zLAb/b6LFkeszsj05Salm5yulJM NrvDZJGtRqPJbNTpDUYlS9JojbwgGgnljO4xWo9ltNbDF2k9ZJTWUxmiMdsUMmVmacxOcby1NBYK TAHfZsQKAlNiUuXc6mcovacGV2Pc3T2UzIwJd/dwONjGz5lb3UPT2O02N06rTxJKt7TtdPcda2oC mbG6KbdWxxoza2IFrHJvZg0J/A8fGlAfoYHkMYBK3+f7Xv32Lh6KpbJuSpOPP6NjA6ibUbph/br+ FnDsr6/DZz3+2GcDCiHiBuLo/+5fHN8e+T3sLiHXPv/2m9USQ9j3v+bD1nRyXf9r2vtft/IWnnwV paevnPov3jyN6ydRDpI9KODZ/8fnMrl8/em9ZC+Zh78o/qaSqVwD9wRp5a7wZWQXOQ69N4/sI2fR /mdkHddITtEqOoy8h78d7HnKkQNkKVnPPUn2syPZzL1PGsnL5AnyCLeIm8aZSTf9mB7Fm938Km4b d4yr5kycHm/FyFBClNFFo8IjC0eECobnB4fl5QaGDhmcMyh7oH+Az+vJysxwp6elpricDrvNKlvM JqNBr9NqJFHgOUpyaSx1fPUzaZqA2+fz1eT1nad/9zzGZ8tf+WLE9p2H3N996JmMfzrP/KfzrOvn 02LEEavwjy9jDT9DKv4QI/YYdcQI64Xab0ZPfZSU1zX4y5fF0sbX1dbijTK/7I1VXAr2kaIS/IxB P94/fok+L5c8ozegakANzzY+QyvGUbXCVZSPfoYjWlNebsyGdZ9dzkpDTNlei4q/DEPHHfu3d3qu ndlx4y2C15IPETym1mhMGh/TqP16l8WUhTGy3ftM7pmOHT0yWVQbMNb56xbOq47xC8HUZwifXb50 Js7QM0rtUm9MQL/qlxtXvOVLvR04Z4/V4ttfhre+9zou68ZXt/vOqBqqvTxmDcQm4M0Jmz9x8x3l qcu87LSjo90bO3BL9Y13feyZmpqa1Lxcb0e5Hx2V5eWWN5SC06lBxm4hG/8m1fnL65Yt9Ma2LGoA b/Bv4Q7GeF+HHKv4GmyijHWs1NU2MHob8KyAg7dj+xJ1PDtU+hlHaflSTN7C/+mpjo5y1unCOkYK Wh4fU2aqBzJzDmOZtxzsLavpu9T3AO4I6p3ashrMB+ttyozq8bhb7l9YBjllsnz9Sm3fFVwo77/p ZXROiim1Me9ib4zMqPbj5VHsa8ko0rF4FJN1NEPzcqdUfvtWTMyW/d6Ov5IYrfX3fs4o/vbKwr4r Urb8V8JuVvgrajs6Kvzeio7ajoU917Ys8ntlf8czU6Z0NJbXotfK6hjF9VPb3bGKHTUxuXYpHY35 YVJSMaO6xO2zYhzJ08r+UwKxg/BBzDEccAH/JvUdMBdkZrXPOz5GZlXXuMHIalafiXryyIQNwj0K ctDHNsajJWyw6IjV+6o+H5Pg7T0KWZSX64ttuaU6ee4li9xHiRIMYD5q2Z0z/Xecs9idLf13rr9e 68fkHFPdNGdMO+j6P4vsspcvHR2jrv/m9pLk/Zh9fDXv5tiiQI1z86ymD0AbFMdSAqgPDnRgWt72 x+RATKw+4y6u8cpWaAk2e7f6p9wyp9pb3nFdCpJX+kbKRE5+2/8aheaBXpJjtFiliapKCfyaFONT RuFmHpzK3Ck9RFeZdCF66LW2njKSeRLuKb9gPm4/kOv1li8rg2jgZE8uLgz1ofZgrrciOaH+Gm+H t2NSXYe3wrt0YR1mTT1C9pZ01AQxebdWYwGzKYwpNe7r1SU1NaPRzl7WDl7B4x01aKGhrwUc1UvB OB56KHcKJHtQZTVW/5YyiEBZDSYXInQGsnYGwl9Tg6f2XacUFEeXpfbR/G+ged9Q3N+fbAUuzhY0 UdPRwdrEGTcIM97R4e7ASNQrfh98qL4LPUR9BkqhhyqV1eyW4vcxkSv3+/w+0FFThrYfxpT0Lyj4 6v+JpaTsBpb+6DqhePMRkPcjlaU//hex9OD/hqWP/q9Y+th1Sr/D0p+A5scYSw99P0v9/w1Dr3NY +R4Ob0lyeMv3cPjxGzjMPDBKuCLEXgGyRyRkDNcN36SbpAlPkrX0LJmG+gwc67kSIgqElAiE7sex AqUVpR5lHkopnplPL+L8SdLI3mVH7jBpE6sIEVrIXvEwqUMguA/P7uXPkn3i52Qph3OxhOyTSki3 1I12HGSXcJEc4A+TmTj68U4UR6JFG6gLaC+G4uEbSBjtNPEtZBremcNfJDPRlg3XEU6SKGjZQM9e +xrXW1BvkwKkiV0XGshUHDfwAbKTd+AdxJzsOtqRxLNqnaBO+CqSIhwmVdxFshJtlqFU4zk3ig1e XTI+JYjOJdqBcy85w5h43d/jURMImEkkRLhaKAA9MeBpEzHjmgXRLiFWFBuxw8t2EhdJwVkqSSPp xE0ySCbJwrkHxYviQxlA/PgeSLLJIJJDBpMhzLPDJ4CSq9YIySPDEEXnk+GkgITICFJIRpIwGUWK yGgyhhTjqbFkHCkhCrmJlJLxiLzL+96s6Dv+aw4T/jXNfE8rE8mk77lKyGQyRb2ej9GvoC5aRjfS x+jb9BOO43K5LdxeXuJ38F8JDcJlcbDYID4mvipJUpV0VOPVbNac1xJtgXaf9owuQ7dZ965e1m81 DDNUGu4zfGBcYfzIxJkGmk6bJXOd+ZBFb5kjj5DXyofkz62Kdb71XZvRNsO21/a2fa39uP2So9jx trPYucN52nnJJbvqXcdT5JQ60AZfGsgExAHohoaEGf5wikkeeRBYhCCfwmVRrfMy+e4NDi+xhzg5 f7jP6rNm44vi2pUtIvmGHQkqkL091y7RTrEdcuYmmYolPd0m6GK83XFELiVHpGDv5V5S0ltSEBye n+2Q/AMGFY4YGSpw8TmDuEI5VGB1WDhcpZ0TQiMnTRwxckKn7Ayva8xzyzqbYWlBRTkuT6KuUDE9 3EWzEx/3/v3B0Uw+eTLm2iXha3EOJDQPknZAWVBupNOzF2SvzuYrfZQOzJZl4stwDysiA4qK3pBh QWXiclK5KNstODN8dKBAsrKcA4gt0Kmxj+h08nIR4QfYhkdnpNLUrKiHeFJ5ZQAdEI7aBtgGR/XB 3lAo2BuMpKjfvVZbShEbWG9Jsa0oiBNrSlGk3Tws0C5Gz5vl8/i0m+Xi4vM0QiKR4fm+HMlCzTTJ gBI6MtzHCKfDQlNGhkOSRkfDvEZyOlyhgpE8C5wG+QewU/7rR5whbsI78zpfX9zIl+bvf+mhPecv m89XKa9OfIi648fzPq7eVz9x1M7JUxtqykqryk47B3NjZv707kX7Z/DD0x9/aNfRp9tPPGX43fzW U8cSPdQ3hErjlq0YM1Phpo+csnjsjKlF4RawFJqkNRHgophLcErRa91E0FAqRs3BeEGwmJSUDM+n IUlPnTL15wyjORiBjTOuia4pojlrstasHDn7abH9VOLviScejn+Q+EH23U9v/+D/fk5PJNtOQ9s2 tO1gbesE4taxtuVv27b7R6bTwhF6mhNKyaIsMtSY6bbGO1eNLIk2NHoa0f70nE2JwHlqpRO6n6YV NLszu+3pHR98/vt3lv5cpX8t6RVGC8chi0ElVRQ1wgN6SolOp9E/IFCOo0YTfSA1EAwF5eJ4cUGQ oKZWIJtWX6HPGrL6nD4rRxNr6K7DdFdiTS+97xA7HkqsYvyZds1MZ1IttGmWAo2qiwk2SiVBMDJB hxQUBSESIYh6SuE4+u0MS3V5A/mGSQVjp235Kjswe4qnbuT0FTNXH1JpnkHruDIuBxJtOsZ3Eo4P gq7e4fl2kDKDfpUwcznnWN/1WGdzyIcYm+U4iUl2/oguiKUVH54fLgCv+pbWh6GJE0aEKio+rAgV lJUVhJiGpUS89gWXI96NPkYoNsrx/K8IBcpCOXCHt5Oea5eOczIYxIMjoWBo1ChSEioJtYuQ5uh5 jIaGqEjvuzex2ibuvVLP5pMjJde+4s+p6z6VTFXCo2ihPNpVLk7WiAGaLQ918fZOyW7qJIIrWss3 8vfyMf5t/hIvvc2jT8rzcnS1juqCEfBrzdqIqiR6KVsptACAAOcfwFllWwoOToctVGArHMFx2jPf fPPqha8Tb+rXtW9dv/6uFrE9sTLxeuKlxFp6Fy2l4+iu04lPv/p74g80/au/UC/opHQ/iK0H5sST VMXE2wjPNd/L03yQEFzDulWl2uqn+199VdxwZTt7h4Br/CmMLY20KSMny/WOzZoNpqZUkaSl/UwS HBKmnLdYjFIa2c3bKi1Vto02dt55m43aBJIm8QJFNKNkmuQwpbqo5JzoXODknU6LIHgt+RbFUmkR LMFIKGgNqQwIWFNCpCTSWxCMlPQWFOCqtYjpEqwPsJ9GsiELheGRtj6loClkKtTpMFMNfYxzXN0x 8+XPJty1euaPb/rxUyd6x3QfO3vWvPgynfn0rI27Fs9JtF1+YeaL/3gf42q9domvE7eRHPKAYrjD /ZCbq9Mvd3P6nmu/VKpMqWH3YJMZX1ZreM7A5QO32x41CzZbTqeF4pNm9GbkZ+zK4DMysjrT7Iqu Uler47G2Oo10o4tutFCdLgNOSobQarH4Wl0uOeNSBpfBRokp7rUWBUNstBGsEHWYqFuxYCK9RWlY MNCSAA0jEQrlp2q+/jFKmixIAKQ7p5ApxsIR0DxBStcYW7e1rVjZtvnesx9WzZ8xdejlUw/fv79r yR2hrElNNj5vxW2R9WUvjn39SEPnCG9k6+QTX97868W3L751nN9nYf4SW09f8S2QizRyu3KLM8tk CpuLMV+zDDSlU5KMxKKYHGGLxdpptPO7CT/EUeRQDPwsHXVEdRyXr5ukW4Lh880yfKV8+DaVwMYk eFwWi2zh2OSyqWWjl3vVQWPY0WBqgI0Zq1sdL1viVkyl4HQI3w4Qal/zFrciMdnpukClRPznhw88 cO8Pnzi1fVNA3HA08TD3txdf/tuMny/avXx1lwqVcmQe5pXJqx0+29bnsmDqwmLPtc+fTR4vKFNQ cYieTo2GpnU2majJHuUo100FUZR0TrFcnCXOSm2QN4ramgwqOlxROSOqhz6o1C/RN+rv1QvNeqrX e+V8mZPZkNaghOReGbKqji0C2WXjKgDURxiSTMMpEM6klGLuuMIR6ZTvs21Jw8ZtcDQdeK9o9apH f/917OW/RP/jQe225bXRtpWj5opN5gdvu/xo0Z8OH7lMnR8dojdTf3xAcPTGPXcuXhIdgJVcivGe xngd4H0e2aEsKs8s98zKnOVZnLHYuy5jnVertdlqspdlN2Xz2Z2WLJqVxVcF6gMbA3yg02RvgoXv 1PDt/AM8zwtam9sZlaQB0Vp1rDH923qRYLzu6BaIiZ4Mjq6WKYbN7P+aXqY0mDiHCtiCxXKNqEIc gRQXY/ARu+rewHYldfLAwhHhYTS735ZDgu3XDTtOFn199Mifn37p6pnTicTPam7mWqK1C3/QOm/u Fuu2lcvbO1Yta+cTBz/9+LHnNzf++qnf//HwxXUTd1XP3bh+7uwf3BG/6Kht2rxw4WaW8eLIfNiH RYhfDPDpMxSLLWaUmZmwlPJHnKW64CfxT1R35bvmwn6D6Xg/NHFiaPjEivHqcULFxxNDBRUVBaGJ 3CuoTZiAGuunHjZwNfqxwN8LKC5XTJaNRilGbfYjaSYTD313JI0PhpLmkFkosKsEEp9ygz3UwDze 2PVb3PJJBcWVWxoDAwej9+EwYno9s5KrZqw+5M8eUsX//VsSMCmN5PfCGOEc1lulEqACz3/EUQfs O4FAfyQRKGiYGA5ho8RJnMCLEs8hhuNpEM4bNG0arFxqEOa6yFpU1K4aufZhqUlbZy+kTh11NvIX riZ4jms5RPc+mzifOPssG/ta+iP4F2gcvrRbMYoPSBL3AOtf5FTDCcMN2cDqZs4EijD66ij+VVb4 +YfiD8Hg30j7dGUorBH3ESUO2GEYDeEjUXJgSXKEChIvwubyPMEARElQSQ/996TraCH+UWHM1UKe Xr3GX+BaEgufpSW0+NkEM9ocabt2iZsB/Z+CqC5fSTMYfDG33dVJBXtUEFJ1bWYz4r/UI1lsGGw9 Q2Grhhn+HxyScBaFJmYuasowOGoj+3xUe7/vAZvU1vrIoZvWtEplY4Jzqm5W8i9NLCwoqygYMUF4 +jfS4z+ofPap12eZMjyzJ1Ws2nn3nHGTvnkwVF5WMGKSGrqpcaxYJUbBXT35oTLhHzqaRly0SLtU KwhanY7Xi5IEp4HnW/rmWydJLRri0GiIuFvR6+FDs3mWNDbKc6ehjU97NRoDRpGeFi8qwj+SWlJc XFxSHMLo0nv7HJy+uW+Xi8+3y+eLmcOOKQxRP+/j/dRAueqd3Jo3T8Wfjr3JR3/3jhi90kr3JxZx lfRKQgJfeWRZiFAFW2IBZweQFcrkesNGA9ekpbq03dNt1GI7YuNsNmrdzfHpu6lNR42iRjKONFYY azzLPE2uzZ52jc4VtWg8mqCG12g8UWPPQFt6M33OL38dL5YTWE1QNrAd6hpmGmdNbxFTN5Eh1Oor YBOjYV9mSv1QTTCTPDuOwzQNo9y6RA5d9dRL9RcffG7VxcQ3T7YdaP/z8y8f3DBhSoe4IfLj5T+v yXypffmhBuFcYt7mha/FDyfKQyvGKQ0jmLzWXbskToOudZGFSulPnPSQhfLVPDV2mkyWzh5YCb1A Owlxdp6AS2UXbeW2Gs0yzSabaEQi1EsVWkkb6QEqUVuUak6kyF8XqFYRfgDzd3pLFqiHyALV9XNK vgEDERgSX4HohCEkTgcJFYjTfpv46E+JU6cppPm31PTXP11KnKOj/pKgZb+9/QU6+QwdTg+se39H 4p1P/pD4JeR8H+HEA5gPMxCNPCVT3k15625i06VOTq2S6iV4cqlRqcdjbSbPZclf94K/zC1hWips 9XkFm9PBaSREH367H9yFK6/6Hdw++j7NpFPPr6irb5++9ZT2CiXdj60edv+eUZ13cuK6JxLHzu+4 RhbWhTxO4ew3fx5SMqz709/dU1jmYnzcC9f+ZdBkIBVKQLPbI9DpArUIRwROEAzMw9DuNtjYms/X V+pjel7Pa5v1hueMYFi8WHUnWHBRwuxsZM1akKp6D8yDQNnLp8ZjXHH8PLf46kXmJVQ9m5h2FLJJ wQvCt6FfHQkrPs3uRoEKgo71p7OJooz5uRcIs0DRG9U9p+/vDX0lu7qxI/8+7rP4h5wv/iFc5aOJ zUfjG9AF+lgKGVkEGXGTVcoERadYy5wHdcJPXPQQogr3bqwOvanTbJaZvOgFLs3VeQJk2NM0VLSX 2+doGjQb7AAT7CZTWjN3PNMe1ZzISM5LETxh1WmElBQlJUb1oJLiEqE+q+D3EisTGFfKtxJTglXB 76QXE/g8mlhIn6ZlG3/xyJWvP038jI7+2+0/sSf+wsXisUbaRYfQInogVPZGZ+LVj79IvBuWKEO8 VL7ROvCNJ7lKBuF5G9dcydMzLHq5lz+AaOYML0LxC3xQdWMxJWosYQ9Z/fuuhxLJdsQStKMndyrT RD09yZ0UYZPog8D5XkfrcMRa9MSh53g9013ch6LgEDmKhgUBegwYJKyLnrxFqZG54UIzC570UrPm OQPTDfAymV8SgUaDciiWodzk4nZtEofAEWYNgARzONeQyBoa0lEftUI3WPnYlfgj3F8SX8TDjNx4 Q9zHHY1PQ42BAZBsIJ9Pgm4j2apMH2KkxGhsYaQZDaJgQF3SOOAlS5pmoVnDGTUCb5AWiKtFThT1 EC1igNU1GjVEaCZcPqdwtVwzJ3KcQdOse86EuS1g7nGBFW4TrBq0sgqjRIoBpEQY9SzyUalPhkAE gQGopn6Vdip8deq1xIzsxLRXX6DvsKhNKIl/wmV8cxbUv4T1D39YGgM7x3yhKUrhT2z0kBEaqwfD EmydJyQq2UWL3llumeys4mt09fwyndYZdYGzPWmWaBpMzIlU+esIFAO0LlNU+Kfqp6Soqd9in3Ii hSMIPxHQ35HEzYnn4CrMpYfo1EuJC3TkZ3+iRYlXxG2J+sQF/C2HtA2HtO09nfjFZ79P/IIWfPIB DTK7vEuFbTeBXjsZrQwy79brKbGZoLZsUUmcyVeJi/gl4lqxXYyJWjDYDMXl6Jt91UAzYz08H/BF MiwMUCs0l2oHdtHnX/1i8y9+dv9bb/1m81Zx0y+Pb35hVvwR4eXElHXL30ffB9A3VAbW7iCyWilr 1FCXxfKhWe8wm/UWvYs3mwk24aSlgaBMEFSpXSLWanmt3mXh883UbPZHiRhEABEV4XylZ4GynH7K MMUpoQJVtTICi2Q2vczomvvi2j6CEeMB7/EAVRoU5Idx/dQnrdcBOv8X/9i8dvyW9ZNyJ38xltfl jBs/7rZbF40oLp66Z01JRbO44d1nNx/Nzd3z003FdfNEY7h+ZVV9XvyAcCExYcSy8aXLGU6NDTWI GZZCR/nI58qw9yl9wEf3WCnXAFdhlO2XNo7LKkCU9IYVpsLH+ZodVofDYU2VtbqwBviIMhiVE1ir XdyjwEm0XCp3O3c3J2g5nyYzxxF2bHLwHJ436hD4HzPLYR2C6ktKWG/s1AjpCgLLdI37J+4Tbt4t uzM7U+0+zis4rJZDuh7dq4gjvc2DndTpT7c0C9V+ShZEgr3n5Q8ivecRXhRBwTDD/4tRkTcDJb0X R73JosiiBcwfKJoPy7kgEggwN9YcPU/wKhZ7gLKrUJIRinhZhVxV7chCMA9FvHlDQE0v79nV9OmJ I/c98PSiH8677UFKfnfsrcOPXJwf5SbPm/34qkd/vujjzrkTSlYVz9nz+aF3mxNvLpu+BSwFT6Ep haPiJvhrmYpZtPEamBWOE5oBvQFag9cIfKoYAItqqmBK/cKuRNprCZ+46eg3Y4SX1TaisB1ByF86 GaqkD8KOrEna17SwjLyzU2snzfR4htxsec6dNAfMAhar3pmVoR+Sz5szjCuENnNkATkIQ2KE+teC 5QWPJS4nvny0oDzvtTk90aONY0aIG67+8UcHVwZ23ZO7cv/jfMrVP768NxIpuPtRlQZy7Yq6BiSy UinZxNFB0kY44Uwz9wUToiS2CLwDsA/ANOxQaYQK4e1NlG4SkH/RQi//VOSln3qhsvu9zd5IURGC 49SSUATKrbj4u84mFFqfkwlHUzC/Ej+aF3/sNXoQyqxNvOMqS6+Av6BLO1PVwb9SWpp4OpdbznEl gDKhlVsoh7CBM/AC32I0OIzQy3qdvkUQQaUoaXXaFo0Ex1jaZKSNukYjpzMKPIwM1DIzKga9Xqvh tZIGL2EfJOUNxnyoPZ3GaBRk6qX5FJGcLHiFfGaHgpoSDaeBpUlDSQ1CJtNUu4zwqU88UVN9ayDe zAThi2nyyHcH3e9o98dajAlQ7NSvg2KHZQpRzc5X4hcCiXAiFIi/+Rptoa2nKZyXK21C4zf3gi9j +XNXxyZ5gyQG8inMn3pcWbQMWCZHDXoD0fMIoDB6jU7AOsW8CRI1GDBYrU7SEHBNAtcksELfohMc Op0gajkD5hUzpzJGr+M5g1YUsLWTCrWwCHqdhIBDw0LHpK0NYWSwtP3jBO7/3VFq5WLteQ37hh1m dXyf1wIcoBgrRqr+w6Tv/Cr+Hjfzq0R2wnOZmxN/5zI9DvM1P57HlcZPc+9xj8T/g8lALDGW24lx ahDVm4XdGjfz3agowuz2Yeeq49rvDcbovyf+L01N+MUNB6/IB5O88iTG0itqG1mKRdyNcHg3dYuU NPOIiRHjyUD31Vb6A1dENtnUlfgT/U1i7EHx0kHYiTD052TE/T7k/mJK05T0uenL0+9I354u2j1+ D5drKbZMtcyzvJH520zpguHCgG8M3wwQLAbLAHgE/L1pNC0tw7+nwbHZwV1yUIcjw2QYgLiWLx26 R1dqsqd0Z8gOQ+mANowsbxd9kX5JeQ/9kCHUclpaTut0eYHcLD8sCyoQw3DTtQx4keOfqqQD3UgJ qX5YBEHrD4KRVGsIaBsipDVMxiLU6oB6cLL8Sw5UH8u9lEAtAmljUGpKFsdb4e6ruRfunNdXMW7K kA3O9a21W6LrPnusa2fDK11zsvJNz26O3Dxp9GxuSKIpOHz14Mx5c5prZ28bXDn8sb2vRKel3Xpr Io1ag9lTRhUBKWF2vQk86wHfTcixjlUGLRE3iG0iz5lTugWZEGu33jXZUePgHK2yhmrOmjhLm+lk mhrxxdckQ5KSOMPUaARuJQhFYEJAfY7d6lKNOyKkpuMb7zryQeJvH9S8PPp4ZFHTg7vWAe2O/64q 8fe3Pkj8Y1AmtyFhzniyfduTkKVpoCeEOXSRdSeJEQi12eEK0yyHM0wU9sVA69Fma5gqKe4w4gaT YrKGTSads4u3W7p0cjtpR1bSRBQgxOSF1HLbLFuD1CRtk0Rbq/Q8YrveiPxFoOAHwdRkPIVpCrDC PsixOMF6uEuA85O+ehIQ5EPbWn+ZuHbljQlrbu3YeMf+JzqXvX8sRMn7vwIGl/1S9VN37XwMvJwD evar6z2FFCreCrlKXi7cIQgmgyWlm7dZunVgqcHYxp1ltMB9643HWdIKcm0NhZKrz+pjUCT6T0mj 4B1DMmA3uD+eSNzxxl+u/Wzeilmz7/5RxdD5m5lPSblfAX/NiadwEwJHH7jn5mFedU5nAjfuBA8d 8JjqFIOcZbGEJcXpDEuMe8Mt1rCEHNkeC8y5U5/WtdF6lxWZDKGrCaGPaxbfYOZcrQ6H9EKms5S2 mp9HnBP/RE4gEu53NCHWTIgZWAymwZT7VNumCi+z5Swb4sz2DYMsS3xnvEnz45Zje2Y+unrPC2u+ OH3i1/EofUuzftGiKH1h677Go6Pyf3hxx7tUc428X7Vy40Yml/DkIJzz4Qs5yTxllI5L44BOyPYu E7FoNLougZqsxGZW4A6ZFb0hbDZrrG22Rs0RzYsAJxwaB7GdAZ6RjEkjMkOJAgEZ+hBKBGsPzrxq 9CG0NzgemTTk9MOF9xd2/3Rr0bTcwctvPXjw+FZ+T/iDX9uOymvvCx+MG7nLTGHx2O0b4OdjJ3A2 9hQUU04ZttH5qJur8NR7lhfz9sF2exi+mTVsG2y1h2WrrYDbbN5g5TzWMXYhfaApl02E0WYL53Zt hNtv5MMsvzHSZg+Hu9LdUvcgBfcGdfEywCVdyHOrZ86YHaNh6HW6sNU+hh/tsfhMA4eIYrBVpxvd c+0Xylj0NbqVpLhS7k05kPJiipiSkmlpvdd3AI6ij9xZeF8hV9g6PXNX5sOZRzKFzMyxQ1rzkQ/g yPNjd42jEfmyio4zACc5tZjfALQuy/Iw3w4WJMDWSwCiGlBnPxBiRgYOAlmDlQMFxlBln9OfhHjU JHFfijSpzFRoNTyIqvnipGbgWd2nJlNmvH+K3nFq5NAZLbtvu3nJ4wtzSj879/J//HHe9PEXaNXk pfXTbr5tadO8DZQ0tR3i5ux+4p7wnNETt092WUZ5h7iyh+aU1rXu+7etz48cMzp3onUOXVZXMSGy YMLE2qu/mTb2ngk3KbeoMhXFxLVifdpJkeK3cofMPWbO3A0rLQkuYRAMrKy32/RtulNOK9dmP6mG LwBeYElLIiXIkTA9l9RyGCUERYXMNVZ/9Pjax+fdN+H44luKGxRmIQ9vn/fIgfhlrmjJHeMmxvHz E44AhqBTRTd8AQspUHxSswdCbrEZLXyzTmduJUjJeC0fWS5ZRKR1WHYmCeJDO2Aq0O0NKDiPOPPD PEXJG6oo+cePi+5xebnKTYGhNyWiV5eir2tfJwK0VO3LQUqUgdZuOdmd7DZaZBli6ejr1CE7vA4e 2K7jes4gmIbphZ/EupU/+U8dOzQ58GAv5iljhwVKb8o93tNeMll0l+QOG6fkMgK++fTLxW2uVWwv CkcQpWOrzwZs39CRtUoJ3B9BFM4hCOEBdsN1PScS4Ai8SLi/i8i0i3BULUCuAf7YGL4MEMEgito2 3Un93wws4GAxObOrLAGMZCRzb1hMnhZcEGF4QhJHUD04rYonMFeGMm5x7/8qsYn+6nIidPr4cX5P YiwYdJE/oKZSMQ1tmJsxoJMnA5QU5F8J10p4mffyHyEbLBJe4ZHy7s/EMvSkDVxXE7EQSPh4R/kn sSvpbmVO2ILMtdPu5JD/51MsNNVcbeYmm2kaZ7BtMtNNOmoG7iBoMkulbkdpDpAnZCYsaW2pTJGl QmO1UVajZwwmfZvWQHMM1HDSc5s3OfhIBDjr5UC86HKAATkLInApkJWNRODpqUAri6YQVTEAol80 rSEn8x5QXP0Sy687MaO+aMHY48e3tx2pve/hu546Pr96DbcvXseRB5tGlMbr+D1N2x87dP61+O84 37rNmErwSF07sCk25Oc9tNtiMXVLvIsfhPSUbLNorTZdm/aUg8ht1pN21T24qq6bkghCLMgvZWR8 u2qwaKw0vPmhqvtvPl61pGXOKX7Phvaahw7Fv+KMO5ta4quhWTkyFftnfPxeFSMpVAbWk2USZ+wi sq1LchVaRqvgyCzLHKfkbOVfSLO06lSbeh0qZdFLAYNnVZNOUm5QPVzRu/Ad//B/3oL/mPZ666En 2+964ii/N/HnN19J/IMaXn2dmg4+2bb1J49vbX2SjR/rF/oeVIIWl+onCRuENoE36+VuhIBuUze1 TLbX2Dl7qwyA9CwxG9rISXgbmLHrfhKyc8zG2wGBILwFVTkMAkm6ScPoBlryV2pNXHulenlLy8x5 W358c1siIK68/Ju3El/nJBzCufjrgaM75nSUJOdjJ3RZHuaDaRP3UJ6abPDPYBhli2W2hFSNZCWm NvNJmZGAJbMA2pvl7YNsL0GEOsNMKjSqg8Gmoky/dettjbULbqluOcHveU++uPTAnEPrEh4MGHMP XII7h7785DeKc0NaWyaXkZ5+zqBzGAw6nwX5eHUrQZpRDrvkNN8geYhvJB0pF/kq5Cn2h6le7rn2 teIy4zG60UCbEMNlpBsEWej22e3MDpbaHGG7AkDCbnd2y7LGAXclQ4dHTBY7tSupqbgLc2hXfD48 omklWQ9k/Tjr7SyhBFlT/KW2mtDMs+hePfr9YROsPcuFJrUa7NMaZsCY7ccNgMYs7kOVYRLYwqAi PSQSLmRODGD0Qd+DR/RtX5l584/CRTMKq2MrH72z/Z5Hbiu8aczkm/7wzPYZW0rPjxw/KmdwYcGi 7TMa7pp6bFFetnf0kOw796/pBASBcBY8PCRUwZ8Zp3gpdYhdnAUBbpfJHrCMsUyxYB3p9Smc2GZ3 Ou0IeGR12hDOMarhaAGlYI7L8HwrdTJEXQ0WYFpVcMGPn8X4E//eumjlsh9Eb00fkHKAl2jl6YOJ sftLD4+Z5ArXRClmUl3H8K9bMK12MhxZB2rVCWnCEIHXWew2mEI7FrD9lNPQpmXWD+Ai8097S0oi xcz2+QpZdAIHj6EZkNswjtyF0V2TZ++ecvzWpXfOPb6hpGJ211OcJf6XznXN3H3MHGHsEvpsQp8S WaOUAoKyhdnOvXNJdIAFwOeSwAWDLFhIbIcdEAWLyCPsl2oZpFwp1SJPKgkKREMIBkLXg3yWHmX2 GX9wU/4pmKfMOUXsTkN27tjLiYaxidpX/s7vuVrNH4q/npwT8SzoMpLPlN319EGOG6EbYVyJbKxg A64AI2W8TqXBaOijUg8U8ZxOD19Mz6L4c0kMo5FhGJQhGBoW02MILKK3JHELvCJpNURFLyzM38NG 4UpaSz+il5BNAeJbKdQKHwmXBJGw3MdqzZeaa/BjVTQDuHkfnLEGvtkagBkMz1C/VThDTRYW/++w DASa17EMN7giJM4lGooSXyYuj0nUn/vzn9o/Y9zhWuLN4NC73LD4u+r84Usg4JOB7FXm3YBdXEcz BBhznkparQ44BmAAKknnkjlPhmKcS6IYPOALbFbQWZhpJ7CuCl+JXVewrwzB0GEfah+CgRHDwDP8 Ahb+n1EpjfZG0KIfumDZgxuAC+7qZ4k22v1Z4sPEl5/S1kT0U2qF2R+TyKOTE8fpe/TlxHk2/9Dp bC1oyHrlJuBQQKXg2AOmOQefCHltYC4ajISlFERBI8BVcUOYRYuAKSa1yBgi9K+E2gX2glw4g1/6 5BLbiKzJATD/JAm+wCUBCKOm8NsxBpVihrQw2XwzvuECcPh9b0E6r+zm9nLvxf8B+rDzmR+r0hdW MiVGV1/yvUu0SV0U21IhPDwERWQuEZQG+mLLtT9rzFBNCmVBfQHehsD/j1d/TT9ODOf3xG2HuS8w q+ijiksRqvj5iBWBj5IXTaWSZHiRL5WxTwINEmzKKEABewdIKhDhwU5XwBTQPEE6iM4rb7xl5eF1 D1eOm7D1h5v3Lts5bim3v2jaG03l/sz299aOdeexPlbSF7ilfA/kx3ocEy1j7wNru4RtQ+zfjMKi hJVdSxvu71q2tIs7tazr/oZlXUjwMNtbxu/hUxAL2mCBxioeq8VjIV7JYUyPORxeASCYoDtisWT7 fH5/ypHMYLwoqObkkJFmux2B8kKOZLhIo0ZRhKhqRN2/G3EcFZlr1L8/AANzclcH5grBUeUjbrql qDYxTpddVDq8ZGZ0VaXYPiR1QWF6Cl8yvKCsYeb4H07/tCKvoKxxZsPDAwIKU3WgtRq05oBWltdV TpL0a58rmUa3m5bKMcklINJju0943pOWkWGX5bQj9r5dmQwZ6t+fWRz/BLs+QS8tvL4Fl3E/u7AP KAfBOOW2N4wfoUxvXlmZCAXDpeGSaV9OF5rSzctHli+tWnnQO6hik0scl188Yfns38wYNC5Jnxsy tQn0pQAbmKvku22iDfEASbVIfBd2hjm6TNTali6n685LyPVxgrstXSe0SZr0dI0M9ZyMqOXeYsTU wLaKidxL4V6oGR4WU7NhqPsVr8fSITXCdqX4GRpgdYhwn+mcN988vm3b688/CM/ZPa3kAl335JP8 3n1xjkvsy/rw0r5tk8Yl3pNtV/v2ccIj55tBswsI/AwlkIpwAtQSS7posXeZqdWaLvSTm/ZfkgvC +shFja2SYphURBBMc/SF/SB1HFyAvjQES+fRGe+8c/See8r2NypjRmStmks3IX7oIzSv++kf2B4z Nz9Ej6qBhLo3BHa+nqhkM3Z/5zMVZ9ApIJ793sEMz03GLx2+/Z0D+40D9qcjkvAQLzDMAf/0m4Zc /IYhX/39wnd/vTCOKOrvFSrIBMJ+BcB2/E8lN5NpZDoi/FvIDPxfArNIFZlNqkkNMKq5+E1thCwk 7eQYeY6cwa9r2YchLtCI+EigjFTMLr2lYk5gwrIVK25duIr9vPf/AdmhtpcKZW5kc3RyZWFtCmVu ZG9iagoxNTAgMCBvYmoKMTIxMTcKZW5kb2JqCjE1MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0FzY2VudCA5MTggL0NhcEhlaWdodCA2ODcgL0Rlc2NlbnQgLTIzMCAvRmxhZ3MgMzIK L0ZvbnRCQm94IFstNTY4IC0yMzEgMTA3MCA5MjZdIC9Gb250TmFtZSAvRldCUUZaK0dpbGxTYW5z IC9JdGFsaWNBbmdsZSAwIC9TdGVtVgo5OCAvQXZnV2lkdGggNTI4IC9NYXhXaWR0aCAxMDg4IC9T dGVtSCA5MCAvWEhlaWdodCA0NTAgL0ZvbnRGaWxlMiAxNDkgMCBSCj4+CmVuZG9iagoxNTIgMCBv YmoKWyAyNzggMjcxIDAgMCAwIDAgNjI1IDAgMzIzIDMyMyAwIDU4NCAyMTkgMzIzIDIxOSAyODEg NTAwIDUwMCA1MDAgNTAwIDAgNTAwCjUwMCAwIDUwMCAwIDIxOSAyMjkgNTg0IDU4NCA1ODQgMzMz IDAgNjY3IDU2MyA3MDggNzUwIDUwMCA0NjkgNzQwIDAgMjUwIDAKNjU2IDAgNzgxIDAgODIzIDUx MCAwIDYwNCA0NTggNjA0IDcwOCA2MDQgMTA0MiA3MDggMCAwIDMzMyAwIDMzMyAwIDAgMCA0MjcK NTAwIDQzOCA1MTAgNDc5IDI1MCA0MjcgNTAwIDIxOSAyMTkgNDc5IDIxOSA3NzEgNTAwIDU1MiA1 MDAgMCAzOTYgMzg1IDMzMwo1MDAgNDM4IDcxOSA1MDAgNDM4IDQxNyAwIDAgMCA1ODMgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDM1NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDI3IDQyNyAw IDAgMCAwIDAgMAowIDAgMCAwIDUwMCA1MDAgXQplbmRvYmoKOSAwIG9iago8PCAvVHlwZSAvRm9u dCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9GV0JRRlorR2lsbFNhbnMgL0ZvbnREZXNj cmlwdG9yCjE1MSAwIFIgL1dpZHRocyAxNTIgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIy MyAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjE1MyAwIG9iago8PCAvTGVu Z3RoIDE1NCAwIFIgL0xlbmd0aDEgODQ0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAG9WXt4VNW1X/s85pyZSSbzyGQemcnMyWRm8n4/TUiGMJMEAhEIQgaJJiEJCRCJGIJwhUaFIhGx ikBEq6VahFDMEFKcgNJIqYq1LbY+qrUPK7S9/Zrrvb3ItWBm7jpnQkryqR9/+HXOrL332ms/1v7t tdc+e5+e9RvaIBr6gIaFy5u720H62UYAiHdlV3N3hNdexvitlb099gjPJgPQa9u7V3VFeP4JAIV1 1dpNk/V1FwGUHR1tza0ROXyBcaGYEeFJPsZJHV0990Z4LfYHnrXrVk7KdWPIJ3Y13zvZP3yEvP2u 5q42jPFn+w4GSd3r7umRWLDNx9jbvb5tsjxpQP1+CQRz1bAO5LAGOKAwrYZGAO6vCiswKBXl+GtN V+65M6bsM9DwEn/ngkel+DXh5fc+b/vCrXyM/ydmyK+XF2NZSigFIIqgfFz52JREqoeBOgj1aUGY i1SBVICUljbbCH3kEHwH6XtINHSSh2ET0k6kJ5GYqdQR5EbJw8MM7zlFNoGZzPMoGduSWJPNqFDa fhUkspFnbB8YPzlNTDh7HxPTcDTIZyvI98iz0Ao28gNwks1QA8nkwImUtbYmFB2BbqQ+JFoKCTky nJBrO0PSwckQrOOCBIactP0lJ8N2KSdIkWHbWXeQwejVBOQ8MbYx6zO2H1tX2c4gHY2IBlOwxEnb Eeta256EIDkwbHvcGiRY57FItMGKVU/aulL22VpzJPn8fUHq6LCtBOVLPUpbYbFgK7BetGW5gzxB PsM635aa83NbElbEYnZs1OnR2CzWPbZbUJRg9blvQTpNBslTkEqeGnbOs53CJA73xNyU4n1B8h8n apJznEGy2VNYk7wvpcbtTJlvc6ZUud2YXvoGt427nZvN5XJpXDLn4gQunovltbyaV/FRvILneS5I fjhcYZOdJkehAmE5eoKX8WyQvIiZzGlyTMo89hLP8BQPfGww/Ec0XgKxQXJ0RC2mMHFSJqVkQXLs RCTrmMfGiClGEqgpMY0BhkARnoJ5ECCPBGWwPa63wlihLdeUVHm/KmiSJNfDtK/+GYk1sK+2viEw aPUHcsVE2Oq/Xtx4PfGVcc8GFLVVpqXVLt50ord7dbuvzeFrcvjakJoCD/d2GAN9LXb78dXdosAe oF1NLSs7xLi5LdDtaPMGVju89uO9Ur0Z4nZR3OvwHod235KG4+2eNu9wr6fX52j2+k+0VK5vnNbX zqm+1ld+SV+VYmPrxb5apHoz+moUxS1iX41iX41iXy2eFqkvcfC+zvrKe3rQOu2+zlp7ILk+MHfR 8oaAvdnvDZJDmOndAOwYqNlXIJntAzOTBTaA8AdIH4px6Lbwn9nXQR3qCv8PXYqTOioSFaoogzF4 BJ6CIZDBYUwnwx0wAOfJalzbK2AE3iMJkIm+l4EgzIe3SDj8NrTD81i+B87CXjgOUVinC/Qo3U2c 4c3IezDdAtvC34ckKIZvwytQgq3uhvHwkfAJlC6G22AQjmL9nxEHdZzRhV8MXwQeFmGb21Dydnh+ eAi0kA6VsBBzt8EZ4qQ/DHeAEUpRu6fhWTgIr8LfyQNkJNwR7g1fCH+MpmoEC9Tjs4WMkI/pIebb 4afDfwuHEIlkSMVem2APPIftD+Ezhq7VR9aQHrKH7KU81APUCLOdNYQmEIcUqManBr3yQ4jAKJyD f8A/yaeUkVbTPfRPwwXh/wUl1OIoxZG0QS8+O/DZjWM6TWQkm8whC8kW8gTZS35NpVK3UQ3URupe 6s90Hb2C3kT/mrmHGWZ3sQMyZeiz8Onw6+F3wQBWuB3Ww1Yc3Vm4AJfhKqGxLQtxklJSSe7Ap488 RY2Sg2SUWkjGyAVqkPyBfEI+Jdcoloqi9FQa1UPtoY5SZ6lf0J30XvpJ+g/0Z0w5S7EH2UsyJ/fb UEtoZ+gX4dLwx+HP0cXyIODMVEId3AnNONpuyIdv4SiO4TOEs3YOfgrnpecTYoFx+BxRAKIlZpJL FuBTR24l7aSTPENO4XNG0uUKhRNBySkNZaAsVD3VQnVRfdS7VB8dT6fS8+jl9BA+b9Dv0dfoawzL 6Bg9U83MhV1MF3MAn0PMYWaY+SVbwpazdexSto/dye6iV7Jvs+/Jtsp2y4Zln8r+G93ifG4dtwtn 5zza7Ktoy//6MSQJtc+Fu2Al8ZIW2IezcZA0Qz9aVyt5CPHqhuRwI72Vrqay0RrOwH+gtR6ALbCT XgEHw7+hB+F9tJS12GQfvMBUgpXdj7PzAGSjFU0+npTUlGS3y5nkSBTs6PIt8WaT0RCnj9VpNero KKVCznMylqEpAuk+R1WTPeBqCjAuR01Nhsg7mjGj+YaMJlzK9kDV9DIBu1ivGUXTSnqwZPuMkp5I Sc9USaK2l0FZRrrd57AHfu512INk+aIGTD/idfjtgXEpvUBKf0dKR2NaELCC3Wfs8NoDpMnuC1T1 dvT7mrwZ6WTUg3AoMtJFx+EBpdhwAOY0b0EHC3PEEr6A2eH1BUwOTKOMdvqaWwMLFzX4vPGC4Mc8 zFrcgH1kpHcGUE94OKrV0fpw0AMtTWKqeUVDgG72B6gmsS1NWsDg8AYMmy8Z/8VeT/l23SAMUM6q 5rb+qoCn6WEEV2SbRK55F3K19XZsltrubwiQ7ZNKiDquRk1FdSN7grNptT0gd1Q6OvpXNyG4sLhh 2OwxS843AAsbhk0ek8RkpI8at5YKOPrRjNkZs8W4VDBujcR/eTCS/6sxMTZuPfdHjGsXTwFARAQc c1HPgH2l1IkDlS0Wg7Zi6F9ZjDjhz09wmJ2oz5wAhTZDOwOsc25zoK/+uhod3ohyTau9w3KTWdqE Kv1YvqlffQvOFJZXO+z9n+Fu3eQY//v0nObJHJlT/RmIQnGip2wlQJqvp3vFzdKJo+4wOjrE+e2V 5hR5h9F3QwbyIjSizoFY3MAXNggBux8z8G0yvTYI8oUNxwnZ7Q+S8PYgeK2j+I5K33kHitNFU+v0 Yv/IZKRjRqqAqcx0exX2XCXair3f3j+3td9eZe9AY2KcUoyCtn5/FiJY34A4wRLs0eOPn0q2+f23 YDtZYjtYBYv3+7GF1ZMtYCxlZU1goex03Exp18KGRQ2BPm98wOP14yyg+Y4tbAiMoeX6/VgqZ0pT 1HhLp3FS51zUOScV5XmRVvDdpQ+b8Pf3i23WNziEwFh/f3y/uN4ifJDAzAzPZEYQxCIi5EHStxDr YuQQ4qU5EBwCquUXMc1Hk75uUfjO/vUIF07pjTWLUNtCCeHibwjhkptB+JabQrh0StNpCJehzqUi wrP+fQiXT0O44usR9kzpjUrORm09EsKV3xDCc24GYe9NIeyb0nQawlWos09EuPrfh3DNNITnfj3C 86b0RiVrUdt5EsLzvyGEF9wMwnU3hfCtU5pOQ3gh6nyriPCifx/Ci6chXP/1CC+Z0huVvA21XSIh vPQbQnjZzSDccFMI+6c0nYbwctTZLyJ8+xTCnvgA3OiH+2a4XfjGHfOKGyDHNyVWC5VUCR6cS2CQ uQc8SOekGMDBfAICphcjFSNtI6/DTmoQduLhuxL5Poz12MT1u58oPJGcQd4Oy8Wj+Jf+qMlcGs9p 7JeW+OpM2ZeIuC/Ji2RFrp/kk3LFZKy8oXwU3vYAqCZzYqQ4H08W7fAOnmm+Td4gV6gxOp2+j36G vsicYxNY8WaNwnMIMBfw/ErjPVhF5G6Kz8IXCCQe76rgApLIY5r+KAgMkniHxX0Ep7AGwNK0U9gK i3F2Tp5G0LiRKpndwS/+xL5ydU6QWXAN7zkQwcHQBdIHH6KGGZ44cKgUrbxCbTCYuXxFK/CmmJVt xrQ69eUFZRPjdb4275+hYsH4O+M52YbCosKCfJfbUZCnj5Vxgz5LDKG63mvqfTvqtoxUTsl9+ObG EXHiUAtP+APGwg5ADJ5I7/YYdrCkitcXxLCWAi5aW0yvMxYrE6qt6t5zxnfGJ8ahYrwCO5izyZMP 8dEu4jS75E7WFacyJkMsaJNJPI8ptQxThih9MtFRGJgUlmTQMBiI9wNEDKTf/Xh9aIjTqDlKsLtd mvwiraAt1ORTjkRKE2uIy6M99zUt2xr6Uyi0tbOilxT0H7r32LN7smpeZAcuHQ+9Ffrox6H/+uNp Unp5iFRdvfQ5WXyZlIbeDf3ut9t/Jo6N4KkQqHfZx/H06DjOkyDJ80QxDBfFcPtYUFTLxUGde3ei BCoqLv88J1tXUE6K8jQOzbmfHHDtHqOv9Ov8h67eRV+R2vLgnCew34VEOOSpK2SqmGXsGutdCZsT tpEdFJ/KLzetMd1nus/yIxMLiSSGsahMAmcx4V0ga4uJSdQpCnSs3bZBSIwSvsUVx61LVLlj7rcV JyZVOyLgXh5XfzZ+ESrKJsoqxjXakiytoYRgrC0p0WAAjRLsFsYU5dS4lFpVMshjOQSXiVYrkgmv xwDxVaslfBHaQm0FidiBI5GTcQ5MC7lafSwniyEyzBD0wrztr47dn79435bRahfzEl25gSRf+WRT 1Y92thS3mmnVFymjRNu9rragfs2WPbtqt5/uvRC68twPN1e3zS/MWbZ6UMLFEf6A7sK1oINKT6Jc ZpKtUm6W7afYexkilzNaKvpxRq5xglmvcHKmWH2QLDoh7OrG67K6ywvG69RXFkg2hcPF8TUS1E5I dM0iaLdxebloxZo8uquoPfSnH/zt9Jq7n81J+Ck5eWrVyycudXbeu6lrzin61+I8Czg351EHDvI9 ZiJLAI5ieDkuFLhG0U6WuSYz8bvuiKyVy4jv5cnVUlG2YKIsJ5voBZx1oYA5H9K8GdKwrwxd/Qer GsLh4QpfHP5IOvXH4H1OGfzOU5yaTRRqZXyUxZ1Xo+6Ur1ZzJbw2Sk7H53JJcqs6ylqaRmWmlL5U SpXmpjq1ao7lLe5EgyVI+j0Og9XGua2ZSspaoCzjysossVxK6uEkc3l8imVejLvYNKv8ZbIfBzRK 9sEkSJclmC5OnEOQ0FRxAVaMj2tLNGgfjWgfmeOZ46KdaAwlkoUkFxbpE4GYnKQwRgBjQrwAcfZY gQiJUEQJYLYaBBwwBuJqJOoycSnefz8aDGlMkjCfRVREMhH9NPspJ3m5eG2gEScGu1ARR6Lb5RYj V0F+YZGOqNbX3enfJ3TkdrXk1JORcn3Ug5sfKRUUh9n/e+6V3g0GZ1SCJjXd1ZgaJy/6xX17Xzm1 v/+Xy9PnHnpMb5Gpoi1Zq8haPt2YsaJ+fmr9a0/V1AxM7Lck0vT2KFmlw1Oz+kcP7X1eRy6KPqs4 /CE9zp7Fmy0rbPTkFqmqVctULzBH4lknH0vFWNXAW62cTkFZDUo2U5epTtFozTal22xKsO0Q1lf+ y/rQAC7imhsXYdXgOpMQNBstcgUQYlS6QG7BAEyUCxTxvAvXFv4ltLQiDOhkHYkyPXoxgwY9R4GI BhTka/OuPH5wy8FDmx86Qvrrs2cd+37FD9edCF399Pfkzr++f/5nP7nwJlWUn1BLWa+W713ZQDKu /o0sQzvehgYnjisO6j3pMo7jDZyBdzNu3QZuA8/roikdOm2NVcbpoxTRKQqzkehTIM5kMOIXjBNC S2Rcok1Prit0JDiqEqLFcUGjLk+DPiAyiQ5NvltSXePYNuLJW/bAf9ZnjCbk7Og+OcKenfhokVDy nP+ZiUXUc71FDQfem3hDXAsEdmIwS9r3UjyoCa1gcY0RKgVoE8MOTlMgsh1VoFdFXHaOjIgb2/U2 qMeZatDArR6Xm3ZFF9HVDKPi1ZRKrpFHuXmWA5lGwZt1RJw3MGl1QeLD0W2VZk2csDo17nQVCyrO TZxDu5ecZGR8etFG4wz6TJwGmR77Pap/fg1rtKrj1Q89PsJkjRY+RdFnaGpo/cSAaEeV4ffpk0wt 3hpnkUzPo8XyAXaf9snYAf1Aqiw5yekuFKqE6qRq99KkZe72pFWuTVGbojepeh09ST3OHtehhMPp OhqUejaDydShh4s3WIz6jNjM5BhlJ+9yFjopZ2K0gknTGV+zWHUcY808kKbM4uQqNcVBlpBlthnj jG5DebKLcyebc1Q2t7oc3Jmm7Jxh4VDj9dU/USLO5kSJ+vIErvmSkpIscbGXiLvWuOgJRD9wt2S3 80kG5dLjliyobALI8XMModPRl7CpmLJqMS8+1igQe0yiAEKiKpp3KwTicsoVJIMR8BscBgkai0BM cRhIe7W6DP2DFEzbtdFV6OJwgxYXgNuVRVxu0QWIlsU5MC2Cj/u3jWAZfP9AB+Emn/JO7+HWgVnu ex7dObvnt6P/WDOHGmRd5U+2d/qS6zaerez84Pefvs6Rl8jC5dnLlt3uS4qzJiWmzr1/4OXdyztm 5VbXeapSTTprVrrviUcvfPA96p84f33hT+jf442sAe/T7/DcEox9I5aS6/hYk84UmyzbSL+PSwhY lQJk0QrWqlUaOaNRGRedqUiJUprNJCXOZDL/6rrZSruRaF4Ib8TPVpSJgIumRRqJ9EYS2ZE0jiLc QEX3V6BxkmJz9oMve50jg5Qjf9WeS/UZZIjJmihZnN90ePl3KdW1t5+ZlbrkycU7qd+YRZvTh+bS f0WdjWCCNz139esfMr5gpDmZQVasrdE2aFdxG+mN3K7YAdjPDuj3x+03HIbDceoaqNVXG87rGS/7 GkvtYA/BIfICe9jAJiWzRr0hjoBMH6WMsfIqE2cyxcXjwmSBDBn0xqGoR+NM5vh3hFXiCjLhtnvR OFFSgn+TtA0aI8NFC8s1ZRkrysrKxDWFH6k8Wr0e4uK6tAaDkSWkSwtg3JGZpt5yTop4jEkjWt7d pBERypPRFEdJk12QgMuwsAjfpkgeoWnhddeDLZVP9z3tSknISlXnZqnZclWo5y1iI0zWqtBjob+/ GGofkfHPR8sEI/9EElP3xQD9gIiV9Au34XeLL/vhtz/cn2PwzSMWTyEZUARe/BZSC7fil46l0AAr pEoEv85EziIy/F4N85bU1i73ptW0re1t6+lc2YxlIlKxcA3SEqRWJPFbOPpjeALpeSTxzf8c0jtI F5EuY0UGKRYpCSk/PPlDGUylCdhn8Okz+OwZfM4MPncGP28Gv2QGL47oxv5bZ/AdM3jx28GN5dfP 4O+ZwW+YwW8S+f8H30KhIwplbmRzdHJlYW0KZW5kb2JqCjE1NCAwIG9iago1MzE3CmVuZG9iagox NTUgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgNzcwIC9DYXBIZWlnaHQg NzE3IC9EZXNjZW50IC0yMzAgL0ZsYWdzIDMyCi9Gb250QkJveCBbLTk1MSAtNDgxIDE0NDUgMTEy Ml0gL0ZvbnROYW1lIC9KVEtLWkQrSGVsdmV0aWNhIC9JdGFsaWNBbmdsZSAwCi9TdGVtViAwIC9B dmdXaWR0aCAtNDQxIC9NYXhXaWR0aCAxNTAwIC9YSGVpZ2h0IDUyMyAvRm9udEZpbGUyIDE1MyAw IFIgPj4KZW5kb2JqCjE1NiAwIG9iagpbIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAg MCAwIDU1NiA1NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAw IDAgMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1 NgowIDAgNTU2IDAgMCAwIDU1NiAwIDAgMCAyMjIgMCAwIDAgMCAwIDMzMyA1MDAgMCA1NTYgMCAw IDAgNTAwIF0KZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL0pUS0taRCtIZWx2ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjE1NSAwIFIgL1dp ZHRocyAxNTYgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMSAvRW5jb2RpbmcgL01hY1Jv bWFuRW5jb2RpbmcKPj4KZW5kb2JqCjE1NyAwIG9iagooTWFjIE9TIFggMTAuNi44IFF1YXJ0eiBQ REZDb250ZXh0KQplbmRvYmoKMTU4IDAgb2JqCihBcHBsZSBLZXlub3RlIDUuMSkKZW5kb2JqCjE1 OSAwIG9iagooRDoyMDExMDcyMTIzMzAxOVowMCcwMCcpCmVuZG9iagoxIDAgb2JqCjw8IC9Qcm9k dWNlciAxNTcgMCBSIC9DcmVhdG9yIDE1OCAwIFIgL0NyZWF0aW9uRGF0ZSAxNTkgMCBSIC9Nb2RE YXRlIDE1OSAwIFIKPj4KZW5kb2JqCnhyZWYKMCAxNjAKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAw MDQzNTMyIDAwMDAwIG4gCjAwMDAwMDA1MzIgMDAwMDAgbiAKMDAwMDAyMDYyMiAwMDAwMCBuIAow MDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDA1MTMgMDAwMDAgbiAKMDAwMDAwMDYzNyAwMDAwMCBu IAowMDAwMDAxNjcwIDAwMDAwIG4gCjAwMDAwMDI1NjYgMDAwMDAgbiAKMDAwMDAzNzE0MyAwMDAw MCBuIAowMDAwMDIxNjU5IDAwMDAwIG4gCjAwMDAwNDMyMjIgMDAwMDAgbiAKMDAwMDAwMDc4OCAw MDAwMCBuIAowMDAwMDAwODQyIDAwMDAwIG4gCjAwMDAwMDE2NTAgMDAwMDAgbiAKMDAwMDAwMTcw NiAwMDAwMCBuIAowMDAwMDAyNTQ2IDAwMDAwIG4gCjAwMDAwMDMyNDIgMDAwMDAgbiAKMDAwMDAw MjYwMiAwMDAwMCBuIAowMDAwMDAzMjIyIDAwMDAwIG4gCjAwMDAwMDMzNTAgMDAwMDAgbiAKMDAw MDAyMTQ5NSAwMDAwMCBuIAowMDAwMDA0MDMwIDAwMDAwIG4gCjAwMDAwMDM1MDIgMDAwMDAgbiAK MDAwMDAwNDAxMCAwMDAwMCBuIAowMDAwMDA0MTM4IDAwMDAwIG4gCjAwMDAwMjE4MTggMDAwMDAg biAKMDAwMDAwNDkwNyAwMDAwMCBuIAowMDAwMDA0MjkwIDAwMDAwIG4gCjAwMDAwMDQ4ODcgMDAw MDAgbiAKMDAwMDAwNTAxNSAwMDAwMCBuIAowMDAwMDIxMjU0IDAwMDAwIG4gCjAwMDAwMDU3MjMg MDAwMDAgbiAKMDAwMDAwNTE2NyAwMDAwMCBuIAowMDAwMDA1NzAzIDAwMDAwIG4gCjAwMDAwMDU4 MzEgMDAwMDAgbiAKMDAwMDAyMTk0MCAwMDAwMCBuIAowMDAwMDA2NjM2IDAwMDAwIG4gCjAwMDAw MDU5ODMgMDAwMDAgbiAKMDAwMDAwNjYxNiAwMDAwMCBuIAowMDAwMDA2NzQ0IDAwMDAwIG4gCjAw MDAwMjE3NzggMDAwMDAgbiAKMDAwMDAwNzQxMyAwMDAwMCBuIAowMDAwMDA2ODk2IDAwMDAwIG4g CjAwMDAwMDczOTMgMDAwMDAgbiAKMDAwMDAwNzUyMSAwMDAwMCBuIAowMDAwMDIxNjE5IDAwMDAw IG4gCjAwMDAwMDg0MzUgMDAwMDAgbiAKMDAwMDAwNzY3MyAwMDAwMCBuIAowMDAwMDA4NDE1IDAw MDAwIG4gCjAwMDAwMDg1NDMgMDAwMDAgbiAKMDAwMDAyMTQxNSAwMDAwMCBuIAowMDAwMDA5Mzk1 IDAwMDAwIG4gCjAwMDAwMjA3NDYgMDAwMDAgbiAKMDAwMDAwODY5NSAwMDAwMCBuIAowMDAwMDA5 Mzc1IDAwMDAwIG4gCjAwMDAwMDk1MDQgMDAwMDAgbiAKMDAwMDAyMTMzNSAwMDAwMCBuIAowMDAw MDEwMjU0IDAwMDAwIG4gCjAwMDAwMDk2NTYgMDAwMDAgbiAKMDAwMDAxMDIzNCAwMDAwMCBuIAow MDAwMDEwMzYzIDAwMDAwIG4gCjAwMDAwMjExNzQgMDAwMDAgbiAKMDAwMDAxMTEzMCAwMDAwMCBu IAowMDAwMDEwNTE1IDAwMDAwIG4gCjAwMDAwMTExMTAgMDAwMDAgbiAKMDAwMDAxMTIzOSAwMDAw MCBuIAowMDAwMDIxODU4IDAwMDAwIG4gCjAwMDAwMTIwMTQgMDAwMDAgbiAKMDAwMDAxMTM5MSAw MDAwMCBuIAowMDAwMDExOTk0IDAwMDAwIG4gCjAwMDAwMTIxMjMgMDAwMDAgbiAKMDAwMDAyMTQ1 NSAwMDAwMCBuIAowMDAwMDEyNzgwIDAwMDAwIG4gCjAwMDAwMTIyNzUgMDAwMDAgbiAKMDAwMDAx Mjc2MCAwMDAwMCBuIAowMDAwMDEyODg5IDAwMDAwIG4gCjAwMDAwMjEyMTQgMDAwMDAgbiAKMDAw MDAxMzY0NCAwMDAwMCBuIAowMDAwMDEzMDQxIDAwMDAwIG4gCjAwMDAwMTM2MjQgMDAwMDAgbiAK MDAwMDAxMzc1MyAwMDAwMCBuIAowMDAwMDIxNzM4IDAwMDAwIG4gCjAwMDAwMTQ2NDIgMDAwMDAg biAKMDAwMDAxMzkwNSAwMDAwMCBuIAowMDAwMDE0NjIyIDAwMDAwIG4gCjAwMDAwMTQ3NTEgMDAw MDAgbiAKMDAwMDAyMTM3NSAwMDAwMCBuIAowMDAwMDE1NDcwIDAwMDAwIG4gCjAwMDAwMTQ5MDMg MDAwMDAgbiAKMDAwMDAxNTQ1MCAwMDAwMCBuIAowMDAwMDE1NTc5IDAwMDAwIG4gCjAwMDAwMjEx MzQgMDAwMDAgbiAKMDAwMDAxNjM0NCAwMDAwMCBuIAowMDAwMDIwODcyIDAwMDAwIG4gCjAwMDAw MTU3MzEgMDAwMDAgbiAKMDAwMDAxNjMyNCAwMDAwMCBuIAowMDAwMDE2NDUzIDAwMDAwIG4gCjAw MDAwMjE2OTggMDAwMDAgbiAKMDAwMDAxNzIxMCAwMDAwMCBuIAowMDAwMDE2NjA1IDAwMDAwIG4g CjAwMDAwMTcxODkgMDAwMDAgbiAKMDAwMDAxNzMyMSAwMDAwMCBuIAowMDAwMDIxMjk0IDAwMDAw IG4gCjAwMDAwMTgxMTEgMDAwMDAgbiAKMDAwMDAxNzQ3NCAwMDAwMCBuIAowMDAwMDE4MDkwIDAw MDAwIG4gCjAwMDAwMTgyMjMgMDAwMDAgbiAKMDAwMDAyMTg5OCAwMDAwMCBuIAowMDAwMDE4OTU0 IDAwMDAwIG4gCjAwMDAwMTgzNzYgMDAwMDAgbiAKMDAwMDAxODkzMyAwMDAwMCBuIAowMDAwMDE5 MDY2IDAwMDAwIG4gCjAwMDAwMjE1NzcgMDAwMDAgbiAKMDAwMDAyMDIyNCAwMDAwMCBuIAowMDAw MDE5MjE5IDAwMDAwIG4gCjAwMDAwMjAyMDMgMDAwMDAgbiAKMDAwMDAyMDM1MiAwMDAwMCBuIAow MDAwMDIxNTM1IDAwMDAwIG4gCjAwMDAwMjA1MDUgMDAwMDAgbiAKMDAwMDAyMzk0MiAwMDAwMCBu IAowMDAwMDIzNzgwIDAwMDAwIG4gCjAwMDAwMjM2MTggMDAwMDAgbiAKMDAwMDAyMzM5NiAwMDAw MCBuIAowMDAwMDIzMjM0IDAwMDAwIG4gCjAwMDAwMjMwNzIgMDAwMDAgbiAKMDAwMDAyMjkxMCAw MDAwMCBuIAowMDAwMDIyNjg4IDAwMDAwIG4gCjAwMDAwMjI1MjYgMDAwMDAgbiAKMDAwMDAyMjM2 NCAwMDAwMCBuIAowMDAwMDIyMjAyIDAwMDAwIG4gCjAwMDAwMjE5ODAgMDAwMDAgbiAKMDAwMDAy MDk4MCAwMDAwMCBuIAowMDAwMDIxMDgxIDAwMDAwIG4gCjAwMDAwMjIwODQgMDAwMDAgbiAKMDAw MDAyMjE0MiAwMDAwMCBuIAowMDAwMDIyMzA2IDAwMDAwIG4gCjAwMDAwMjI0NjggMDAwMDAgbiAK MDAwMDAyMjYzMCAwMDAwMCBuIAowMDAwMDIyNzkyIDAwMDAwIG4gCjAwMDAwMjI4NTAgMDAwMDAg biAKMDAwMDAyMzAxNCAwMDAwMCBuIAowMDAwMDIzMTc2IDAwMDAwIG4gCjAwMDAwMjMzMzggMDAw MDAgbiAKMDAwMDAyMzUwMCAwMDAwMCBuIAowMDAwMDIzNTU4IDAwMDAwIG4gCjAwMDAwMjM3MjIg MDAwMDAgbiAKMDAwMDAyMzg4NCAwMDAwMCBuIAowMDAwMDI0MDQ2IDAwMDAwIG4gCjAwMDAwMjQx MDQgMDAwMDAgbiAKMDAwMDAzNjMxNCAwMDAwMCBuIAowMDAwMDM2MzM3IDAwMDAwIG4gCjAwMDAw MzY1ODcgMDAwMDAgbiAKMDAwMDAzNzMxOCAwMDAwMCBuIAowMDAwMDQyNzI3IDAwMDAwIG4gCjAw MDAwNDI3NDkgMDAwMDAgbiAKMDAwMDA0Mjk5MSAwMDAwMCBuIAowMDAwMDQzMzk5IDAwMDAwIG4g CjAwMDAwNDM0NTIgMDAwMDAgbiAKMDAwMDA0MzQ4OSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl IDE2MCAvUm9vdCAxMzMgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw4YzkzMzY1NmQ0MmYwZGQ4YjRi MWZlNDE5MmNiNTVmYj4KPDhjOTMzNjU2ZDQyZjBkZDhiNGIxZmU0MTkyY2I1NWZiPiBdID4+CnN0 YXJ0eHJlZgo0MzYyNwolJUVPRgo= --Apple-Mail-7-123998376-- --Apple-Mail-8-123998412 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcyMTIzMzI0 NFowIwYJKoZIhvcNAQkEMRYEFICYayUWMFWOSqzi7rz5caB/uYbuMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBtQySaCSAnhiHWa8mR7AGMRLq2FEqamWhHxmH68IcjFh7xP4xQNviZFeqU 6xG0t0uYLf3spppMR0pQ0mUiSVTwLWZ1lnKzqHkdcs7cpIGxtHJFgKYPq/FaVXHeTfFo6XNBQO3n 52qervsAVnExeGElET2FL2svpthL4f7qDh3ER1y4i9XCii7NbNG4dRolj7aMnGQFpJDjm70Mv7YQ 4Cr8g8XV07rgOEtxVNoFzvnsIA7hwGHg7Q5He3KG0/9cT8+nbPd/q1I7MFOkSdsN8ljgPRQQIsEX gerUh/FGFVsCHOgjKkt4E5sylzcYbhsZOb+6XdGA31eLC1dIQ5KO5homAAAAAAAA --Apple-Mail-8-123998412-- From justin@affinix.com Thu Jul 21 16:48:01 2011 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 8D88711E807D for ; Thu, 21 Jul 2011 16:48:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvuqQfzb1WX2 for ; Thu, 21 Jul 2011 16:48:00 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4593E11E8071 for ; Thu, 21 Jul 2011 16:47:56 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id D8E21284071 for ; Thu, 21 Jul 2011 16:47:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=F 3OVLUobgZCXF7GsU08n5YPfsJygyoSMYNQ9U+X7of5PVb5tdTDbaCo7To60wG1h2 DQz4+B546R9iVZbO6hbRTMYKqTSxl1BH8ab/EjJYNp3/9xoB4kJPf/ZUkL67VB3U XvOj9er4ryACzlywQws+572wfaWWDJLwe4r1fPc3C4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=DV6jKxD qyAENsaMm094KbKUjfwY=; b=OJLe/o9JiHw+qXbNPejXG8Bj18uJiHRN1rXkVw3 gBgdVBCoskmz3cvlZIuop5vVaTzn8XSejbmj6T8P9ofiazacl96gMyg1zaAkxGTr sZHFdUvZxUT+8zuE+nqCKoh1FxaulK4A1JGXFOaFgarcodtTGIE3nnXKbMNLIYP3 v4nA= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id CBB5E28406C for ; Thu, 21 Jul 2011 16:47:55 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Thu, 21 Jul 2011 16:47:54 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.2; x86_64; ; ) References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> In-Reply-To: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107211647.54651.justin@affinix.com> Subject: Re: [xmpp] E2E 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: Thu, 21 Jul 2011 23:48:01 -0000 I like this, especially the part about packaging the signed stanza into the e2e blob. This avoids canonicalization problems. Btw, the approach is almost the same as what I documented long ago: http://xmpp.org/extensions/inbox/secure.html If I had the energy I would still try to push this XEP (JEP?), since it seems the e2e discussion has come all the way back around to single stanza security again. Oh well, maybe some useful ideas from it can be taken instead. On Thursday, July 21, 2011 04:32:43 PM Matt Miller wrote: > Attached is the current version of my current slides. > > > - m&m > > Matt Miller - > Collaboration Software Group - Cisco Systems, Inc. From waqas20@gmail.com Thu Jul 21 17:48:26 2011 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 1C6C421F86AF for ; Thu, 21 Jul 2011 17:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPvxiP8jsr4k for ; Thu, 21 Jul 2011 17:48: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 8B1B021F86AD for ; Thu, 21 Jul 2011 17:48:25 -0700 (PDT) Received: by yxp4 with SMTP id 4so1081339yxp.31 for ; Thu, 21 Jul 2011 17:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LaiCWVtheea05dDmUi58tk7b2l05Ja/mWumnyGd+MyA=; b=XiocSgepEkuWFxEiMeKEGskiVWSBm6J18eO3c2nSTNonz6jWHHBqzvLwj5Wjbafaxe xhC/7DCJKdEd/injaHe1UQ6WjXHsxKLFJckxbg8wfPuxXriSwokZP9DyOaKmVnK/B1LH SOZloLD0fBRaG0D2Gstll8jjIJscZy7hxNPIQ= Received: by 10.150.179.18 with SMTP id b18mr1346174ybf.130.1311295705096; Thu, 21 Jul 2011 17:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.16 with HTTP; Thu, 21 Jul 2011 17:48:05 -0700 (PDT) In-Reply-To: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> From: Waqas Hussain Date: Fri, 22 Jul 2011 05:48:05 +0500 Message-ID: To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Group Subject: Re: [xmpp] E2E 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: Fri, 22 Jul 2011 00:48:26 -0000 On Fri, Jul 22, 2011 at 4:32 AM, Matt Miller wrote: > Attached is the current version of my current slides. > > > - m&m > > Matt Miller - > Collaboration Software Group - Cisco Systems, Inc. > I'm not sure if this is the appropriate time or place to question this, but I'll just go ahead. Question: What threat does this form of E2E attempt to protect the end users from? Given the dependence on PEP, any MITM (including the servers of the users) can render this useless. So if this isn't attempting to protect against the servers or any other MITM with the ability to modify the stream, what exactly is this protecting against? What am I missing here? And what does PEP gain us here? Wouldn't querying the contact's resource for the public key work better, since it could possibly generate a key (possibly based on out-of-band communication)? This would also mean separate clients could have separate keys, thus the compromise of one client machine would not cause a leak of a critical private key of the user, just that one client's. -- Waqas Hussain From ben@nostrum.com Thu Jul 21 20:23:28 2011 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 ABD28228010 for ; Thu, 21 Jul 2011 20:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-6oDlTsFD+a for ; Thu, 21 Jul 2011 20:23:18 -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 297A311E8075 for ; Thu, 21 Jul 2011 20:23:17 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6M3ND72011471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Jul 2011 22:23:13 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Thu, 21 Jul 2011 22:23:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01C7963F-EC92-4511-930E-822472182472@nostrum.com> References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> To: Waqas Hussain X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: XMPP Group Subject: Re: [xmpp] E2E 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: Fri, 22 Jul 2011 03:23:28 -0000 On Jul 21, 2011, at 7:48 PM, Waqas Hussain wrote: > I'm not sure if this is the appropriate time or place to question > this, but I'll just go ahead. [actual discussion ellided] I'd argue that this is the _best_ place to question things, as it's the = list of record for the working group :-) The more we have out in the = open on the list, the faster the f2f meeting will go. Thanks! Ben.= From stpeter@stpeter.im Thu Jul 21 20:30:29 2011 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 B1F7511E8079 for ; Thu, 21 Jul 2011 20:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE14uSi2vIyd for ; Thu, 21 Jul 2011 20:30:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 509E511E8075 for ; Thu, 21 Jul 2011 20:30:29 -0700 (PDT) Received: from squire.local (unknown [216.17.175.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 918FE4005A; Thu, 21 Jul 2011 21:31:11 -0600 (MDT) Message-ID: <4E28EECF.2010904@stpeter.im> Date: Thu, 21 Jul 2011 21:30:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ben Campbell References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> <01C7963F-EC92-4511-930E-822472182472@nostrum.com> In-Reply-To: <01C7963F-EC92-4511-930E-822472182472@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Group Subject: Re: [xmpp] E2E 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: Fri, 22 Jul 2011 03:30:29 -0000 On 7/21/11 9:23 PM, Ben Campbell wrote: > > On Jul 21, 2011, at 7:48 PM, Waqas Hussain wrote: > >> I'm not sure if this is the appropriate time or place to question >> this, but I'll just go ahead. > > [actual discussion ellided] > > I'd argue that this is the _best_ place to question things, as it's the list of record for the working group :-) The more we have out in the open on the list, the faster the f2f meeting will go. +1 From mamille2@cisco.com Fri Jul 22 06:46:29 2011 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 118F921F8520 for ; Fri, 22 Jul 2011 06:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFMioBRreIJ2 for ; Fri, 22 Jul 2011 06:46:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5459621F8512 for ; Fri, 22 Jul 2011 06:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4581; q=dns/txt; s=iport; t=1311342388; x=1312551988; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=oqXrIkyTrE/SGs7EQa4hvcCVO98aJb0BJ0pS0cp2u2c=; b=YX50tjK65ZPYitt6qszSWoVUqwLGk2MdMhw5DSYQ8nTzQ2HafPqp2+Ym QZOUnDFyqhjqClBcp0oCfpznxuv7QdIR8pvXYmUr0bXIZQQHDl6/6FSt4 YG1ogKz1Sz4apIG5EAPhglkSd1kskeSQ3shdBwD5Kpf1qofWcMJDRnrtp I=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHx+KU6rRDoH/2dsb2JhbABTp0l3iHwEnQqeM4VgXwSHVYsZkH4 X-IronPort-AV: E=Sophos;i="4.67,247,1309737600"; d="p7s'?scan'208";a="5491406" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2011 13:46:27 +0000 Received: from dhcp-64-101-72-203.cisco.com (dhcp-64-101-72-203.cisco.com [64.101.72.203]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6MDkRRG031480; Fri, 22 Jul 2011 13:46:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2-175221404; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <201107211647.54651.justin@affinix.com> Date: Fri, 22 Jul 2011 07:46:26 -0600 Message-Id: References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> <201107211647.54651.justin@affinix.com> To: Justin Karneges X-Mailer: Apple Mail (2.1084) Cc: xmpp@ietf.org Subject: Re: [xmpp] E2E 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: Fri, 22 Jul 2011 13:46:29 -0000 --Apple-Mail-2-175221404 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you for taking the time to look at the slides. Further comments inline... On Jul 21, 2011, at 17:47, Justin Karneges wrote: > I like this, especially the part about packaging the signed stanza = into the=20 > e2e blob. This avoids canonicalization problems. Canonicalization is one issue most of the other object-based proposals = haven't really addressed. I think this sidesteps the issue altogether, = which might help adoption. >=20 > Btw, the approach is almost the same as what I documented long ago: > http://xmpp.org/extensions/inbox/secure.html >=20 I had forgotten about that one! After a quick read, it looks like I'm = following a fairly similar pattern, but using the octet-string = representation of the stanza as the input data for encrypting/signing. > If I had the energy I would still try to push this XEP (JEP?), since = it seems=20 > the e2e discussion has come all the way back around to single stanza = security=20 > again. Oh well, maybe some useful ideas from it can be taken instead. >=20 As stpeter would say, "the more the merrier!" (-: - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-2-175221404 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcyMjEzNDYy N1owIwYJKoZIhvcNAQkEMRYEFOESM3LY/6hYNc07FmR/z2ohqtbLMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBrCZTCb7wokgnRuelSLcNgOdNml6lfYX1L/wEVuAdm25kQoeasDIoOOykB /NTM3VfU1QJMrT9vkm0KM2ygeR16pc0BBu7nzRQ1FMwxOD3hAC8k2k6yOn2KzIXSeELQGgRxHfAz lgAnXPcRyNA8KSZKFq91ATmEUVAncZbKvy/0rapk6nftUZnfIE4McYrRLFXNh1xUQl+GVRTKi9q/ +fnABaaG3RWCaT16Ry5vLprLKYdtYgNnImlI/Yyf9yjbC+u44YyjQjEgu2o4SReXojVKCWjPM6zE Qj8O6n60ATlPFJojx/lcM/XbicgK9j8ZDCWalxWKFCbWMowEFPllaxIQAAAAAAAA --Apple-Mail-2-175221404-- From mamille2@cisco.com Fri Jul 22 07:04:11 2011 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 5BD0B21F8793 for ; Fri, 22 Jul 2011 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x1miBy5oWIE for ; Fri, 22 Jul 2011 07:04:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 965B721F867A for ; Fri, 22 Jul 2011 07:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5019; q=dns/txt; s=iport; t=1311343450; x=1312553050; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=5beYeLx25PEdRmCzyuxD+0xe/bxlhyHGJJVHyjqeRKI=; b=dbwc3UA0UVjXJ+GU//HCWAJ2cNkiBHDMS6CGCqESgCiuRzlXRdUa1zoj pZdRwhPFK7lKEBCl1+d/ytxKzivUCDFv3/TZAapI2OeywJI6C6ZDWKpwz T2MlZ2iGkRnK88rVltGHbexfApWZQXCD+8htXuHzrlHo9dwLpXTEilhay 0=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABqCKU6rRDoI/2dsb2JhbABTp0l3iHydDZ4zhWBfBIdVixmQfg X-IronPort-AV: E=Sophos;i="4.67,247,1309737600"; d="p7s'?scan'208";a="5496954" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2011 14:04:10 +0000 Received: from dhcp-64-101-72-203.cisco.com (dhcp-64-101-72-203.cisco.com [64.101.72.203]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6ME49Ai026785; Fri, 22 Jul 2011 14:04:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3-176283483; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: Date: Fri, 22 Jul 2011 08:04:08 -0600 Message-Id: <86F453A1-F69F-4AE3-911A-9C57B345A6F3@cisco.com> References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> To: Waqas Hussain X-Mailer: Apple Mail (2.1084) Cc: XMPP Group Subject: Re: [xmpp] E2E 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: Fri, 22 Jul 2011 14:04:11 -0000 --Apple-Mail-3-176283483 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 21, 2011, at 18:48, Waqas Hussain wrote: > On Fri, Jul 22, 2011 at 4:32 AM, Matt Miller = wrote: >> Attached is the current version of my current slides. >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Collaboration Software Group - Cisco Systems, Inc. >>=20 >=20 > I'm not sure if this is the appropriate time or place to question > this, but I'll just go ahead. >=20 > Question: What threat does this form of E2E attempt to protect the end > users from? >=20 > Given the dependence on PEP, any MITM (including the servers of the > users) can render this useless. So if this isn't attempting to protect > against the servers or any other MITM with the ability to modify the > stream, what exactly is this protecting against? What am I missing > here? >=20 > And what does PEP gain us here? Wouldn't querying the contact's > resource for the public key work better, since it could possibly > generate a key (possibly based on out-of-band communication)? This > would also mean separate clients could have separate keys, thus the > compromise of one client machine would not cause a leak of a critical > private key of the user, just that one client's. >=20 Using PEP has a number of advantages: * The public keys can be obtained whether the user is online or offline. * Updating keys automatically notifies the interested parties. It does mean that you need to trust PEP data. It might (should?) be = possible to take other steps to verify the public keys. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-3-176283483 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcyMjE0MDQw OVowIwYJKoZIhvcNAQkEMRYEFAXKJDDnEMR7qlyoi1YJUlK0gG1JMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBAAnnWpKhsH+zqLYK5umAZknXQHblS3MfiFc7RWJxMsJ/W+FEJSU6H7bWD EEOjLPCo8JsSX6NyNqRElD93bpOjjUQ07ztRTnxPu3jnWgcy9oRa01zZjfwHlZ/DWosXhU7s/Pqr krasMQa8fc08IvtcRwkxpCckltM/mkJ6Dwxm62XlHYrUCMiz6SOqBOXVEkhkFReKrmajx8nl9PV5 kMf8KEUKwvpLXEO9UjHsVB0GwcPv0yVV0t9+7i5yBjp1qoJsIPcpyyCKpHXAgTkOqYYBFm7Uqy6u fZce3Vq6JCXk8XBTzx5xNwJR554KfD56oRNW5sQIbBOhLzLevElID+M+AAAAAAAA --Apple-Mail-3-176283483-- From duerst@it.aoyama.ac.jp Fri Jul 22 00:51:40 2011 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 B16C221F865F for ; Fri, 22 Jul 2011 00:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.54 X-Spam-Level: X-Spam-Status: No, score=-99.54 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-5jaOY5U4Nl for ; Fri, 22 Jul 2011 00:51:40 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id E674621F8658 for ; Fri, 22 Jul 2011 00:51:39 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p6M7pXJv021979 for ; Fri, 22 Jul 2011 16:51:33 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 4e78_2e2d_6b2fd062_b437_11e0_8576_001d096c5b62; Fri, 22 Jul 2011 16:51:33 +0900 Received: from [IPv6:::1] ([133.2.210.5]:55854) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 22 Jul 2011 16:51:36 +0900 Message-ID: <4E292BC3.30301@it.aoyama.ac.jp> Date: Fri, 22 Jul 2011 16:50:27 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 22 Jul 2011 07:17:47 -0700 Cc: xmpp@ietf.org, apps-discuss@ietf.org Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 22 Jul 2011 07:51:40 -0000 Hello Joe, On 2011/07/22 1:28, Joe Hildebrand wrote: > On 7/21/11 1:03 AM, "Martin J. Dürst" wrote: > >> Slide 123: Good to see that. By the way, I seem to remember both John > and me >> begging you for an explanation of why Jabber wants to use NFD a > few months >> ago, and I'm not sure I have seen an answer. Now might be a > good time (if you >> already sent one, a pointer would be appreciated). > > > Let me try. Glad to start talking. > First some assumptions: > - Stringprep is currently one of the performance hotspots of some XMPP > servers. Is that an assumption backed by facts or a wild guess? > - XMPP does not guarantee that the original form of the address that is > entered by the user or sent on the first hop is transmitted without > modification to other hops in the system. > - As such, many XMPP servers optimize by performing canonicalization at the > edges of their system and even store the canonical version for future > comparison. Makes sense. > - If the spec is written that clients SHOULD perform canonicalization, many > in our community will, particularly if they know that they will get better > performance from the server. That's the same for NFC and NFD, isn't it? The advantage of NFC is that it's designed to more-or-less match what's out there, so you get the advantage that there is more stuff that's already canonicalized even if if a client doesn't do anything. That gets reinforced by both the IETF and the W3C telling everybody to use NFC. > The property of NFK?D that we like is that if you have a string of > codepoints that is already in NFK?D, you can check that the string is in the > correct normalization form without having to allocate memory. With NFK?C, > you'll have to decompose (allocating memory), recompose (at some finite CPU > cost), then recompose (possibly allocating *again*) just to check if you > have already done the normalization. Nope. That's just how the algorithm was defined, because the decomposition component was already around, and NFD was what defined canonical equivalence. As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has some code (both UTF-8 and UTF-16) for compact (memory footprint) and reasonably fast NFC check. Please ignore the "XML 1.1" in the title. Also please note that this is proof of concept code, and may need additional testing and of course upgrade to the newest version of Unicode. I don't have any open bug reports, but that may be for other reasons than that there are no bugs. Also, there are various ways to trade off speed against memory (see also Björn's mail), but the memory here is just the footprint of the sharable data, there's no need for lots of memory per conversion. > For the K portion, I have found John's argument compelling that codepoints > with compatibility decompositions should just be prohibited in our > localparts. Probably just fine for most cases. Potentially a problem for wide/narrow in places like Japan. > In our resourceparts, I'm of the opinion that we don't need to > compatibility map -- it's fine for all of those codepoints to stay distinct. Yes indeed. > The idea is that clients SHOULD normalize, servers double-check inputs from > non-trusted sources (like clients and other servers), then always store and > forward the normalized version. That's fine. But it doesn't explain the choice of NFD (vs. NFC). Regards, Martin. From k.i.smith@gmail.com Fri Jul 22 07:26:08 2011 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 55A1A21F8519 for ; Fri, 22 Jul 2011 07:26:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtkKWHm+L6Nd for ; Fri, 22 Jul 2011 07:26:07 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD3E521F8514 for ; Fri, 22 Jul 2011 07:26:07 -0700 (PDT) Received: by qyk9 with SMTP id 9so4994501qyk.10 for ; Fri, 22 Jul 2011 07:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gwJDpN4Ok5nD/2510n3dpbmACdOe1dEVSEL2vPWXvbI=; b=jsE59uvgI1Oz91pY75JswKFK80m6qKy5mDjCsP1tCJDTuAcpyg0tvUK0lm1VPd2yq1 gSeKDvglZgkx4ZY0fTZ0+pM+fRAA/BcKBZ5rP3Hu8IkUVitnkrHtyXLc2b5V5Os1Ch+c u78H/m3+s6zM41g3JIK2qQXd59HyqpZZgbf9Y= MIME-Version: 1.0 Received: by 10.229.182.84 with SMTP id cb20mr1288081qcb.6.1311344767282; Fri, 22 Jul 2011 07:26:07 -0700 (PDT) Sender: k.i.smith@gmail.com Received: by 10.229.183.66 with HTTP; Fri, 22 Jul 2011 07:26:07 -0700 (PDT) In-Reply-To: <86F453A1-F69F-4AE3-911A-9C57B345A6F3@cisco.com> References: <6754D815-31C1-4591-BBDD-882FF78DB369@cisco.com> <86F453A1-F69F-4AE3-911A-9C57B345A6F3@cisco.com> Date: Fri, 22 Jul 2011 15:26:07 +0100 X-Google-Sender-Auth: 0L6slGCeDxaHJcz68WCKtuZYMls Message-ID: From: Kevin Smith To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Group Subject: Re: [xmpp] E2E Slides 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: Fri, 22 Jul 2011 14:26:08 -0000 On Fri, Jul 22, 2011 at 3:04 PM, Matt Miller wrote: > On Jul 21, 2011, at 18:48, Waqas Hussain wrote: > >> On Fri, Jul 22, 2011 at 4:32 AM, Matt Miller wrote: >>> Attached is the current version of my current slides. >>> >>> >>> - m&m >>> >>> Matt Miller - >>> Collaboration Software Group - Cisco Systems, Inc. >>> >> >> I'm not sure if this is the appropriate time or place to question >> this, but I'll just go ahead. >> >> Question: What threat does this form of E2E attempt to protect the end >> users from? >> >> Given the dependence on PEP, any MITM (including the servers of the >> users) can render this useless. So if this isn't attempting to protect >> against the servers or any other MITM with the ability to modify the >> stream, what exactly is this protecting against? What am I missing >> here? >> >> And what does PEP gain us here? Wouldn't querying the contact's >> resource for the public key work better, since it could possibly >> generate a key (possibly based on out-of-band communication)? This >> would also mean separate clients could have separate keys, thus the >> compromise of one client machine would not cause a leak of a critical >> private key of the user, just that one client's. >> > > Using PEP has a number of advantages: > > * The public keys can be obtained whether the user is online or offline. > * Updating keys automatically notifies the interested parties. > > It does mean that you need to trust PEP data. =A0It might (should?) be po= ssible to take other steps to verify the public keys. Using PEP seems to make a lot of sense to me - I'm assuming that whatever the mechanism for retrieving keys they're still going to need to be verified in some manner. /K From Joe.Hildebrand@webex.com Fri Jul 22 08:26:20 2011 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 61AE321F8511; Fri, 22 Jul 2011 08:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfwfaMKjsDGM; Fri, 22 Jul 2011 08:26:19 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by ietfa.amsl.com (Postfix) with SMTP id 8C17521F8510; Fri, 22 Jul 2011 08:26:19 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 08:26:18 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jul 2011 15:26:18 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 22 Jul 2011 09:26:17 -0600 From: Joe Hildebrand To: "Martin J. =?ISO-8859-1?B?RPxyc3Q=?=" Message-ID: Thread-Topic: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 Thread-Index: AcxIg7MfGf6kV+3Dnk+rFdfkWLCijw== In-Reply-To: <4E292BC3.30301@it.aoyama.ac.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2011 15:26:18.0175 (UTC) FILETIME=[B3D2BCF0:01CC4883] Cc: apps-discuss@ietf.org, xmpp@ietf.org Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 22 Jul 2011 15:26:20 -0000 On 7/22/11 1:50 AM, "Martin J. D=FCrst" wrote: >> First some assumptions: >> - Stringprep is currently one of the performance hotspots of some XMPP >> servers. >=20 > Is that an assumption backed by facts or a wild guess? I can only talk definitively about one server, but yes, I've got data to back up that assumption for that one server. >> - If the spec is written that clients SHOULD perform canonicalization, m= any >> in our community will, particularly if they know that they will get bett= er >> performance from the server. >=20 > That's the same for NFC and NFD, isn't it? The advantage of NFC is that > it's designed to more-or-less match what's out there, so you get the > advantage that there is more stuff that's already canonicalized even if > if a client doesn't do anything. That gets reinforced by both the IETF > and the W3C telling everybody to use NFC. Absolutely. However, my point is that our client community, unlike the MUA community (for example) is more likely to adopt change. >> The property of NFK?D that we like is that if you have a string of >> codepoints that is already in NFK?D, you can check that the string is in= the >> correct normalization form without having to allocate memory. With NFK?= C, >> you'll have to decompose (allocating memory), recompose (at some finite = CPU >> cost), then recompose (possibly allocating *again*) just to check if you >> have already done the normalization. >=20 > Nope. That's just how the algorithm was defined, because the > decomposition component was already around, and NFD was what defined > canonical equivalence. >=20 > As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has > some code (both UTF-8 and UTF-16) for compact (memory footprint) and > reasonably fast NFC check. Please ignore the "XML 1.1" in the title. > Also please note that this is proof of concept code, and may need > additional testing and of course upgrade to the newest version of > Unicode. I don't have any open bug reports, but that may be for other > reasons than that there are no bugs. Am I correct that the key bit of your algorithm is: """Check for potential combination with starter. The list of recombinations is calculated so that any combining character that would lead to a change (full combination, recombination so that the combining character gets combined in but another combining character is separated, complete decomposition,...) is listed. 2176 such pairs have been found.""" Can you talk more about that? Do we expect that future versions of Unicode will change that set of pairs? > Probably just fine for most cases. Potentially a problem for wide/narrow > in places like Japan. Yup. That's why the wide/narrow stuff is still on the list of questions to be addressed with this approach. I also fully expect that there are N othe= r codepoints that are marked as having compatibility decomposition but are actually in widespread use, and someone's going to complain about them one day. >> The idea is that clients SHOULD normalize, servers double-check inputs f= rom >> non-trusted sources (like clients and other servers), then always store = and >> forward the normalized version. >=20 > That's fine. But it doesn't explain the choice of NFD (vs. NFC). One other point, the re-composition stuff in the C forms *is* objectively more difficult to implement, and will *always* take more CPU. If it's not required, it should be avoided. And I haven't seen any compelling argument= s as to why C should be preferred. What I've seen so far: - That's the way we've always done it. Not compelling to me if we're going to switch away from NFKC in any way. - Saves a few bytes on the wire. Not compelling in a world with compression. (see: http://xmpp.org/extensions/xep-0138.html) - More likely to render correctly. Not with today's font renderers. Are there any others I'm missing? --=20 Joe Hildebrand From dave@cridland.net Fri Jul 22 08:44:41 2011 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 9BBB321F8B33; Fri, 22 Jul 2011 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puzmNQdbtw+N; Fri, 22 Jul 2011 08:44:41 -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 AFCC921F8B32; Fri, 22 Jul 2011 08:44:40 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BB19E1168087; Fri, 22 Jul 2011 16:44:39 +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 hZUmzvipEKQ2; Fri, 22 Jul 2011 16:44:36 +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 A683E1168067; Fri, 22 Jul 2011 16:44:35 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <9031.1311349475.663904@puncture> Date: Fri, 22 Jul 2011 16:44:35 +0100 From: Dave Cridland To: Joe Hildebrand , General discussion of application-layer protocols , XMPP Working Group , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 22 Jul 2011 15:44:41 -0000 On Fri Jul 22 16:26:17 2011, Joe Hildebrand wrote: > On 7/22/11 1:50 AM, "Martin J. Dürst" > wrote: > > >> First some assumptions: > >> - Stringprep is currently one of the performance hotspots of > some XMPP > >> servers. > > > > Is that an assumption backed by facts or a wild guess? > > I can only talk definitively about one server, but yes, I've got > data to > back up that assumption for that one server. I have no opinion on NFC versus NFD, but on this specific point it is true for our server as well, and I'm aware of at least one other server for which stringprep is a key area of CPU usage (Not Joe's). 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 Fri Jul 22 14:36:32 2011 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 1A04321F87E2 for ; Fri, 22 Jul 2011 14:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpRiG0AD26ei for ; Fri, 22 Jul 2011 14:36:31 -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 10EBC21F8754 for ; Fri, 22 Jul 2011 14:36:30 -0700 (PDT) Received: from dn3-227.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 p6MLaRK2016487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Jul 2011 16:36:28 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <8FBA40FC-D268-4C1B-880A-BAFB4FE94537@nostrum.com> Date: Fri, 22 Jul 2011 16:36:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FBA40FC-D268-4C1B-880A-BAFB4FE94537@nostrum.com> To: XMPP Group X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Joe Hildebrand Subject: [xmpp] Minutes Taker(s) and Chatroom Scribes 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, 22 Jul 2011 21:36:32 -0000 To reiterate the call for minutes takers and XMPP scribe: Please? Thanks! Ben. On Jul 21, 2011, at 3:50 PM, Ben Campbell wrote: > Hi Everyone >=20 > Due to our shortened schedule, we will need to be as efficient as we = can in getting the meeting moving, changing speakers, etc. To that end: >=20 > Presenters: Please get slides to the chairs as much in advance as you = can, so we can have everything up and ready on one laptop. >=20 > Minutes: Can we get one or two volunteers for minutes in advance of = the meeting? This could could several minutes of time where the chairs = usually look hopefully at the participants until someone gives in :-) = For minutes, we primarily need a transcript of issues, major discussion = points, and issue resolutions. A blow-by-blow transcript is not required = (but doesn't hurt). >=20 > Jabber Scribe: Can we get one or two jabber scribes. The jabber scribe = mainly needs to enter speaker information in the chatroom, and bring any = remote-participant comments to the microphone. >=20 > (Note that we can combined the minutes taker and jabber scribe roles = if the jabber scribe enters sufficient detail.) >=20 >=20 > Thanks! >=20 > Ben. >=20 >=20 > Begin forwarded message: >=20 >> From: "Richard L. Barnes" >> Subject: [xmpp] Combining XMPP and GEOPRIV >> Date: July 19, 2011 4:56:48 PM CDT >> To: XMPP Working Group , GEOPRIV WG >>=20 >> Dear XMPP and GEOPRIV participants, >>=20 >> A brief agenda update, which should be reflected on the official = agenda soon: >>=20 >> In order to resolve the conflict between XMPP and GEOPRIV on Tuesday = morning of the IETF meeting, the chairs of the two groups have decided = to run their sessions in sequence instead of in parallel. The = 150-minute morning session will be divided into two 75-minute sessions. >>=20 >> XMPP: 09:00 - 10:15 >> GEOPRIV: 10:15 - 12:30 >>=20 >> Both session will be held in room 206A, the room previously assigned = for the GEOPRIV session. The agendas for the individual sessions will = of course be posted on the meeting materials pages. >>=20 >> Sincerely, >> GEOPRIV and XMPP co-chairs >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From duerst@it.aoyama.ac.jp Sun Jul 24 22:38:38 2011 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 77D1421F85C0 for ; Sun, 24 Jul 2011 22:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.524 X-Spam-Level: X-Spam-Status: No, score=-100.524 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTD5JOP5A08I for ; Sun, 24 Jul 2011 22:38:37 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B521F8785 for ; Sun, 24 Jul 2011 22:38:36 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p6P5cX16021522 for ; Mon, 25 Jul 2011 14:38:33 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 018a_199a_560f694a_b680_11e0_9e03_001d096c566a; Mon, 25 Jul 2011 14:38:33 +0900 Received: from [IPv6:::1] ([133.2.210.5]:59236) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 25 Jul 2011 14:38:32 +0900 Message-ID: <4E2D0124.9040602@it.aoyama.ac.jp> Date: Mon, 25 Jul 2011 14:37:40 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joe Hildebrand References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 25 Jul 2011 06:55:42 -0700 Cc: apps-discuss@ietf.org, xmpp@ietf.org Subject: Re: [xmpp] [apps-discuss] i18n intro, Sunday 14:00-16:00 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, 25 Jul 2011 05:38:38 -0000 Hello Joe, On 2011/07/23 0:26, Joe Hildebrand wrote: > On 7/22/11 1:50 AM, "Martin J. Dürst" wrote: > >>> First some assumptions: >>> - Stringprep is currently one of the performance hotspots of some XMPP >>> servers. >> >> Is that an assumption backed by facts or a wild guess? > > I can only talk definitively about one server, but yes, I've got data to > back up that assumption for that one server. Okay, thanks for the confirmation. >>> - If the spec is written that clients SHOULD perform canonicalization, many >>> in our community will, particularly if they know that they will get better >>> performance from the server. >> >> That's the same for NFC and NFD, isn't it? The advantage of NFC is that >> it's designed to more-or-less match what's out there, so you get the >> advantage that there is more stuff that's already canonicalized even if >> if a client doesn't do anything. That gets reinforced by both the IETF >> and the W3C telling everybody to use NFC. > > Absolutely. However, my point is that our client community, unlike the MUA > community (for example) is more likely to adopt change. Yes, but there's no need to adopt change without a really good reason. And there should be no need for XMPP to differ from the rest of the IETF. BTW, can you tell us what programming language the server is written in? Are you using any kinds of libraries for character-related business? >>> The property of NFK?D that we like is that if you have a string of >>> codepoints that is already in NFK?D, you can check that the string is in the >>> correct normalization form without having to allocate memory. With NFK?C, >>> you'll have to decompose (allocating memory), recompose (at some finite CPU >>> cost), then recompose (possibly allocating *again*) just to check if you >>> have already done the normalization. >> >> Nope. That's just how the algorithm was defined, because the >> decomposition component was already around, and NFD was what defined >> canonical equivalence. >> >> As an example, http://www.w3.org/2003/06/xml1.1test/Overview.html has >> some code (both UTF-8 and UTF-16) for compact (memory footprint) and >> reasonably fast NFC check. Please ignore the "XML 1.1" in the title. >> Also please note that this is proof of concept code, and may need >> additional testing and of course upgrade to the newest version of >> Unicode. I don't have any open bug reports, but that may be for other >> reasons than that there are no bugs. > > Am I correct that the key bit of your algorithm is: In some way, yes. > """Check for potential combination with starter. The list of recombinations > is calculated so that any combining character that would lead to a change > (full combination, recombination so that the combining character gets > combined in but another combining character is separated, complete > decomposition,...) is listed. 2176 such pairs have been found.""" > > Can you talk more about that? The actual list is in http://dev.w3.org/cvsweb/~checkout~/charlint/xml1.1test/nf16data.c?content-type=text/plain, in the array 'recombiners'. The first entry is {0x003C, 0x0338}, which is a '<' and a COMBINING LONG SOLIDUS OVERLAY. It's here because there is U+226E, NOT LESS-THAN, which is canonically equivalent, and therefore the sequence U+003C, U+0338 (or any sequence U+003C, [other combining characters], U+0338 ) isn't in NFC. Let's look at another entry: {0x00FC, 0x0300}. This is LATIN SMALL LETTER U WITH DIAERESIS (ü) followed by COMBINING GRAVE ACCENT. This is not in NFC because there is U+01DC, LATIN SMALL LETTER U WITH DIAERESIS AND GRAVE. Another, somewhat more involved example: {0x1EC5, 0x0323}. This is LATIN SMALL LETTER E WITH CIRCUMFLEX AND TILDE and COMBINING DOT BELOW. This is not in NFC because there is U+1EC7, LATIN SMALL LETTER E WITH CIRCUMFLEX AND DOT BELOW, and NFC is U+1EC7 + U+0303 (COMBINING TILDE) because combining characters below have a lower combining class and therefore are preferred when recombining. > Do we expect that future versions of Unicode > will change that set of pairs? This is at least in theory possible. The data is from 2003. With input from the W3C, the Unicode Consortium created a fairly strong stability policies regarding normalization (please see http://www.unicode.org/policies/stability_policy.html, under "Normalization Stability"). As a result, for new precomposed characters, they had to be included in the combining exclusions. That meant that the benefit of proposing them as precomposed characters was lost, and there were virtually no such characters that made it all the way. It's still possible to propose a new script with some precomposed/decomposed alternatives, but I wouldn't know about a case where this has been done. Please note that such additions would also affect decomposition, so a software (table) update would be needed independent of whether you go for NFC or NFD. >> Probably just fine for most cases. Potentially a problem for wide/narrow >> in places like Japan. > > Yup. That's why the wide/narrow stuff is still on the list of questions to > be addressed with this approach. I also fully expect that there are N other > codepoints that are marked as having compatibility decomposition but are > actually in widespread use, and someone's going to complain about them one > day. > >>> The idea is that clients SHOULD normalize, servers double-check inputs from >>> non-trusted sources (like clients and other servers), then always store and >>> forward the normalized version. >> >> That's fine. But it doesn't explain the choice of NFD (vs. NFC). > > One other point, the re-composition stuff in the C forms *is* objectively > more difficult to implement, Yes, but usually, you'd just use a library, and be done with it. > and will *always* take more CPU. Not if most of your data is already in NFC, and you can check that quickly. I do not have actual statistics, but I don't know any major language or script where data would from the start be in NFD. On the other hand, there are examples such as Korean where essentially everything is in NFC, and NFD expands the number of characters by a factor of between 2 and 3, affecting every single character. For other big languages such as Spanish, Portuguese, French, German, Italian, Polish, Japanese,... data is also essentially in NFC, although the characters that would be decomposed are less frequent than the 100% for Korean. > If it's not required, it should be avoided. That's similar to the argument about saving bytes on the wire. It's not compelling in a world with efficient libraries and faster and faster processors. Also, please note that the code at http://www.w3.org/2003/06/xml1.1test/Overview.html isn't really the only way to optimize, and it's just a proof of concept, not really optimized based on actual benchmarks. My guess is that there are things that are "overoptimized" (i.e. too complicated without a corresponding speed gain) and some spots that could still be further optimized. In many cases, checking for all-ASCII first can shave off quite a bit of time. Also, doing a lookup of the string (which I guess has to happen sooner or later anyway) before checking for normalization may speed up things. > And I haven't seen any compelling arguments > as to why C should be preferred. What I've seen so far: > > - That's the way we've always done it. Not compelling to me if we're going > to switch away from NFKC in any way. That may not be compelling on the level of XMPP, but on the level of the IETF or the Internet, it's a different issue. Also, under the assumption that actual characters where NFKC makes a difference are few and far between, NFKC and NFC are quite close. A change from NFKC to NFC may be much smoother than a change from NFKC to NFD. > - Saves a few bytes on the wire. Not compelling in a world with > compression. (see: http://xmpp.org/extensions/xep-0138.html) Agreed. > - More likely to render correctly. Not with today's font renderers. Depends on the exact characters in question. Can go either way. > Are there any others I'm missing? See above (libraries, frequency of data in NFC vs. NFD,...). Regards, Martin. From ben@nostrum.com Mon Jul 25 20:46:25 2011 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 502F711E80BB for ; Mon, 25 Jul 2011 20:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rclOCqYZ4dL for ; Mon, 25 Jul 2011 20:46:24 -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 7772511E8077 for ; Mon, 25 Jul 2011 20:46:24 -0700 (PDT) Received: from [10.0.1.2] ([130.129.65.151]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6Q3kMqb043621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 22:46:23 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Mon, 25 Jul 2011 23:46:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A721CFF-05FE-4A36-BBDC-5DB639295A25@nostrum.com> References: To: XMPP Group X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 130.129.65.151 is authenticated by a trusted mechanism) Cc: Joe Hildebrand Subject: Re: [xmpp] Combining XMPP and GEOPRIV 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, 26 Jul 2011 03:46:25 -0000 Just a reminder, XMPP will meet in tomorrow morning in 206A. This is = most likely different from any printed schedules, although I believe the = electronic ones are up to date. We will share the room with GEOPRIV = according to the schedule below=20 (except for the typo: The time slot runs through 1130, not 1230. ) Cary has graciously agreed to take minutes. We still need a volunteer = for XMPP scribe, and an alternate minute taker would not hurt. Thanks! Ben. On Jul 19, 2011, at 5:56 PM, Richard L. Barnes wrote: > Dear XMPP and GEOPRIV participants, >=20 > A brief agenda update, which should be reflected on the official = agenda soon: >=20 > In order to resolve the conflict between XMPP and GEOPRIV on Tuesday = morning of the IETF meeting, the chairs of the two groups have decided = to run their sessions in sequence instead of in parallel. The = 150-minute morning session will be divided into two 75-minute sessions. >=20 > XMPP: 09:00 - 10:15 > GEOPRIV: 10:15 - 12:30 >=20 > Both session will be held in room 206A, the room previously assigned = for the GEOPRIV session. The agendas for the individual sessions will = of course be posted on the meeting materials pages. >=20 > Sincerely, > GEOPRIV and XMPP co-chairs > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From stpeter@stpeter.im Thu Jul 28 08:08:12 2011 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 E6CB411E8080 for ; Thu, 28 Jul 2011 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ViyyFFkbcuf for ; Thu, 28 Jul 2011 08:08:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 15C3711E8085 for ; Thu, 28 Jul 2011 08:08:12 -0700 (PDT) Received: from dhcp-13ac.meeting.ietf.org (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1100D410E8 for ; Thu, 28 Jul 2011 09:09:11 -0600 (MDT) Message-ID: <4E317B56.6040205@stpeter.im> Date: Thu, 28 Jul 2011 11:08:06 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: XMPP References: <4E317A07.2000706@stpeter.im> In-Reply-To: <4E317A07.2000706@stpeter.im> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <4E317A07.2000706@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: [precis] meeting coordinates 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, 28 Jul 2011 15:08:13 -0000 FYI. Sorry that I didn't send a message like this about the XMPP WG session the other day. -------- Original Message -------- Subject: [precis] meeting coordinates Date: Thu, 28 Jul 2011 11:02:31 -0400 From: Peter Saint-Andre To: precis@ietf.org Just a reminder that the PRECIS WG meeting starts in 2 hours. Here is information for remote participants: Audio: http://ietf81streaming.dnsalias.net/ietf/ietf802.m3u Slides: https://datatracker.ietf.org/meeting/81/materials.html#wg-precis Chatroom: xmpp:precis@jabber.ietf.org?join /psa _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis