From rfc-editor@rfc-editor.org Fri Apr 1 07:51:42 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5C93A687B; Fri, 1 Apr 2011 07:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hp01TgaXC+7; Fri, 1 Apr 2011 07:51:42 -0700 (PDT) Received: from email.elon.edu (efe2.elon.edu [152.33.5.1]) by core3.amsl.com (Postfix) with ESMTP id DD1C13A6875; Fri, 1 Apr 2011 07:51:41 -0700 (PDT) Received: from EV01.elon.edu ([10.17.1.100]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Apr 2011 10:53:22 -0400 Received: from mail pickup service by EV01.elon.edu with Microsoft SMTPSVC; Fri, 1 Apr 2011 10:53:11 -0400 Received: from email.elon.edu ([10.17.1.143]) by EV01.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:34:14 -0400 Received: from emf1.elon.edu ([10.17.20.20]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:34:14 -0400 X-ASG-Debug-ID: 1301524454-0314c70ee440730001-3cnnEG Received: from mail-gy0-f180.google.com (mail-gy0-f180.google.com [209.85.160.180]) by emf1.elon.edu with ESMTP id 0IV2dGMBRqxwncf0 for ; Wed, 30 Mar 2011 18:34:14 -0400 (EDT) X-Barracuda-Envelope-From: ietf-announce-bounces@ietf.org X-Barracuda-Apparent-Source-IP: 209.85.160.180 Received: by gyf2 with SMTP id 2sf997815gyf.11 for ; Wed, 30 Mar 2011 15:34:13 -0700 (PDT) Received: by 10.151.24.21 with SMTP id b21mr2050768ybj.403.1301524453779; Wed, 30 Mar 2011 15:34:13 -0700 (PDT) X-Barracuda-BBL-IP: nil Received: by 10.151.24.21 with SMTP id b21mr2050767ybj.403.1301524453749; Wed, 30 Mar 2011 15:34:13 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id ws4si873340icb.155.2011.03.30.15.34.12; Wed, 30 Mar 2011 15:34:12 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8449E28C1C4; Wed, 30 Mar 2011 15:31:47 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8D43A6BE0; Wed, 30 Mar 2011 15:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XnFySqxIiOt; Wed, 30 Mar 2011 15:31:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 5DAE93A67EE; Wed, 30 Mar 2011 15:31:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BE6F3E0768; Wed, 30 Mar 2011 15:33:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-ASG-Orig-Subj: RFC 6121 on Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence Message-Id: <20110330223314.BE6F3E0768@rfc-editor.org> Date: Wed, 30 Mar 2011 15:33:14 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Barracuda-Connect: mail-gy0-f180.google.com[209.85.160.180] X-Barracuda-Start-Time: 1301524454 X-Barracuda-URL: http://spam.elon.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at elon.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=2.5 QUARANTINE_LEVEL=3.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59444 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-OriginalArrivalTime: 30 Mar 2011 22:34:15.0007 (UTC) FILETIME=[9950DEF0:01CBEF2A] Cc: xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] RFC 6121 on Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence X-BeenThere: xmpp@ietf.org List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:51:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6121 Title: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence Author: P. Saint-Andre Status: Standards Track Stream: IETF Date: March 2011 Mailbox: psaintan@cisco.com Pages: 114 Characters: 244800 Obsoletes: RFC3921 I-D Tag: draft-ietf-xmpp-3921bis-20.txt URL: http://www.rfc-editor.org/rfc/rfc6121.txt This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK] This document is a product of the Extensible Messaging and Presence Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From rfc-editor@rfc-editor.org Fri Apr 1 07:53:43 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DFB3A6875; Fri, 1 Apr 2011 07:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edkLmdPFjFG1; Fri, 1 Apr 2011 07:53:42 -0700 (PDT) Received: from email.elon.edu (efe2.elon.edu [152.33.5.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAFA3A6869; Fri, 1 Apr 2011 07:53:42 -0700 (PDT) Received: from EV01.elon.edu ([10.17.1.100]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Apr 2011 10:55:22 -0400 Received: from mail pickup service by EV01.elon.edu with Microsoft SMTPSVC; Fri, 1 Apr 2011 10:54:51 -0400 Received: from email.elon.edu ([10.17.1.143]) by EV01.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:33:06 -0400 Received: from emf1.elon.edu ([10.17.20.20]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:33:06 -0400 X-ASG-Debug-ID: 1301524385-0314c70ee440530001-3cnnEG Received: from mail-iw0-f178.google.com (mail-iw0-f178.google.com [209.85.214.178]) by emf1.elon.edu with ESMTP id ZTyEKByLEXQxzdBT for ; Wed, 30 Mar 2011 18:33:05 -0400 (EDT) X-Barracuda-Envelope-From: ietf-announce-bounces@ietf.org X-Barracuda-Apparent-Source-IP: 209.85.214.178 Received: by iwn9 with SMTP id 9sf2270126iwn.23 for ; Wed, 30 Mar 2011 15:33:05 -0700 (PDT) Received: by 10.42.156.2 with SMTP id x2mr1693243icw.310.1301524384981; Wed, 30 Mar 2011 15:33:04 -0700 (PDT) X-Barracuda-BBL-IP: nil Received: by 10.42.156.2 with SMTP id x2mr1693242icw.310.1301524384971; Wed, 30 Mar 2011 15:33:04 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id u12si1308615ibe.130.2011.03.30.15.33.03; Wed, 30 Mar 2011 15:33:03 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7D128C0E8; Wed, 30 Mar 2011 15:31:21 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720EC3A6BE0; Wed, 30 Mar 2011 15:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PowTb6Q38rWV; Wed, 30 Mar 2011 15:31:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C8C2C3A67EE; Wed, 30 Mar 2011 15:31:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 30908E0763; Wed, 30 Mar 2011 15:32:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-ASG-Orig-Subj: RFC 6120 on Extensible Messaging and Presence Protocol (XMPP): Core Message-Id: <20110330223249.30908E0763@rfc-editor.org> Date: Wed, 30 Mar 2011 15:32:49 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Barracuda-Connect: mail-iw0-f178.google.com[209.85.214.178] X-Barracuda-Start-Time: 1301524385 X-Barracuda-URL: http://spam.elon.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at elon.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=2.5 QUARANTINE_LEVEL=3.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59444 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-OriginalArrivalTime: 30 Mar 2011 22:33:06.0752 (UTC) FILETIME=[70A1FC00:01CBEF2A] Cc: xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] RFC 6120 on Extensible Messaging and Presence Protocol (XMPP): Core X-BeenThere: xmpp@ietf.org List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:53:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6120 Title: Extensible Messaging and Presence Protocol (XMPP): Core Author: P. Saint-Andre Status: Standards Track Stream: IETF Date: March 2011 Mailbox: psaintan@cisco.com Pages: 211 Characters: 451942 Obsoletes: RFC3920 I-D Tag: draft-ietf-xmpp-3920bis-22.txt URL: http://www.rfc-editor.org/rfc/rfc6120.txt The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] This document is a product of the Extensible Messaging and Presence Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From rfc-editor@rfc-editor.org Fri Apr 1 07:57:11 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020093A6878; Fri, 1 Apr 2011 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPVawZktQDQw; Fri, 1 Apr 2011 07:57:10 -0700 (PDT) Received: from email.elon.edu (efe2.elon.edu [152.33.5.1]) by core3.amsl.com (Postfix) with ESMTP id CD5BA3A6839; Fri, 1 Apr 2011 07:57:09 -0700 (PDT) Received: from EV01.elon.edu ([10.17.1.100]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Apr 2011 10:58:34 -0400 Received: from mail pickup service by EV01.elon.edu with Microsoft SMTPSVC; Fri, 1 Apr 2011 10:57:08 -0400 Received: from email.elon.edu ([10.17.1.143]) by EV01.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:35:31 -0400 Received: from emf1.elon.edu ([10.17.20.20]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Mar 2011 18:35:31 -0400 X-ASG-Debug-ID: 1301524529-0314c70eeb40bb0001-3cnnEG Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by emf1.elon.edu with ESMTP id HWaFCDyjTQIww7l1 for ; Wed, 30 Mar 2011 18:35:29 -0400 (EDT) X-Barracuda-Envelope-From: ietf-announce-bounces@ietf.org X-Barracuda-Apparent-Source-IP: 209.85.213.54 Received: by ywf9 with SMTP id 9sf848600ywf.13 for ; Wed, 30 Mar 2011 15:35:28 -0700 (PDT) Received: by 10.150.215.16 with SMTP id n16mr2099629ybg.224.1301524528934; Wed, 30 Mar 2011 15:35:28 -0700 (PDT) X-Barracuda-BBL-IP: nil Received: by 10.150.215.16 with SMTP id n16mr2099627ybg.224.1301524528905; Wed, 30 Mar 2011 15:35:28 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id m21si14199498ybn.77.2011.03.30.15.35.27; Wed, 30 Mar 2011 15:35:27 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64713A67EE; Wed, 30 Mar 2011 15:32:06 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0963A6BE0; Wed, 30 Mar 2011 15:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE+YBC1Sk4SJ; Wed, 30 Mar 2011 15:32:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2D6EF3A67EE; Wed, 30 Mar 2011 15:32:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E72BE0768; Wed, 30 Mar 2011 15:33:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-ASG-Orig-Subj: RFC 6122 on Extensible Messaging and Presence Protocol (XMPP): Address Format Message-Id: <20110330223334.8E72BE0768@rfc-editor.org> Date: Wed, 30 Mar 2011 15:33:34 -0700 (PDT) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Barracuda-Connect: mail-yw0-f54.google.com[209.85.213.54] X-Barracuda-Start-Time: 1301524529 X-Barracuda-URL: http://spam.elon.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at elon.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=2.5 QUARANTINE_LEVEL=3.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59444 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-OriginalArrivalTime: 30 Mar 2011 22:35:31.0871 (UTC) FILETIME=[C72162F0:01CBEF2A] Cc: xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] RFC 6122 on Extensible Messaging and Presence Protocol (XMPP): Address Format X-BeenThere: xmpp@ietf.org List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:57:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6122 Title: Extensible Messaging and Presence Protocol (XMPP): Address Format Author: P. Saint-Andre Status: Standards Track Stream: IETF Date: March 2011 Mailbox: psaintan@cisco.com Pages: 23 Characters: 50646 Updates: RFC3920 I-D Tag: draft-ietf-xmpp-address-09.txt URL: http://www.rfc-editor.org/rfc/rfc6122.txt This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. [STANDARDS-TRACK] This document is a product of the Extensible Messaging and Presence Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From stpeter@stpeter.im Thu Apr 7 15:27:09 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8C73A6965 for ; Thu, 7 Apr 2011 15:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2+mfs1AzacA for ; Thu, 7 Apr 2011 15:27:08 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0277E3A67E5 for ; Thu, 7 Apr 2011 15:27:08 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5A21440D62 for ; Thu, 7 Apr 2011 16:31:23 -0600 (MDT) Message-ID: <4D9E3AA1.2010806@stpeter.im> Date: Thu, 07 Apr 2011 16:28:49 -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 X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010608070305040905050405" Subject: [xmpp] common IDN mappings X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:27:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010608070305040905050405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've started working on rfc6122bis (yes, already!). I think we need to define common mappings for internationalized domain names (IDNs) so that we have consistent treatment across the XMPP network. These mappings will go beyond what is defined for IDNA2008 (RFC 5895 is optional for generic IDNA applications but IMHO we want to be more specific for XMPP, and we might want different mappings anyway). I am thinking about the following ordered list of operations to be applied to IDNs: 1. Map uppercase and titlecase characters to their lowercase equivalents. (I.e., we would not preserve case in XMPP, as is done in IDNA2008 and domain name processing more generally; this is consistent with the traditional approach in the XMPP community.) 2. Map all characters using Unicode Normalization Form D (NFD). (By contrast, RFC 5895 suggests NFC.) However, I've run into a bit of a snag. It seems that IDN is more strongly tied to NFC than I had realized: http://www.alvestrand.no/pipermail/idna-update/2011-April/007042.html The upshot seems to be that we will need to define XMPP domainparts without reference to U-labels or even IDN (!) if we want to say that XMPP uses NFD. In essence we would have 4 different layers of string processing: 1. Raw string =3D a UTF-8 encoded string of Unicode code points to which no case mapping or normalization has been applied. This is the kind of string that a client might receive from the operating system as a result of user input or somesuch. 2. Domainpart =3D a UTF-8 encoded string of Unicode code points that has been case-mapped to lowercase and to which Normalization Form D has been applied. A raw string would be converted into a domainpart by lowercasing and then normalizing via NFD. Only domainparts (not raw strings, not U-labels, not A-labels) would be communicated over the wire in XMPP. 3. U-label =3D a UTF-8 encoded string of Unicode code points that has bee= n case-mapped to lowercase and to which Normalization Form C has been applied. A domainpart would be converted into a U-label by performing the recomposition part of NFC. A U-label might be communicated from an XMPP application (e.g., client or server) to a DNS API that can take U-labels as input. However, it's necessary to do this only when the application needs to resolve a domain name via DNS, not during normal XMPP processing. 4. A-label =3D an ASCII string that is generated by applying the Punycode= algorithm (RFC 3492) to a U-label and then adding the ACE prefix ("xn--"). I think the conversion from U-label to A-label could be performed by an IDN-aware DNS API, but it's possible that an XMPP application would need to complete this conversion (again, only when the application needs to resolve a domain name). IMHO this four-fold taxonomy would minimize the work an XMPP application would need to do when handling domain names on the XMPP network, while enabling us to convert domain names into U-labels or A-labels only when absolutely necessary. However, I might be missing some subtleties here, so feedback is welcome. One wrinkle is that we'd need to write 6122bis so that domainparts don't reference U-labels or even IDNs (because IDNs are defined in terms of either A-labels or U-labels and we don't want a dependency on NFC if we can avoid it). This might be a challenge for the spec writer, but shouldn't bother implementers much... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010608070305040905050405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQw NzIyMjg0OVowIwYJKoZIhvcNAQkEMRYEFEiS6dw+zzY2EWd9P37DeiVJ51ARMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBINy6YkWaWXj4qyPkNH0SgxPuo3UKO6duFvYiXEl5aj0P52ysQfd3zkJfD nsYNayARH07PpiHg6q7nfsSlvVmp4sv0f3vOsETHPZDGktvwjP4sSH6DdfSN3J+fq/Uc3TUo H/F6QkIr+cedJaRbbLWuF3tkiFxY3ADQmgv79PUsIiW7+2uiX7QDhCt1d59kx0neekhcS0B0 chmAuDKHNwco7vVSYkg0MYRy771gtbV2RyvU0m7GEJQTKLKbixkEgzJVs6JJhKX78/qCsccG FV1pOLY4HM9+0nlPic1NpJhtzcdSmIUicT6knbhHwsUg+e28FuJw3D0SGra0rA08mCEFAAAA AAAA --------------ms010608070305040905050405-- From jehan.marmottard@gmail.com Sat Apr 9 11:47:20 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F7E3A6955 for ; Sat, 9 Apr 2011 11:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KruuFbzJbKT6 for ; Sat, 9 Apr 2011 11:47:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 68ACC3A6841 for ; Sat, 9 Apr 2011 11:47:19 -0700 (PDT) Received: by wwa36 with SMTP id 36so3736819wwa.13 for ; Sat, 09 Apr 2011 11:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sTOu09K08taDR5cWbzKGhfuY5qR+CdNahVQl7gJlMdI=; b=kQ02AwsmDfvsDWjS8bjyduR6zntB4i6D/pX0yrDk7rqF3yivL7nwF7hR55UVAkWSsu 9azuE3Fx3t0ti7k6u292BUAlOMWuBl6MR8Ln6CAe9VnM/mDrYewxNyROv8R6UPbSNhRp q4aRSlS5rvVTZg0WS/4/Dxnv3bhnuaDlxxPvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=t7gGC9VCeBynJF6WXkIIV7UkKrYAuwKeVixiZH3MG8ZLoLj99irUI90cs8OM1hqWBp cnxqzXmv1KXP3HVbqnaUF5DEDJ2XPCufQWw2nmB4mvNdoMV4nQe9s/tMpUvlnZy9X9O3 xfcG8ixauj2BIApIxXgFw9+60poHppJaFCcfE= MIME-Version: 1.0 Received: by 10.216.18.194 with SMTP id l44mr1075399wel.87.1302374944904; Sat, 09 Apr 2011 11:49:04 -0700 (PDT) Received: by 10.216.29.194 with HTTP; Sat, 9 Apr 2011 11:49:04 -0700 (PDT) In-Reply-To: <4D9E3AA1.2010806@stpeter.im> References: <4D9E3AA1.2010806@stpeter.im> Date: Sun, 10 Apr 2011 03:49:04 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre , XMPP Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [xmpp] common IDN mappings X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 18:47:20 -0000 Hi, On Fri, Apr 8, 2011 at 7:28 AM, Peter Saint-Andre wrote: > I've started working on rfc6122bis (yes, already!). I think we need to > define common mappings for internationalized domain names (IDNs) so that > we have consistent treatment across the XMPP network. These mappings > will go beyond what is defined for IDNA2008 (RFC 5895 is optional for > generic IDNA applications but IMHO we want to be more specific for XMPP, > and we might want different mappings anyway). > > I am thinking about the following ordered list of operations to be > applied to IDNs: > > 1. Map uppercase and titlecase characters to their lowercase > equivalents. (I.e., we would not preserve case in XMPP, as is done in > IDNA2008 and domain name processing more generally; this is consistent > with the traditional approach in the XMPP community.) I agree with this. Though I do like to be precise about cases when I write, for the Internet in general, one knows people don't really care. So that would be basically a security risk to difference cases. Making all cases equivalent prevent people being lured by a user taking the same nick with different case. > 2. Map all characters using Unicode Normalization Form D (NFD). (By > contrast, RFC 5895 suggests NFC.) > [...] For all the rest, I will have to re-read any necessary RFCs related to IDNs as I did this some time ago. Jehan From jehan.marmottard@gmail.com Sun Apr 10 11:30:39 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E948A3A69A8 for ; Sun, 10 Apr 2011 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQTB998TlWXs for ; Sun, 10 Apr 2011 11:30:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E59513A698B for ; Sun, 10 Apr 2011 11:30:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so4094039wwa.13 for ; Sun, 10 Apr 2011 11:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=3e+PQQ0/+SruEvcubAPZEgR8f3jBSUcCnrwZI3LyLKo=; b=rjT0/i6lgz3uDjDDLKZFMDFFJxGox6wLV0B6qOrXKsBKCmVgKws8skRf+fj698y1Be XxujHOH3HTscVtDx+OL1n6PWGUexaS0FtUtJcqMGIYz18NNk8uRAweCYSAmGF5dMtkW5 sudnyUfvaN9gDFflqffXaKuZaTIUsvkHQQ4qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qtXfzgWfEll8q1DEfMbpv9rbwoxuJn+69hCbtf+q8WSJDvniIkDUSDemEgSvFl9NXT +EosAPRGafZGM5YJxERgdd7cYY1uQ1LwDJIWcx8kJAfpXuJ2eP3DEjNa3fu0QDr4Gspw T1oeuaVl2b/tV1atr7Al3OEsNChWul901UlMs= MIME-Version: 1.0 Received: by 10.216.131.230 with SMTP id m80mr4299052wei.48.1302460238158; Sun, 10 Apr 2011 11:30:38 -0700 (PDT) Received: by 10.216.29.194 with HTTP; Sun, 10 Apr 2011 11:30:38 -0700 (PDT) Date: Mon, 11 Apr 2011 03:30:38 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: XMPP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:30:40 -0000 Hi, as we always see things when it is too late (or at least for the current RFC), but... in "4.7.3. id": =AB For response stream headers, the receiving entity MUST include the 'id' attribute. =BB But the section does not detail any stream error which might be sent if the receiving entity does not include a stream id, nor do I seem to find any stream error in the list which might be usable in such a case. Is that missing? What is supposed to be the reaction of a compliant XMPP implementation here? Thanks. Jehan From mwild1@gmail.com Sun Apr 10 13:42:39 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B6B3A697E for ; Sun, 10 Apr 2011 13:42:39 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcKHfo5qRRbk for ; Sun, 10 Apr 2011 13:42:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BEC9C3A6974 for ; Sun, 10 Apr 2011 13:42:38 -0700 (PDT) Received: by iye19 with SMTP id 19so6233397iye.31 for ; Sun, 10 Apr 2011 13:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zjf/tTS9ZGQEs/gyiifUWbCU2aQuAxEduA/OfzZIjC8=; b=W3InrHbdQ7MHyN7H9+K4KXkFGH4ue6AU7DEX8ezIFaVDDHC1xsmRuFv10jAWCMmzWZ 8SkZ0IWwvD0QKSyrwXH+Ohn0zsjWYRfwjsTnrvtW50ccqv/O6b2JC96aP+x7/XxQ9kn/ dU+qwGzym0jITbiJG8hlsEem0HUVQnvjhbSUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=X4j5x3od4lMpab4kkXd71SzSaFiplfokj2zn7Rl/s1y3GMRchhjMKeY1W4a0FzdBCD kPoLXZa9VRZbSyaPkld+pyHHgjXBKcPdCdbOU+eNAyCGf/8xcJPCnb0YQJBxm1DRde3o CBuJlNWTFiQms/0qrrKs9gBXLvqN8Md5cQ/JE= Received: by 10.42.168.134 with SMTP id w6mr1127195icy.246.1302468158101; Sun, 10 Apr 2011 13:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.180.130 with HTTP; Sun, 10 Apr 2011 13:42:17 -0700 (PDT) In-Reply-To: References: From: Matthew Wild Date: Sun, 10 Apr 2011 21:42:17 +0100 Message-ID: To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 20:42:39 -0000 2011/4/10 Jehan Pag=C3=A8s : > Hi, > > as we always see things when it is too late (or at least for the > current RFC), but... in "4.7.3. id": > > =C2=AB > For response stream headers, the receiving entity MUST include the > =C2=A0 'id' attribute. > =C2=BB > > But the section does not detail any stream error which might be sent > if the receiving entity does not include a stream id, nor do I seem to > find any stream error in the list which might be usable in such a > case. Is that missing? What is supposed to be the reaction of a > compliant XMPP implementation here? If it were the client that could omit the id and not the server, I'd see more reason for a dedicated stream error. However as it is a server that doesn't send the 'id' isn't an XMPP server. After you have established that, what good is 1) continuing to pretend you're doing XMPP 2) informing the server it is not an XMPP server? More useful for a client would be to inform the user that the server is broken, I think. In summary, close the stream - that's a FIN, or (perhaps with or an application-defined error) if you insist on sending an error. I don't think the rarity of this error warrants any special handling or a dedicated error condition though. Regards, Matthew PS. On the other hand... RFC 3920 had and I just noticed that it's still in the 6120 schema - "oops" :) From jehan.marmottard@gmail.com Sun Apr 10 14:23:26 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E3D3A69C6 for ; Sun, 10 Apr 2011 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stRexEXA-7gT for ; Sun, 10 Apr 2011 14:23:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E64053A69A6 for ; Sun, 10 Apr 2011 14:23:24 -0700 (PDT) Received: by wwa36 with SMTP id 36so4157657wwa.13 for ; Sun, 10 Apr 2011 14:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XuxfjsdN2VC0858OaHnCX+a3rbFoX71wLhirl4EJPsQ=; b=MPQoNsoSndgmkcRu+vjveuBSsHczpc+rPSLIyQo49gN0bxfEs1hWpmdMu28+FmktZZ KVZQ3lDLMTo8ot55OzB6zqunX5aLriCz09bieVGgyXRRjjN1fD7a2rBgDzB66yEkjO7/ WQvKkxH006dScGkKvN5Eog0Hn4HB1wu1M9CEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iVp0t4DHkzkh9O2wKxiOOlgW/zMe+wHTCK16rP2llX24Rh3FaqgZdHEoWQaa5WNCOK JSkdlkUCqemdAlvOv1JVSM5ucDSiCDr7XcRpcv02FxH0ZuCZiNotHcwUFZCtuMi1zXsB i4WaKpUUJDn/+6PmYERxPMpcW90U85aMmcP20= MIME-Version: 1.0 Received: by 10.216.131.230 with SMTP id m80mr4429614wei.48.1302470603982; Sun, 10 Apr 2011 14:23:23 -0700 (PDT) Received: by 10.216.29.194 with HTTP; Sun, 10 Apr 2011 14:23:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Apr 2011 06:23:23 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Matthew Wild Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 21:23:26 -0000 Hi, 2011/4/11 Matthew Wild : > 2011/4/10 Jehan Pag=E8s : >> Hi, >> >> as we always see things when it is too late (or at least for the >> current RFC), but... in "4.7.3. id": >> >> =AB >> For response stream headers, the receiving entity MUST include the >> =A0 'id' attribute. >> =BB >> >> But the section does not detail any stream error which might be sent >> if the receiving entity does not include a stream id, nor do I seem to >> find any stream error in the list which might be usable in such a >> case. Is that missing? What is supposed to be the reaction of a >> compliant XMPP implementation here? > > If it were the client that could omit the id and not the server, I'd > see more reason for a dedicated stream error. However as it is a > server that doesn't send the 'id' isn't an XMPP server. After you have > established that, what good is 1) continuing to pretend you're doing > XMPP 2) informing the server it is not an XMPP server? I don't agree. That's a bug, that's all. So we must send an error to inform the server, hence eventually letting the operators/implementers know something is broken in their server and fix them (if they see a lot of the same error about not sending an id in their logs, they would begin to see there is an issue). Of course, you could say that's a big bug so any server would have it. But as the same section of RFC6120 states: =AB Interoperability Note: In RFC 3920, the text regarding inclusion of the 'id' attribute was ambiguous, leading some implementations to leave the attribute off the response stream header. =BB And I guess that some clients may be letting the error pass because of the fact that some server are not sending ids (because ambiguous in RFC3920). So that would be useful to have more strict clients which can send useful errors to the servers. So I personally completely disagree with both your points: 1) this is a bug and that's all. It does not make the implementation completely "not-XMPP" because there is a bug! Or if we go this way, as soon as you have a bug (which makes the implementation not compliant with the RFC), you can say you are not doing XMPP, so we can stop right away then. Because if so, I think there exists actually no XMPP implementation in this world (I doubt there is a single XMPP implementation right now, client or server, which is perfectly without a single bug). A server which sends something not XML at all: that's not XMPP. Ok. It sends me a stream header, but forgets the id: that's XMPP with a bug. I really see a big difference. 2) It is always useful to inform others of their errors. If we go further in your optic, we can as well stop sending any error (stream, stanza or whatever) at all. > More useful for a client would be to inform the user that the server > is broken, I think. That's good to inform the user also. Maybe he will go make a bug report... or not. But if the server is bugged, I think the first step is to inform the server automatically. That's the whole point of having stream errors. > In summary, close the stream - that's a FIN, or > (perhaps with or an application-defined > error) if you insist on sending an error. I don't think the rarity of > this error warrants any special handling or a dedicated error > condition though. I don't know how rare is the error. But the interoperability note in the RFC that I quoted above let me think that it may not be that rare. And in the end, I don't see why this stream error deserves less a dedicated error than others (stream errors are *all* rares. They break the stream, so they are the kind of errors any implementation really look for and try to fix fast). > Regards, > Matthew > > PS. On the other hand... RFC 3920 had and I just noticed > that it's still in the 6120 schema - "oops" :) And so why has this error been removed in FC6120? :-/ Regards, Jehan From mwild1@gmail.com Sun Apr 10 15:06:34 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AF83A69CC for ; Sun, 10 Apr 2011 15:06:34 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV4NBGuIdD8O for ; Sun, 10 Apr 2011 15:06:33 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7C6D53A69C6 for ; Sun, 10 Apr 2011 15:06:32 -0700 (PDT) Received: by iwn39 with SMTP id 39so6286023iwn.31 for ; Sun, 10 Apr 2011 15:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=x9OlQ4a5Yg4JJFRJHWJaDSxZ1+CtJnOE6tPEpV5ujfY=; b=JshtDyxVxGN+BpqYC6AJWl9rHq5ylxxGfytFK0lP72Xp6fREBPpDmpY0vr31fFipUn jX8wwrNMYNJFjiL/bjwiY4pHKXZKi/SULh+94ZrkbsgX9C1tkF1ZzIQn+f02OwlNrCyB U5rRet3NwfR/+ijgNRPgS1C8uevgjzJTPsC9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lEOpG/mbGIIK8ZdOuuNZV7vem3nFyTCKkFlM8QG2lVN6t4tiaPwM6H9xHEwQr9SCn3 88sk5XZMGceVYtq6OVygp9UnaJq+c5MkOucrQLd7hasy1Kw2Mol3OmgwUrtDn7YHfdOu YptKjyk8oh02LKQ23j2/ZmNHdUzHpHuWsFq8g= Received: by 10.42.108.137 with SMTP id h9mr7083367icp.112.1302473192061; Sun, 10 Apr 2011 15:06:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.180.130 with HTTP; Sun, 10 Apr 2011 15:06:12 -0700 (PDT) In-Reply-To: References: From: Matthew Wild Date: Sun, 10 Apr 2011 23:06:12 +0100 Message-ID: To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 22:06:34 -0000 2011/4/10 Jehan Pag=C3=A8s : > Hi, > > 2011/4/11 Matthew Wild : >> 2011/4/10 Jehan Pag=C3=A8s : >>> Hi, >>> >>> as we always see things when it is too late (or at least for the >>> current RFC), but... in "4.7.3. id": >>> >>> =C2=AB >>> For response stream headers, the receiving entity MUST include the >>> =C2=A0 'id' attribute. >>> =C2=BB >>> >>> But the section does not detail any stream error which might be sent >>> if the receiving entity does not include a stream id, nor do I seem to >>> find any stream error in the list which might be usable in such a >>> case. Is that missing? What is supposed to be the reaction of a >>> compliant XMPP implementation here? >> >> If it were the client that could omit the id and not the server, I'd >> see more reason for a dedicated stream error. However as it is a >> server that doesn't send the 'id' isn't an XMPP server. After you have >> established that, what good is 1) continuing to pretend you're doing >> XMPP 2) informing the server it is not an XMPP server? > > I don't agree. That's a bug, that's all. So we must send an error to > inform the server, hence eventually letting the operators/implementers > know something is broken in their server and fix them (if they see a > lot of the same error about not sending an id in their logs, they > would begin to see there is an issue). > > Of course, you could say that's a big bug so any server would have it. > But as the same section of RFC6120 states: > =C2=AB > =C2=A0 =C2=A0 =C2=A0Interoperability Note: In RFC 3920, the text regardin= g inclusion > =C2=A0 =C2=A0 =C2=A0of the 'id' attribute was ambiguous, leading some imp= lementations > =C2=A0 =C2=A0 =C2=A0to leave the attribute off the response stream header= . > =C2=BB > I don't know which implementations those are. The stream id has historically been used for a number of things, e.g. component auth and dialback spring to mind. I think any server omitting the 'id' attribute would have a hard time on today's network. > 2) It is always useful to inform others of their errors. If we go > further in your optic, we can as well stop sending any error (stream, > stanza or whatever) at all. > >> More useful for a client would be to inform the user that the server >> is broken, I think. > > That's good to inform the user also. Maybe he will go make a bug > report... or not. But if the server is bugged, I think the first step > is to inform the server automatically. That's the whole point of > having stream errors. > >> In summary, close the stream - that's a FIN, or >> (perhaps with or an application-defined >> error) if you insist on sending an error. I don't think the rarity of >> this error warrants any special handling or a dedicated error >> condition though. > > I don't know how rare is the error. But the interoperability note in > the RFC that I quoted above let me think that it may not be that rare. As above, I think you'll find it's very rare. No popular implementation is going to have this bug for long, given how many things break without it. > And in the end, I don't see why this stream error deserves less a > dedicated error than others (stream errors are *all* rares. They break > the stream, so they are the kind of errors any implementation really > look for and try to fix fast). > The most common stream errors I see are not-well-formed (buggy client), host-unknown (misconfigured server or DNS), connection-timeout (network or config issues), system-shutdown (server restart). I have seen invalid-id, but only in the context of failed dialback (jabberd2 uses it). I maintain that there is little point in clients sending errors to servers. Maybe I'm biased, being a server dev, but I don't intend to argue about it. If you are so passionate about reporting this error then send with instead. We can't have a stream error for every MUST in the spec that an implementation might break, and this case deserves one less than any I can think of. >> PS. On the other hand... RFC 3920 had and I just noticed >> that it's still in the 6120 schema - "oops" :) > > And so why has this error been removed in FC6120? :-/ > >From Appendix D: "Removed the unnecessary and unused stream error (see RFC 3920 for historical documentation)." Regards, Matthew From jehan.marmottard@gmail.com Sun Apr 10 22:49:55 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95AE33A6A80 for ; Sun, 10 Apr 2011 22:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D96al6zqC7VY for ; Sun, 10 Apr 2011 22:49:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B098F3A6A7F for ; Sun, 10 Apr 2011 22:49:50 -0700 (PDT) Received: by wwa36 with SMTP id 36so4312823wwa.13 for ; Sun, 10 Apr 2011 22:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6xo/pID4Zk9SCQ/ZSUQhui9bO1mPhH3+ahhWmvrpuTc=; b=NKXGRz9iFQMMCMd/hR0AE+jk/cnTUyedB1vKBQQF1uwSz3kMWj23mSQI98nTdN2L+M iZvHFX0gfkZgCvANqhAoZ0mKMXFKxhCSztbaEmal4wQmQYsSoVYZVhqTsk0ShiG6zESV hl4SzuvleRXl0Ux2yArnTKKy4yuwPVR51aNKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g9mRoieMSFzcesiT0ruWIzF+qAYcjw6aKt2OcC88ORaJ0GFAigPcyyGd+NmTmKa8pR UNRF8N4J0wjRlqWmBM14XedURmRNz9UXMlbsuZleTiqH2YJayLpEWMnoNlKh74J5zY43 gjdWgGnda6Z6oZeLg9t8ZWbwAcOFK4vBVAA4Y= MIME-Version: 1.0 Received: by 10.216.138.66 with SMTP id z44mr429954wei.87.1302500989711; Sun, 10 Apr 2011 22:49:49 -0700 (PDT) Received: by 10.216.29.194 with HTTP; Sun, 10 Apr 2011 22:49:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Apr 2011 14:49:49 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Matthew Wild Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 05:49:55 -0000 Hi, 2011/4/11 Matthew Wild : > 2011/4/10 Jehan Pag=E8s : >> Hi, >> >> 2011/4/11 Matthew Wild : >>> 2011/4/10 Jehan Pag=E8s : >>>> Hi, >>>> >>>> as we always see things when it is too late (or at least for the >>>> current RFC), but... in "4.7.3. id": >>>> >>>> =AB >>>> For response stream headers, the receiving entity MUST include the >>>> =A0 'id' attribute. >>>> =BB >>>> >>>> But the section does not detail any stream error which might be sent >>>> if the receiving entity does not include a stream id, nor do I seem to >>>> find any stream error in the list which might be usable in such a >>>> case. Is that missing? What is supposed to be the reaction of a >>>> compliant XMPP implementation here? >>> >>> If it were the client that could omit the id and not the server, I'd >>> see more reason for a dedicated stream error. However as it is a >>> server that doesn't send the 'id' isn't an XMPP server. After you have >>> established that, what good is 1) continuing to pretend you're doing >>> XMPP 2) informing the server it is not an XMPP server? >> >> I don't agree. That's a bug, that's all. So we must send an error to >> inform the server, hence eventually letting the operators/implementers >> know something is broken in their server and fix them (if they see a >> lot of the same error about not sending an id in their logs, they >> would begin to see there is an issue). >> >> Of course, you could say that's a big bug so any server would have it. >> But as the same section of RFC6120 states: >> =AB >> =A0 =A0 =A0Interoperability Note: In RFC 3920, the text regarding inclus= ion >> =A0 =A0 =A0of the 'id' attribute was ambiguous, leading some implementat= ions >> =A0 =A0 =A0to leave the attribute off the response stream header. >> =BB >> > > I don't know which implementations those are. The stream id has > historically been used for a number of things, e.g. component auth and > dialback spring to mind. I think any server omitting the 'id' > attribute would have a hard time on today's network. > >> 2) It is always useful to inform others of their errors. If we go >> further in your optic, we can as well stop sending any error (stream, >> stanza or whatever) at all. >> >>> More useful for a client would be to inform the user that the server >>> is broken, I think. >> >> That's good to inform the user also. Maybe he will go make a bug >> report... or not. But if the server is bugged, I think the first step >> is to inform the server automatically. That's the whole point of >> having stream errors. >> >>> In summary, close the stream - that's a FIN, or >>> (perhaps with or an application-defined >>> error) if you insist on sending an error. I don't think the rarity of >>> this error warrants any special handling or a dedicated error >>> condition though. >> >> I don't know how rare is the error. But the interoperability note in >> the RFC that I quoted above let me think that it may not be that rare. > > As above, I think you'll find it's very rare. No popular > implementation is going to have this bug for long, given how many > things break without it. I don't know how rare it actually is either. I did not check but still I quoted the above. Every piece of text which has ever been added to the RFC (especially on such a specific topic) has normally been added for a reason. So I guess it must exist somewhere. >> And in the end, I don't see why this stream error deserves less a >> dedicated error than others (stream errors are *all* rares. They break >> the stream, so they are the kind of errors any implementation really >> look for and try to fix fast). >> > > The most common stream errors I see are not-well-formed (buggy > client), host-unknown (misconfigured server or DNS), > connection-timeout (network or config issues), system-shutdown (server > restart). I have seen invalid-id, but only in the context of failed > dialback (jabberd2 uses it). Of course, we won't see many of such error to be sure how rare it is if it isn't anymore in the spec. ;-) > I maintain that there is little point in clients sending errors to > servers. Maybe I'm biased, being a server dev, but I don't intend to > argue about it. If you are so passionate about reporting this error > then send with instead. We can't have a > stream error for every MUST in the spec that an implementation might > break, and this case deserves one less than any I can think of. I don't see why it deserves less than an invalid-from or invalid-namespace. As you said yourself, that's some feature pretty important for an healthy network. And it is not that I am passionate (or maybe, but that's because I am passionate in everything I do and I care about details). That's just that I am writing a client side of XMPP. And this case is something which can theoritically happen so I just wanted to know how to handle this. I could of course simply close the stream as you suggest, but that's definitely not "clean". The right way to close a broken stream is with an error first-hand (and I would agree that it does not matter if that's in fact not a XMPP server on the other side, but really some entity that sends me an XML opening tag, labelled as a jabber stream and with a jabber:client default namespace, though no id... I tend to think that's just a broken XMPP server). For the undefined-condition, I looked at it when I was first searching for a stream error before sending the email. The description said: =AB this error condition SHOULD NOT be used except in conjunction with an application-specific condition. =BB >>> PS. On the other hand... RFC 3920 had and I just noticed >>> that it's still in the 6120 schema - "oops" :) >> >> And so why has this error been removed in FC6120? :-/ >> > > From Appendix D: "Removed the unnecessary and unused > stream error (see RFC 3920 for historical documentation)." Yep sorry, I should have checked myself. Got lazy (as an excuse, it was about 6:20 AM when I sent my last email :p)... See you! Jehan > Regards, > Matthew > From fippo@mail.symlynx.com Sun Apr 10 23:00:35 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E4D3A6A80 for ; Sun, 10 Apr 2011 23:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+QSfcRFv0bx for ; Sun, 10 Apr 2011 23:00:31 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by core3.amsl.com (Postfix) with ESMTP id D5FE43A69D8 for ; Sun, 10 Apr 2011 23:00:30 -0700 (PDT) Received: from [10.150.124.14] ([89.204.153.142]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3B60Dfp012879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Apr 2011 08:00:26 +0200 Message-ID: <4DA298DE.4040905@mail.symlynx.com> Date: Mon, 11 Apr 2011 07:59:58 +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: XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:00:36 -0000 Matthew Wild wrote: > I don't know which implementations those are. The stream id has > historically been used for a number of things, e.g. component auth and > dialback spring to mind. I think any server omitting the 'id' > attribute would have a hard time on today's network. More importantly, the response stream id was used in the obsolete XEP 0078 digest authentication scheme. I think you would have had more (user-visible) problems omitting it in 2004 than you would have today. From dave@cridland.net Mon Apr 11 03:57:12 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DFE3A6B03 for ; Mon, 11 Apr 2011 03:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAmhC2EV2MzD for ; Mon, 11 Apr 2011 03:57:11 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 3804D3A6B00 for ; Mon, 11 Apr 2011 03:57:11 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D1DFB1168087; Mon, 11 Apr 2011 11:57:03 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odpew2K9+FyJ; Mon, 11 Apr 2011 11:57:00 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 2C77D1168067; Mon, 11 Apr 2011 11:57:00 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <3111.1302519420.171372@puncture> Date: Mon, 11 Apr 2011 11:57:00 +0100 From: Dave Cridland To: =?ISO-8859-1?Q?Jehan_Pag=E8s?= , XMPP Working Group , Matthew Wild Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 10:57:12 -0000 On Mon Apr 11 06:49:49 2011, Jehan Pagès wrote: > that's definitely not "clean". The right way to close a broken > stream > is with an error first-hand (and I would agree that it does not > matter > if that's in fact not a XMPP server on the other side, but really > some > entity that sends me an XML opening tag, labelled as a jabber stream > and with a jabber:client default namespace, though no id... I tend > to > think that's just a broken XMPP server). There are several cases where the correct way to close the stream is not with an error. For one thing, the - hopefully normal - case of shutting down a client session would not have an error. Now, if the client has decided that a stream is sufficiently broken that it cannot continue with the session, there are also cases where the correct thing to do is to simply close the stream and inform the user - not the server - as to the reasons why. Sometimes, it's arguably better to drop the connection rather than even send a stream closing tag. On the other hand, having lots of very much edge-case errors seems to lay an additional burden that's bound to be skipped by someone not even bothering to issue a stream id. Consider - if a server implementation doesn't support a stream id, then why on earth would the implementor carefully catch the error issued by a client in that instance? 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 jehan.marmottard@gmail.com Mon Apr 11 04:41:49 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5953A6B07 for ; Mon, 11 Apr 2011 04:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EziVZQTvZwpx for ; Mon, 11 Apr 2011 04:41:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CF7C23A68D1 for ; Mon, 11 Apr 2011 04:41:48 -0700 (PDT) Received: by wwa36 with SMTP id 36so4514403wwa.13 for ; Mon, 11 Apr 2011 04:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VpT9fOcYNjUkhmTEYU0akmuFIY/MZCb4XCoVeofHJE0=; b=YNqWo1lejTjT9M1+7a5IXJhbNOFUBUszTncmn7VXCvjkSufIVNpNJUVEJdtN01n+rn 4oZdse8iaEpCFyUuLJT6x6xrmAiCynAv9XNC9lfk0k1GonYhi2VNHChKQwkEuXlQHKhZ GixOiJ29ZJV2w+LUM4/Wegu9yhSm5dgfVmyJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pUs8J3TF2+i1xP6VX4H7azgY/FMOXYtWoyoLf7yZC1X3mSR1XaWLH9kthSMfnd89Cp Wpnm76l1u8dTZE79vZ++ped+IxUqLcHbbAZFnaqReikEOm1Sw+9OMFODbh0uhFtRm/hM QXangVy9zrPodx+vGB/CrlvnX4+YppesIVgQg= MIME-Version: 1.0 Received: by 10.216.55.145 with SMTP id k17mr2760842wec.48.1302522108554; Mon, 11 Apr 2011 04:41:48 -0700 (PDT) Received: by 10.216.29.194 with HTTP; Mon, 11 Apr 2011 04:41:48 -0700 (PDT) In-Reply-To: <3111.1302519420.171372@puncture> References: <3111.1302519420.171372@puncture> Date: Mon, 11 Apr 2011 20:41:48 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: XMPP Working Group Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:41:50 -0000 Hi, On Mon, Apr 11, 2011 at 7:57 PM, Dave Cridland wrote: > On Mon Apr 11 06:49:49 2011, Jehan Pag=E8s wrote: >> >> that's definitely not "clean". The right way to close a broken stream >> is with an error first-hand (and I would agree that it does not matter >> if that's in fact not a XMPP server on the other side, but really some >> entity that sends me an XML opening tag, labelled as a jabber stream >> and with a jabber:client default namespace, though no id... I tend to >> think that's just a broken XMPP server). > > There are several cases where the correct way to close the stream is not > with an error. > > For one thing, the - hopefully normal - case of shutting down a client > session would not have an error. > > Now, if the client has decided that a stream is sufficiently broken that = it > cannot continue with the session, there are also cases where the correct > thing to do is to simply close the stream and inform the user - not the > server - as to the reasons why. Sometimes, it's arguably better to drop t= he > connection rather than even send a stream closing tag. > > On the other hand, having lots of very much edge-case errors seems to lay= an > additional burden that's bound to be skipped by someone not even botherin= g > to issue a stream id. > > Consider - if a server implementation doesn't support a stream id, then w= hy > on earth would the implementor carefully catch the error issued by a clie= nt > in that instance? Here you are making assumptions that the implementation has a bug because the implementer is just a lazy ass. Nearly it looks like he did the bug on purpose (he "doesn't support a stream id")! This kind of thinking could be applied to nearly any bug and looks like the kind of complaints some users do about developers to show they are not happy and that we MUST work better. That's sad to read it from developers as well. I don't know if any implementation has this bug, but if any, I would definitely not assume anything else than the objective fact it is a bug (which can be for so many reasons). Plus, the RFC itself gives a good reason why it would be perfectly plausible to find such a bug, even with a very picky and hard-worker developer: "In RFC 3920, the text regarding inclusion of the 'id' attribute was ambiguous". Anyway I don't really agree with any of the reasons I read about why this specific case deserves less an error than others :-/ (of course, the best one I see right now is that the RFC has just been released, but that does not prevent us from talking for the long-time future, or some errata). Though it's definitely not such a big deal. Jehan From remko.troncon@gmail.com Mon Apr 11 04:57:37 2011 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6591B3A6A09 for ; Mon, 11 Apr 2011 04:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohhImCTbKDYI for ; Mon, 11 Apr 2011 04:57:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D7E7E3A69FF for ; Mon, 11 Apr 2011 04:57:36 -0700 (PDT) Received: by iye19 with SMTP id 19so6898525iye.31 for ; Mon, 11 Apr 2011 04:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LDSPMVle6h3mx0XsRzJsOi4vqwcIXQZWRrbeK6xYiMA=; b=bwcSMNychZMwGq2P4vl7ldpWNyvce2zckLF3kt7op9aZ34pxF/nldW+O7viSzPc4rB w+bONnJRkLjktqT3Lhy8hS+T1//1u798eTP5tVEUtzFBiX3UH6pF1G6sclzLPsX7JvKd UKgGN6CuWUysa5He1/H5hPy9l4ENs727ap27E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jG8pk7xCmptjiZN8taFBj5p8DDRpe1+Ef2KBfjfM5a08ozcYlzLkr5YnmtkZGOnKYH HRiuQxG0NZL+Pp3ZyDrxXnf71r9QbG3MoLVQod+LDHzzljbDxdtbmwyY2XQTHwK6psBE 5ZClMxN00HzQKPPtVoi4gNZogra5XGYs5dx+c= MIME-Version: 1.0 Received: by 10.231.65.75 with SMTP id h11mr5260035ibi.149.1302523057030; Mon, 11 Apr 2011 04:57:37 -0700 (PDT) Sender: remko.troncon@gmail.com Received: by 10.231.213.170 with HTTP; Mon, 11 Apr 2011 04:57:36 -0700 (PDT) In-Reply-To: References: <3111.1302519420.171372@puncture> Date: Mon, 11 Apr 2011 13:57:36 +0200 X-Google-Sender-Auth: f0ZP5VtiO3uqynFk-OcYqVKiI50 Message-ID: From: =?UTF-8?Q?Remko_Tron=C3=A7on?= To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Content-Type: text/plain; charset=UTF-8 Cc: XMPP Working Group Subject: Re: [xmpp] RFC 6120: stream error when no stream id? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:57:37 -0000 > Anyway I don't really agree with any of the reasons I read about why > this specific case deserves less an error than others >From a pragmatic client developer's point of view: because all this has no impact whatsoever on user experience of XMPP. But I agree that a futile detail like this has been discussed a bit much already. Let's just write it down and process it when the next RFC is being written. cheers, Remko From stpeter@stpeter.im Mon Apr 11 15:44:53 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E31A3E06AC for ; Mon, 11 Apr 2011 15:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDKmq0jZ+C0Z for ; Mon, 11 Apr 2011 15:44:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 19A68E0699 for ; Mon, 11 Apr 2011 15:44:50 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 53CBD40022 for ; Mon, 11 Apr 2011 14:19:11 -0600 (MDT) Message-ID: <4DA36190.9020006@stpeter.im> Date: Mon, 11 Apr 2011 14:16: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: xmpp@ietf.org References: <3111.1302519420.171372@puncture> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060506000706030402070508" Subject: Re: [xmpp] RFC 6120: stream error when no stream id? 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 Apr 2011 22:44:54 -0000 This is a cryptographically signed message in MIME format. --------------ms060506000706030402070508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/11/11 5:57 AM, Remko Tron=C3=A7on wrote: >> Anyway I don't really agree with any of the reasons I read about why >> this specific case deserves less an error than others >=20 > From a pragmatic client developer's point of view: because all this > has no impact whatsoever on user experience of XMPP. >=20 > But I agree that a futile detail like this has been discussed a bit > much already. Let's just write it down and process it when the next > RFC is being written. Duly noted. :) --------------ms060506000706030402070508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx MTIwMTYxNlowIwYJKoZIhvcNAQkEMRYEFE9NeQ9poxxl84qC6ji21mnmabr3MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCNa1YoX3wPQdDvI8dSZ8xSCgp5uyY6gkKP2W3Vc3CHoVKNwU27ToNc9qIO AJJR+LUMCz8EQ1A1ArqdWExP0NR7C4mkDQT41rIJ/WLSLkPAtm3JGc0831XP90V7LCbErBl9 li4KrAiHD7G/ERQabJ5VbSAk/KXXyZvHgFpStRiISZ74P3yH1fSl+UkTXq9h2I6vzds3B2Aj VjeWYQq8uSPd07tlJ/WBjmthokWnu91u3H5ld8lnZEojtNM7MjhjJwgAFZXx5j1r2F4sBZ4p EZR425RV7wijy4qtHVn0uinCTqOGOunl2UnK11aB6jgpV6tP6s1xt9X6j7dnVyG+GrvYAAAA AAAA --------------ms060506000706030402070508-- From stpeter@stpeter.im Thu Apr 21 17:11:53 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11710E0732 for ; Thu, 21 Apr 2011 17:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flo+5KwOUZCz for ; Thu, 21 Apr 2011 17:11:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 816D9E06DD for ; Thu, 21 Apr 2011 17:11:52 -0700 (PDT) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C462400AB for ; Thu, 21 Apr 2011 18:15:38 -0600 (MDT) Message-ID: <4DB0C7C6.7020808@stpeter.im> Date: Thu, 21 Apr 2011 18:11:50 -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 X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040602030801080304090203" Subject: [xmpp] 3920, 6120, and 6122 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 Apr 2011 00:11:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040602030801080304090203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've received several puzzled queries off-list about the relationship between RFCs 3920, 6120, and 6122. "Why does 6122 update 3920 if 6120 obsoletes 3920?" I explain the puzzle by pointing out that (1) 6120 obsoletes everything in 3920 except the address format, (2) 6122 updates the address format by correcting some errors in 3920, and (3) we had to do it this way because one third of the XMPP address format has been upgraded to not use stringprep (cf. IDNA2008) whereas the other two thirds are waiting on completion of work by the PRECIS WG on a generic replacement for stringprep. I further explain that both 6120 and 6122 will probably be obsoleted by a combined spec that brings the protocol bits and the address format back into the same document: 3920 /\ / \ / \ 6120 6122 \ / \ / \/ 3920ter /psa --------------ms040602030801080304090203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy MjAwMTE1MFowIwYJKoZIhvcNAQkEMRYEFDcIPUchLwd8v6SpB24s3qSnx8akMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA1nmWAbLInQR0HWg3HRI9SQnKjYoS3XGxH2YmDZgke3JHTC4X6aXQPMUAO f9Nw3vfLqqx8sC54tcAxwGmVpp1h9Sv3b4qjP+L9SIav/VEyOkhmW3TqdHHz8DAna5XritlJ Dk1AJcOOCXAMsE7kr04shRnoG8eZkGakDNLpI0ZF1qVZ6mDMH4WXsJScmNQUQBTh+KPY44wU F7zblMupqgCEOdc5q9b5nCRNpJv631oQDiPW2v/00o54087pGM9wIQrx5BeEKMLJE6Re88jx Gya40jW5trF4b1G5U+zItoWWE9D8Lo6/HF4axtC6ySHEsxMzjJmzwvouGcGfS0XxksE7AAAA AAAA --------------ms040602030801080304090203-- From ben.schumacher@webex.com Fri Apr 22 08:44:06 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36D5FE077E for ; Fri, 22 Apr 2011 08:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L9n5onZTz7H for ; Fri, 22 Apr 2011 08:44:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 73C24E0782 for ; Fri, 22 Apr 2011 08:43:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYIAN6hsU2rRDoI/2dsb2JhbACET5NCjUx3pzOLXJB7gSmDUH0EhXSIOQ X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208";a="685821498" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2011 15:43:53 +0000 Received: from horus.local (wedjat.cisco.com [64.101.72.137]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3MFhrde004800 for ; Fri, 22 Apr 2011 15:43:53 GMT Message-ID: <4DB1A239.40906@webex.com> Date: Fri, 22 Apr 2011 09:43:53 -0600 From: Ben Schumacher Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: xmpp@ietf.org References: <4DB0C7C6.7020808@stpeter.im> In-Reply-To: <4DB0C7C6.7020808@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 3920, 6120, and 6122 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 Apr 2011 15:44:06 -0000 On 4/21/11 6:11 PM, Peter Saint-Andre wrote: > I've received several puzzled queries off-list about the relationship > between RFCs 3920, 6120, and 6122. "Why does 6122 update 3920 if 6120 > obsoletes 3920?" > > I explain the puzzle by pointing out that (1) 6120 obsoletes everything > in 3920 except the address format, (2) 6122 updates the address format > by correcting some errors in 3920, and (3) we had to do it this way > because one third of the XMPP address format has been upgraded to not > use stringprep (cf. IDNA2008) whereas the other two thirds are waiting > on completion of work by the PRECIS WG on a generic replacement for > stringprep. I further explain that both 6120 and 6122 will probably be > obsoleted by a combined spec that brings the protocol bits and the > address format back into the same document: > > 3920 > /\ > / \ > / \ > 6120 6122 > \ / > \ / > \/ > 3920ter > Without this glorious ASCII art, I probably would have been lost in the description. ;) Thanks Peter. Ben From Tory.Patnoe@webex.com Fri Apr 22 11:01:36 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 296B1E0691 for ; Fri, 22 Apr 2011 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ZkKpinFxkd for ; Fri, 22 Apr 2011 11:01:35 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by ietfc.amsl.com (Postfix) with SMTP id 7EF49E0611 for ; Fri, 22 Apr 2011 11:01:35 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.198]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:01:34 -0700 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Apr 2011 18:01:34 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 22 Apr 2011 12:01:35 -0600 From: Tory Patnoe To: Ben Schumacher , XMPP Message-ID: Thread-Topic: [xmpp] 3920, 6120, and 6122 Thread-Index: AcwBF1F+ezdcIHjBGUqBMdG1sTTP1A== In-Reply-To: <4DB1A239.40906@webex.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Apr 2011 18:01:34.0314 (UTC) FILETIME=[51157CA0:01CC0117] Subject: Re: [xmpp] 3920, 6120, and 6122 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 Apr 2011 18:01:36 -0000 On 2011-4-22 9:43 AM, "Ben Schumacher" wrote: > Without this glorious ASCII art, I probably would have been lost in the > description. ;) > > Thanks Peter. > I'd also like to be reminded of where the "bis" and "ter" come from. I've searched "Latin Ordinal Numbers" but that isn't quite right. Although referring to 3920primus and 3921primus seems appropriate. -- Tory From stpeter@stpeter.im Fri Apr 22 11:06:06 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3CC65E0780 for ; Fri, 22 Apr 2011 11:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCIlQCoW6O84 for ; Fri, 22 Apr 2011 11:06:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id AB5A2E0611 for ; Fri, 22 Apr 2011 11:06:05 -0700 (PDT) Received: from dhcp-64-101-72-251.cisco.com (dhcp-64-101-72-251.cisco.com [64.101.72.251]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 773B840022; Fri, 22 Apr 2011 12:09:55 -0600 (MDT) Message-ID: <4DB1C38C.9090502@stpeter.im> Date: Fri, 22 Apr 2011 12:06:04 -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: Tory Patnoe References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040103010506070902010208" Cc: XMPP , Ben Schumacher Subject: Re: [xmpp] 3920, 6120, and 6122 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 Apr 2011 18:06:06 -0000 This is a cryptographically signed message in MIME format. --------------ms040103010506070902010208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/22/11 12:01 PM, Tory Patnoe wrote: >=20 > On 2011-4-22 9:43 AM, "Ben Schumacher" wrote= : >=20 >> Without this glorious ASCII art, I probably would have been lost in th= e >> description. ;) >> >> Thanks Peter. >> >=20 > I'd also like to be reminded of where the "bis" and "ter" come from. I'= ve > searched "Latin Ordinal Numbers" but that isn't quite right. Although > referring to 3920primus and 3921primus seems appropriate. In Latin, "bis" means twice (you can see this in the word "biscuit", which means twice cooked). Similarly, "ter" means thrice. I sure hope we don't get to "quater", though. ;-) /psa --------------ms040103010506070902010208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy MjE4MDYwNFowIwYJKoZIhvcNAQkEMRYEFJuDOloG20oB708uApZ/yLMPujSxMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC2JIQ0/dmfx56MTxHGAqcoqkOVcMaHR6OonVddthuyzukIejqblWUZNDpq JVGP1smosQN3ZUcOlfxPRPAt2Kub0Wv8Op5o+pUlPn9alQpbocYChZOYAQHbMFIZzfygN77o 1lG1eBdbAz6zNwEv8uSm4uM0/tfQzMPS+Du0wLkfY8L60KMBJzlTwnHkNtP6Ta7XdUhXLG6g CZW8EJgAJLvJuzj4eI9gnQLqnlBdXdDN6QAXsHsZBZGYyQNO3I1hUs4gZqG6rmRwZQhIk6/c ToolkA5wQ0xIO7GYe85TeXCYJdWi9w2iY0VXIE8X8Cf16ymISYtSZ0uZ/Y2IofsygB1uAAAA AAAA --------------ms040103010506070902010208-- From jehan.marmottard@gmail.com Fri Apr 22 11:40:33 2011 Return-Path: X-Original-To: xmpp@ietfc.amsl.com Delivered-To: xmpp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 536B3E0686 for ; Fri, 22 Apr 2011 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUdUiyEIFdqf for ; Fri, 22 Apr 2011 11:40:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 47573E065A for ; Fri, 22 Apr 2011 11:40:32 -0700 (PDT) Received: by wwa36 with SMTP id 36so574461wwa.13 for ; Fri, 22 Apr 2011 11:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vUWAfMY20clfJUSqRZ11j10seCO4q9abRX1okqkjqOg=; b=snInWEzygzT/eB16iYi+YJTKPC0Bb13La+kFN/hes9Jv8IuAfW10KgPR9A0Jxd+YpE No004dcl/o1uJg5qI0DBlKSapHfaUdCw/x1iNqq1YIrOT+Y50KKY79fWYflxg6KgsjX1 OLKrFM4KMLilTjBBYDgYBduJwdxb+yz0xSiPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IbwPVYIy9GFVGaUZsi2nQwrlF69UXsUOcWwr9hAH868NxohmBjukuv9lwQUnMcqRDE o7a52kfn2El5bTjnt19vvBcaDK4xSFTuR0BftUZfBTW8U96GAtq4P+UwCO0CoEuYHAQN Rk1gD+y5uReG3am00+/xM1phQxYOikNns97po= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr1296035wes.90.1303497631640; Fri, 22 Apr 2011 11:40:31 -0700 (PDT) Received: by 10.216.134.153 with HTTP; Fri, 22 Apr 2011 11:40:31 -0700 (PDT) In-Reply-To: <4DB1C38C.9090502@stpeter.im> References: <4DB1C38C.9090502@stpeter.im> Date: Sat, 23 Apr 2011 03:40:31 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Schumacher , XMPP Subject: Re: [xmpp] 3920, 6120, and 6122 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 Apr 2011 18:40:33 -0000 Hi, On Sat, Apr 23, 2011 at 3:06 AM, Peter Saint-Andre wrote: > On 4/22/11 12:01 PM, Tory Patnoe wrote: >> >> On 2011-4-22 9:43 AM, "Ben Schumacher" wrote: >> >>> Without this glorious ASCII art, I probably would have been lost in the >>> description. ;) >>> >>> Thanks Peter. >>> >> >> I'd also like to be reminded of where the "bis" and "ter" come from. I've >> searched "Latin Ordinal Numbers" but that isn't quite right. Although >> referring to 3920primus and 3921primus seems appropriate. > > In Latin, "bis" means twice (you can see this in the word "biscuit", > which means twice cooked). > > Similarly, "ter" means thrice. > > I sure hope we don't get to "quater", though. ;-) In the current rate, that will be in maybe 15 years before we begin to work on this hypothetical 3920quater. You have time to see it come. :-D Jehan From ben@nostrum.com Mon Apr 25 15:29:05 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 E50F8E0689 for ; Mon, 25 Apr 2011 15:29:05 -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, 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 ydBJPXNy0z8E for ; Mon, 25 Apr 2011 15:29:05 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 631ABE0670 for ; Mon, 25 Apr 2011 15:29:02 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p3PJcWlb013247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Apr 2011 14:38:33 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Apr 2011 14:38:31 -0500 Message-Id: <844CFF8F-B171-433C-A8FB-ECBB9C23A4B8@nostrum.com> To: XMPP Group Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Subject: [xmpp] IETF 80 Minutes X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:29:06 -0000 Hi, Draft minutes from the XMPP meeting in Prague are posted at = http://www.ietf.org/proceedings/80/minutes/xmpp.txt . Please report any errors or updates as soon as possible. Thanks! Ben.= From stpeter@stpeter.im Tue Apr 26 19:22:05 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 23F5EE067E for ; Tue, 26 Apr 2011 19:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 JSahWrsyAqTQ for ; Tue, 26 Apr 2011 19:22:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5163FE0682 for ; Tue, 26 Apr 2011 19:22:04 -0700 (PDT) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E718640022; Tue, 26 Apr 2011 20:26:16 -0600 (MDT) Message-ID: <4DB77DC9.2040007@stpeter.im> Date: Tue, 26 Apr 2011 20:22:01 -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: Ben Campbell References: <844CFF8F-B171-433C-A8FB-ECBB9C23A4B8@nostrum.com> In-Reply-To: <844CFF8F-B171-433C-A8FB-ECBB9C23A4B8@nostrum.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080904030907030405080408" Cc: XMPP Group Subject: Re: [xmpp] IETF 80 Minutes X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 02:22:05 -0000 This is a cryptographically signed message in MIME format. --------------ms080904030907030405080408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/25/11 1:38 PM, Ben Campbell wrote: > Hi, >=20 > Draft minutes from the XMPP meeting in Prague are posted at http://www.= ietf.org/proceedings/80/minutes/xmpp.txt . >=20 > Please report any errors or updates as soon as possible. Looks good. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080904030907030405080408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy NzAyMjIwMVowIwYJKoZIhvcNAQkEMRYEFPLF3goClhnC4sOpEfV/V1rNX4jIMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBej3nAmJ7Ukh5R9Y/1u+gIb6qTZk2W0gcnYnxwmUhwwyG2z+FbjK6i5rHB 3tT1U+oAobG5/dUGDPUGbGiDyNkz+qZRJqVcJE/52e7aBDmg7Kwbk5oPm5hd3obvE74DZE+k 2Ji1+XcvegFhdgayXO0XqVN+3/vYypVyGJQE88YG/TtKYSxaxEvDYtCZnavgK9aW40rGRD2R VFztb+9vZGv4IBx0ZjJiJyRkFulwOuJgP7k17tbUwlpereBgusLCCMwbRox6k1vi/+R9t+sn pE5PSUBtYiyiTE2el4F+KNMNYsspQcS5vq2WJlamzHbxF3TGZzLTVk927mbDr7TZRfddAAAA AAAA --------------ms080904030907030405080408--