From zarevucky.jiri@gmail.com Sat Aug 1 07:10:13 2009 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 A17BB3A69A8 for ; Sat, 1 Aug 2009 07:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oW6e2r5-gjPC for ; Sat, 1 Aug 2009 07:10:12 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id A7D313A6D72 for ; Sat, 1 Aug 2009 07:10:04 -0700 (PDT) Received: by bwz19 with SMTP id 19so1669621bwz.37 for ; Sat, 01 Aug 2009 07:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vC4r8LyX7ZMzJDls0PHoz2sv5wVl1BMUQbEgliObz3s=; b=x9957B4h+gdLmCIy8bPsRJldRenr12tl00oA7UkMq2GCb9j4AIMDcY0hEgbyUQeU8+ +gwpdojdRd5sgeao5+DmWabDjBWxzzkSZMh2Of+SoMIZE6F8InVk0YAD59L6kbTfv588 eBg5fOSCOqTUYpT4zBXrGDH1udWzv3ED7YmeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=B1FthuUPVF5mFyMnVE/ZCTU2dStepBhM3FUQxZEbIjXxWCmP8IPwH1wQRHvspeeVde uw/410DL+aa/2F9MInBgSFTbeAg1KBWehUYzdEJGdwQfdqGDvb/rqr9B7snX8dC8n9Dj Ildmiz7tbDJSmOA8XJ4iNPfffX4yRbY+3edvg= Received: by 10.103.1.4 with SMTP id d4mr383836mui.53.1249135804257; Sat, 01 Aug 2009 07:10:04 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id j9sm22939792mue.56.2009.08.01.07.10.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Aug 2009 07:10:03 -0700 (PDT) Message-ID: <4A744CAE.4060905@gmail.com> Date: Sat, 01 Aug 2009 16:09:50 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: xmpp@ietf.org References: <057.68667927e0bb839c72dd253854f8adee@tools.ietf.org> <4A730B35.4090903@stpeter.im> In-Reply-To: <4A730B35.4090903@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] #3: whitespace pings are in fact keepalives 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, 01 Aug 2009 14:10:13 -0000 On 07/31/2009 05:18 PM, Peter Saint-Andre wrote: > On 7/7/09 12:52 AM, xmpp issue tracker wrote: > >> #3: whitespace pings are in fact keepalives >> ... >> > I have fixed this in my working copy. The paragraph in which the > relevant text is found now reads as follows: > > An XML stream can appear idle at the XMPP level because the > underlying TCP connection has become idle (e.g., a client's network > connection has been lost). The typical method for detecting an idle > TCP connection is to send a space character (U+0020) over the TCP > connection between XML stanzas, which is allowed for XML streams as > described under Section 12.7. The sending of such a space character > is properly called a WHITESPACE KEEPALIVE (although the term > "whitespace ping" is in common use, in fact it is not a ping since no > "pong" is possible). The time between such whitespace keepalives (or > other connection-testing methods) is a matter of implementation and > local service policy; however, it is RECOMMENDED that any such test > be performed not more than once every 60 seconds. > > Peter > That's still not good. You can't use whitespace to detect idle connection, because there is no response from the server and TCP timeout is usually veeery long. The only use I can see would be preventing connection timeout. That being said, it's not a "test" and the paragraph in this form is strongly misleading. From zarevucky.jiri@gmail.com Sat Aug 1 07:30:12 2009 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 F1D273A69A8 for ; Sat, 1 Aug 2009 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=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 2TxPm9kdEMBY for ; Sat, 1 Aug 2009 07:30:11 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id F1CAC3A6A77 for ; Sat, 1 Aug 2009 07:30:10 -0700 (PDT) Received: by bwz19 with SMTP id 19so1674957bwz.37 for ; Sat, 01 Aug 2009 07:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=o2o7/bDzTP/rGWcJ23W+eAx3MdZBCVwAWzWKp5KXkNk=; b=Wlk8lUF4rLyBnSDb657GEYrq2wQTcDdrHTVdFF09zr9AxBV5uZ/p37u4pRWXm100uf OwpUrLLBhCq0ibdfZTfheX9NP7sD7FBWBPPA3x8YYUXJtDxh3+XOX8fyegYlFoKBDgzw PFzy7yMkICU+qlj+taQ7c/jawAX1dZd+Fanw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=LkaYtCMPkJ1UEd5ZLe9HsNm9po4GOK6r4IXTApQFVXXkde4+5hyfLh2ZDBbQb/m5np wFNHDZjs73B/oYALcL+fM9apGpR4dPKzEUkDuFVqyhQ3IVFiK8Ie7mosOavnoXPnog1p 4uGWX71xviRY9VmC5hi8orOzkWR9Vnx7g4j1Q= Received: by 10.103.238.19 with SMTP id p19mr2220133mur.32.1249137010093; Sat, 01 Aug 2009 07:30:10 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id 12sm26471478muq.52.2009.08.01.07.30.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Aug 2009 07:30:09 -0700 (PDT) Message-ID: <4A745170.4030008@gmail.com> Date: Sat, 01 Aug 2009 16:30:08 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: xmpp@ietf.org References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> In-Reply-To: <4A736C06.4000203@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] presence subscriptions + desync 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, 01 Aug 2009 14:30:12 -0000 On 08/01/2009 12:11 AM, Peter Saint-Andre wrote: >> The main problem is IMO that the >> lacks a immediate acknowledgment by the contact's server. >> The acknowledgment is only sent after user interaction. >> > Hey, let's change presence subscriptions to use IQ stanzas. But then > we'd ack every one and really add some stanzas to the network... > Just out of interest... Presence: Total: 50 bytes IQ: Total: 134 bytes, increase of 84 bytes per request Well, it's more than a double, but I doubt anyone would even notice. How big share of traffic could possibly belong to subscription requests? From justin@affinix.com Sat Aug 1 09:09:34 2009 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 7C3573A67CC for ; Sat, 1 Aug 2009 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FcWex-QpGEw for ; Sat, 1 Aug 2009 09:09:33 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id CCB1C3A685F for ; Sat, 1 Aug 2009 09:09:33 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 2CDCF141C4 for ; Sat, 1 Aug 2009 09:09:33 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Sat, 1 Aug 2009 09:09:32 -0700 User-Agent: KMail/1.9.10 References: <057.68667927e0bb839c72dd253854f8adee@tools.ietf.org> <4A730B35.4090903@stpeter.im> <4A744CAE.4060905@gmail.com> In-Reply-To: <4A744CAE.4060905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908010909.32523.justin@affinix.com> Subject: Re: [xmpp] #3: whitespace pings are in fact keepalives 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, 01 Aug 2009 16:09:34 -0000 On Saturday 01 August 2009 07:09:50 Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrot= e: > On 07/31/2009 05:18 PM, Peter Saint-Andre wrote: > > On 7/7/09 12:52 AM, xmpp issue tracker wrote: > >> #3: whitespace pings are in fact keepalives > >> ... > > > > I have fixed this in my working copy. The paragraph in which the > > relevant text is found now reads as follows: > > > > An XML stream can appear idle at the XMPP level because the > > underlying TCP connection has become idle (e.g., a client's network > > connection has been lost). The typical method for detecting an idle > > TCP connection is to send a space character (U+0020) over the TCP > > connection between XML stanzas, which is allowed for XML streams as > > described under Section 12.7. The sending of such a space character > > is properly called a WHITESPACE KEEPALIVE (although the term > > "whitespace ping" is in common use, in fact it is not a ping since = no > > "pong" is possible). The time between such whitespace keepalives (= or > > other connection-testing methods) is a matter of implementation and > > local service policy; however, it is RECOMMENDED that any such test > > be performed not more than once every 60 seconds. > > > > Peter > > That's still not good. You can't use whitespace to detect idle > connection, because there is no response from the server and TCP timeout > is usually veeery long. The only use I can see would be preventing > connection timeout. That being said, it's not a "test" and the paragraph > in this form is strongly misleading. Even though the TCP timeout is very long, it's still better than no timeout= at=20 all. Servers send whitespace keepalives to clients, to bust connections th= at=20 might be broken. This will ensure dead clients get sweeped away in about 2= 0=20 minutes, rather than potentially never. =2DJustin From zarevucky.jiri@gmail.com Sat Aug 1 11:46:05 2009 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 4E23B3A6A37 for ; Sat, 1 Aug 2009 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 cXItzzhBmsJu for ; Sat, 1 Aug 2009 11:46:04 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1FE423A6A18 for ; Sat, 1 Aug 2009 11:46:03 -0700 (PDT) Received: by bwz19 with SMTP id 19so1745075bwz.37 for ; Sat, 01 Aug 2009 11:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EUJXARF/D2Meh3VgQdZ7qlW8WZqLjHRLvDXDLLi+AiA=; b=QN3yT6vqtj3LSNxw9CCvab3UIahGEx3Wdmk4QG4oZwIre8eggxdBpO4GOXpZ+rcBD5 6haMyU7weS8jOSYicZxGp5N4MGLs3+xVyIfIBTe+2OM2fKdBDrlSlGi/u28IlDZeO5tM /WaV15iGuWTCLpHrJ+c+zrB9XChrpres06m/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=a10qlkPXA2ofprUo4PAsofQHT/r4hUBW+Pg4vfO38JfuzuFDlovB+pAdB1J+Xyvs+3 K90fOv4Om0wJxzH6Z4epTiUMizZX4IPD1zPAnr17+q4t1Zk26KXZMeyoTzXD9s6KVS2l yyfu8Bfdp23tEPTUTvoRBhL3LtQbmOdp7h2v8= Received: by 10.103.213.9 with SMTP id p9mr2340098muq.121.1249152363511; Sat, 01 Aug 2009 11:46:03 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id 14sm27332090muo.3.2009.08.01.11.46.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Aug 2009 11:46:03 -0700 (PDT) Message-ID: <4A748D69.7060408@gmail.com> Date: Sat, 01 Aug 2009 20:46:01 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: xmpp@ietf.org References: <057.68667927e0bb839c72dd253854f8adee@tools.ietf.org> <4A730B35.4090903@stpeter.im> <4A744CAE.4060905@gmail.com> <200908010909.32523.justin@affinix.com> In-Reply-To: <200908010909.32523.justin@affinix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [xmpp] #3: whitespace pings are in fact keepalives 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, 01 Aug 2009 18:46:05 -0000 On 08/01/2009 06:09 PM, Justin Karneges wrote: > On Saturday 01 August 2009 07:09:50 Jiří Zárevúcky wrote: > >> On 07/31/2009 05:18 PM, Peter Saint-Andre wrote: >> >>> On 7/7/09 12:52 AM, xmpp issue tracker wrote: >>> >>>> #3: whitespace pings are in fact keepalives >>>> ... >>>> >>> I have fixed this in my working copy. The paragraph in which the >>> relevant text is found now reads as follows: >>> >>> An XML stream can appear idle at the XMPP level because the >>> underlying TCP connection has become idle (e.g., a client's network >>> connection has been lost). The typical method for detecting an idle >>> TCP connection is to send a space character (U+0020) over the TCP >>> connection between XML stanzas, which is allowed for XML streams as >>> described under Section 12.7. The sending of such a space character >>> is properly called a WHITESPACE KEEPALIVE (although the term >>> "whitespace ping" is in common use, in fact it is not a ping since no >>> "pong" is possible). The time between such whitespace keepalives (or >>> other connection-testing methods) is a matter of implementation and >>> local service policy; however, it is RECOMMENDED that any such test >>> be performed not more than once every 60 seconds. >>> >>> Peter >>> >> That's still not good. You can't use whitespace to detect idle >> connection, because there is no response from the server and TCP timeout >> is usually veeery long. The only use I can see would be preventing >> connection timeout. That being said, it's not a "test" and the paragraph >> in this form is strongly misleading. >> > Even though the TCP timeout is very long, it's still better than no timeout at > all. Servers send whitespace keepalives to clients, to bust connections that > might be broken. This will ensure dead clients get sweeped away in about 20 > minutes, rather than potentially never. > > -Justin > Yes, but 20 minutes still doesn't equal either "test" or "idle detection". That's why I'm saying the paragraph is misleading. Nobody who wants to sweep dead clients will likely rely on mechanism that takes 20 minutes to manifest itself. It's more likely server will cut the client sooner, for inactivity. From zarevucky.jiri@gmail.com Sat Aug 1 12:04:35 2009 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 9143F3A672F for ; Sat, 1 Aug 2009 12:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sKn9aymCHlGk for ; Sat, 1 Aug 2009 12:04:34 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 8EDC73A6D1B for ; Sat, 1 Aug 2009 12:04:16 -0700 (PDT) Received: by fxm17 with SMTP id 17so1935746fxm.37 for ; Sat, 01 Aug 2009 12:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=VxkOEytSAwuFzsagu0MWSNR58Ullqbu7KHPdbh2aj9E=; b=NFBNweJe/0wIOeJpI4leK9GSybrrv+rSuOuuhW1p3dRL+UqZeADs1HLb4pHVBZrjd1 SftaybbMKG8SudQV10PWtVKjMpnMVeoQsluXW5WiczFToyas6cb0KqdXW/8Ki5zSIzpn jaLEa/7vUaXKmqLJ9UNXr0vQi8KhOaFx06Fjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=svYkNbiVAZcuth45pC2GQpO7rYkYSaApAVzSKeZd3/V7QYAPY7hgExLqQlZC8yKiUl xnrClxEObPtKj1xWfi+y729ojN6okEpgI0AvdafeFUjEjy1ow7mMg/+q/kETzOAtY8Y5 FuvVIavRgubX6YytJGe9tiCpPft9ksUKax/1k= Received: by 10.102.218.6 with SMTP id q6mr1627641mug.93.1249153456028; Sat, 01 Aug 2009 12:04:16 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id w5sm20565898mue.34.2009.08.01.12.04.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Aug 2009 12:04:15 -0700 (PDT) Message-ID: <4A7491AE.9000907@gmail.com> Date: Sat, 01 Aug 2009 21:04:14 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Waqas Hussain References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> <4A745170.4030008@gmail.com> <7fc4fa880908011154l4a449004o5adbb6dd55fbc7be@mail.gmail.com> In-Reply-To: <7fc4fa880908011154l4a449004o5adbb6dd55fbc7be@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060407070304090509090806" Cc: xmpp@ietf.org Subject: Re: [xmpp] presence subscriptions + desync 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, 01 Aug 2009 19:04:35 -0000 This is a multi-part message in MIME format. --------------060407070304090509090806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08/01/2009 08:54 PM, Waqas Hussain wrote: > 2009/8/1 Jiří Zárevúcky > > > > Just out of interest... > > > Presence: > > > > Total: 50 bytes > > IQ: > > type="subscribe" to="user@example.org > "/> > > > Total: 134 bytes, increase of 84 bytes per request > > > Well, it's more than a double, but I doubt anyone would even notice. > How big share of traffic could possibly belong to subscription > requests? > > > That argument doesn't really apply. Compression pretty much reduces > the size difference to nothing. And such minor differences in size > have no real impact, thanks to the nature of packet switching > networks. The IQ reply though doubles the packet count. > > But as a counter argument, the IQ would happen just once, while the > subscription request may be resent more than once, until the contact > accepts or rejects it. > > That said, I think the current model is just fine, and changing it > would be much much more effort than it's worth. Unless you count in how nicer would it look in the XML console (just joking ;)). > What would IQs (or the presence based acks Philipp argued for) > achieve? Acknowledgement that the remote server received the request? > Stream management would do that just fine. Indeed. > > -- > Waqas Hussain > --------------060407070304090509090806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08/01/2009 08:54 PM, Waqas Hussain wrote:
2009/8/1 Jiří Zárevúcky <zarevucky.jiri@gmail.com>

Just out of interest...


Presence:

<presence type="subscribe" to="user@example.org"/>

Total: 50 bytes

IQ:

<iq type="set" id="254"><query xmlns="urn:xmpp:subscription" type="subscribe" to="user@example.org"/></iq>
<iq type="result" id="254"/>

Total: 134 bytes, increase of 84 bytes per request


Well, it's more than a double, but I doubt anyone would even notice.
How big share of traffic could possibly belong to subscription requests?

That argument doesn't really apply. Compression pretty much reduces the size difference to nothing. And such minor differences in size have no real impact, thanks to the nature of packet switching networks. The IQ reply though doubles the packet count.

But as a counter argument, the IQ would happen just once, while the subscription request may be resent more than once, until the contact accepts or rejects it.

That said, I think the current model is just fine, and changing it would be much much more effort than it's worth.

Unless you count in how nicer would it look in the XML console (just joking ;)).

What would IQs (or the presence based acks Philipp argued for) achieve? Acknowledgement that the remote server received the request? Stream management would do that just fine.

Indeed.


--
Waqas Hussain


--------------060407070304090509090806-- From klaus.hartke@googlemail.com Sun Aug 2 08:26:05 2009 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 EAF4E3A6950 for ; Sun, 2 Aug 2009 08:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 87IgJJPVT4uN for ; Sun, 2 Aug 2009 08:26:05 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id F228D3A6A4B for ; Sun, 2 Aug 2009 08:24:06 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so820590eye.31 for ; Sun, 02 Aug 2009 08:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=75GipgOj70V43hYs+iSuNyipzz4THHbM+J9lk8Jgjb8=; b=rM78DJw3qFOZyHJhBQJgC9vMczI12gDPUXophfLho907i+lBrMVi51L2Dge9ANj24t 8H6OMENKY2Ut9zCurPL3vth5cpUGpHYAkUd/kW+GW2pv7/3/rhvA1yj8xzvmBvPuh1uw pIVd9qe9kqlE9UBNESuKHw+cZH7w2wFSwngSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PueW0i6RBhZKJGGEOX2Cv6cHiRBPtuvqLsUq/RiTwGnTxRiX5dOZKI+oLFhYiApNWw Qr0a0R+XZWXXMhYmm6rFhSpftm6ACmzvNsuV8Q9eDfRec2bK/805vBfcVnw+vkFyiSq0 DDUzg4G3n/MRHXsdgvlRtdG/lIg2tH5lT75UU= MIME-Version: 1.0 Received: by 10.216.70.208 with SMTP id p58mr1007023wed.29.1249226646949; Sun, 02 Aug 2009 08:24:06 -0700 (PDT) In-Reply-To: <4A7491AE.9000907@gmail.com> References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> <4A745170.4030008@gmail.com> <7fc4fa880908011154l4a449004o5adbb6dd55fbc7be@mail.gmail.com> <4A7491AE.9000907@gmail.com> Date: Sun, 2 Aug 2009 17:24:06 +0200 Message-ID: <4d1e95de0908020824o6a916654gde6603e0b358bef8@mail.gmail.com> From: Klaus Hartke To: xmpp@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] presence subscriptions + desync 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, 02 Aug 2009 15:26:06 -0000 2009/8/1 Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky : > On 08/01/2009 08:54 PM, Waqas Hussain wrote: >> What would IQs (or the presence based acks Philipp argued for) achieve? >> Acknowledgement that the remote server received the request? Stream >> management would do that just fine. > > Indeed. (and ) stanzas are generally one-way -- except if they generate an error. The *only* way to handle these errors is to bubble them up to the user interface, regardless of what initiated the stanza, because the corresponding code will already have "moved on". On the other hand, code that sends an request usually blocks and waits for an result/error, so the error can be handled by the code itself and will not unconditionally be shown to the user. The code can decide itself what to with the error, whether to show it to the user, perform a different action or just ignore it. I think it's be desirable to have this behavior for actions that can fail. One-way stanzas should be used only if an action cannot fail or if the initiator doesn't need to be informed. Replies to one-way stanzas should be informational at most. Just my two (euro)cents. --K From trac@tools.ietf.org Mon Aug 3 12:09:24 2009 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 0E3493A677C for ; Mon, 3 Aug 2009 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 F627DoLJ376M for ; Mon, 3 Aug 2009 12:09:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id A94CF3A6EA6 for ; Mon, 3 Aug 2009 12:09:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MY2uB-0007pB-Go; Mon, 03 Aug 2009 12:09:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "xmpp issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: stpeter@stpeter.im X-Trac-Project: xmpp Date: Mon, 03 Aug 2009 19:09:07 -0000 X-URL: http://tools.ietf.org/xmpp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/xmpp/trac/ticket/1#comment:1 Message-ID: <066.e2802ebc25ba1243548f9a252e0d7451@tools.ietf.org> References: <057.6b3002661f874ecf6ea1638cffa6a05b@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <057.6b3002661f874ecf6ea1638cffa6a05b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stpeter@stpeter.im, xmpp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: xmpp@ietf.org Subject: Re: [xmpp] #1: mention SCTP as alternative transport? X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:09:24 -0000 #1: mention SCTP as alternative transport? -----------------------------------+---------------------------------------- Reporter: stpeter@stpeter.im | Owner: Peter Saint-Andre Type: enhancement | Status: closed Priority: minor | Milestone: milestone1 Component: 3920bis | Version: Severity: Submitted WG Document | Resolution: wontfix Keywords: | -----------------------------------+---------------------------------------- Changes (by stpeter@stpeter.im): * status: new => closed * resolution: => wontfix Comment: Mailing list consensus that alternative bindings shall be defined in specifications other than 3920bis, however we might mention the possibility of SCTP in 3920bis. -- Ticket URL: xmpp From stpeter@stpeter.im Mon Aug 3 12:44:50 2009 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 8550F28C1DF for ; Mon, 3 Aug 2009 12:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tntrxoooPygr for ; Mon, 3 Aug 2009 12:44:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5C9533A6A57 for ; Mon, 3 Aug 2009 12:44:49 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 495D24007B; Mon, 3 Aug 2009 13:44:38 -0600 (MDT) Message-ID: <4A773E24.7000705@stpeter.im> Date: Mon, 03 Aug 2009 13:44:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= References: <057.68667927e0bb839c72dd253854f8adee@tools.ietf.org> <4A730B35.4090903@stpeter.im> <4A744CAE.4060905@gmail.com> <200908010909.32523.justin@affinix.com> <4A748D69.7060408@gmail.com> In-Reply-To: <4A748D69.7060408@gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] #3: whitespace pings are in fact keepalives 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, 03 Aug 2009 19:44:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/1/09 12:46 PM, Jiří Zárevúcky wrote: > On 08/01/2009 06:09 PM, Justin Karneges wrote: >> On Saturday 01 August 2009 07:09:50 Jiří Zárevúcky wrote: >> >>> On 07/31/2009 05:18 PM, Peter Saint-Andre wrote: >>> >>>> On 7/7/09 12:52 AM, xmpp issue tracker wrote: >>>> >>>>> #3: whitespace pings are in fact keepalives >>>>> ... >>>>> >>>> I have fixed this in my working copy. The paragraph in which the >>>> relevant text is found now reads as follows: >>>> >>>> An XML stream can appear idle at the XMPP level because the >>>> underlying TCP connection has become idle (e.g., a client's >>>> network >>>> connection has been lost). The typical method for detecting an >>>> idle >>>> TCP connection is to send a space character (U+0020) over the TCP >>>> connection between XML stanzas, which is allowed for XML >>>> streams as >>>> described under Section 12.7. The sending of such a space >>>> character >>>> is properly called a WHITESPACE KEEPALIVE (although the term >>>> "whitespace ping" is in common use, in fact it is not a ping >>>> since no >>>> "pong" is possible). The time between such whitespace >>>> keepalives (or >>>> other connection-testing methods) is a matter of implementation >>>> and >>>> local service policy; however, it is RECOMMENDED that any such >>>> test >>>> be performed not more than once every 60 seconds. >>>> >>>> Peter >>>> >>> That's still not good. You can't use whitespace to detect idle >>> connection, because there is no response from the server and TCP timeout >>> is usually veeery long. The only use I can see would be preventing >>> connection timeout. That being said, it's not a "test" and the paragraph >>> in this form is strongly misleading. >>> >> Even though the TCP timeout is very long, it's still better than no >> timeout at >> all. Servers send whitespace keepalives to clients, to bust >> connections that >> might be broken. This will ensure dead clients get sweeped away in >> about 20 >> minutes, rather than potentially never. >> >> -Justin >> > > Yes, but 20 minutes still doesn't equal either "test" or "idle > detection". That's why I'm saying the paragraph is misleading. Nobody > who wants to sweep dead clients will likely rely on mechanism that takes > 20 minutes to manifest itself. It's more likely server will cut the > client sooner, for inactivity. The core XMPP specification will never solve this problem. However, it might be helpful to provide more detailed guidance to XMPP implementers on this topic, and to mention other connection-testing methods. Thus I have modified the text as follows. An XML stream can appear idle at the XMPP level because the underlying TCP connection has become idle (e.g., a client's network connection has been lost). One common method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7; the sending of such a space character is properly called a WHITESPACE KEEPALIVE (although the term "whitespace ping" is often used, in fact it is not a ping since no "pong" is possible). Other connection-testing methods include the application-level pings described in [XEP-0199] and the more comprehensive stream management protocol described in [XEP-0198]. Implementers are advised to support whichever connection-testing methods they deem appropriate, but to carefully weigh the network impact of such methods against the benefits of discovering idle streams in a timely manner. The length of time between the use of any particular connection test is a matter of implementation and local service policy; however, it is RECOMMENDED that any such test be performed not more than once every 60 seconds. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3PiQACgkQNL8k5A2w/vzDaQCeO8h1TOwWwFTzjmGIHIo6nTho TycAoLiFRAO7bAACu/ZnrCQTDGznG9Br =vk2O -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 3 13:43:28 2009 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 6D41728C290 for ; Mon, 3 Aug 2009 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgP9ftdFLuQQ for ; Mon, 3 Aug 2009 13:43:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 52AD128C297 for ; Mon, 3 Aug 2009 13:43:27 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CF3D24007B; Mon, 3 Aug 2009 14:43:27 -0600 (MDT) Message-ID: <4A774BEE.7030809@stpeter.im> Date: Mon, 03 Aug 2009 14:43:26 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Philipp Hancke References: <4be2be550907090820h245d149ct7c0362c1d312dcce@mail.gmail.com> <4A561E1E.5090902@goodadvice.pages.de> <4A5620F3.40203@stpeter.im> <4A564A30.1040204@mail.symlynx.com> <4A57B145.4080906@stpeter.im> <4A7374C9.5070803@stpeter.im> <4A774332.2050605@goodadvice.pages.de> In-Reply-To: <4A774332.2050605@goodadvice.pages.de> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] [Standards] none + pending in 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, 03 Aug 2009 20:43:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/3/09 2:06 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: > [...] >> In my working copy I now have the following text: >> >> APPENDIX A.1 >> >> 3. "None + Pending In" = contact and user are not subscribed to each >> other, and contact has sent user a subscription request but user >> has not replied yet; in fact, the user's server MUST NOT add the >> contact to the user's roster or and MUST NOT push or deliver >> roster items to the user in this state, but instead MUST simply > > Remove the "or and MUST NOT push or deliver roster items to the user in > this state" please - at least the "or" :-) > There are no roster items in that state unless the user had manually > added them before and those should still be delivered (see > http://mail.jabber.org/pipermail/standards/2009-July/022270.html ). > >> note the existence of the inbound presence subscription request >> and wait until the user has approved the subscription request >> before adding the contact to the user's roster. Aha, that was unclear. Adjusted/corrected text.... 3. "None + Pending In" = contact and user are not subscribed to each other, and contact has sent user a subscription request but user has not replied yet; this state might or might not be reflected in the user's roster, as follows: if the user has created a roster item for the contact then the server MUST maintain that roster item and simply note the existence of the inbound presence subscription request, but if not then the user's server MUST NOT create a roster item for the user and MUST simply note the existence of the inbound presence subscription request and wait until the user has approved the subscription request before adding the contact to the user's roster. >> SECTION 3.3.3 >> >> When the contact's server receives the unsubscribe notification, it >> MUST first check if the user is in the contact's roster with >> subscription='from' or subscription='both' (i.e., a subscription >> state of "From", "From + Pending Out", or "Both"; see Appendix A). >> If this check is successful, the contact's server MUST initiate a >> roster push to all of the contact's interested resources, containing >> an updated roster item for the contact with the 'subscription' >> attribute set to a value of "none" (if the subscription state was >> "From" or "From + Pending Out") or "to" (if the subscription state >> was "Both"). >> >> ... >> >> Otherwise -- that is, if the contact does not exist, if the user is >> not in the contact's roster, or if the user is in the contact's >> roster with a subscription state other than those described in the >> foregoing check -- then the contact's server MUST silently ignore the >> stanza by not delivering it to the contact, not modifying the >> contact's roster, and not generating a roster push to the contact's >> interested resources. However, if the contact's server is keeping >> track of an inbound presence subscription request from the user to >> the contact without having added the user to the contact's roster >> because the contact has not yet approved or denied the subscription >> request (equivalent to a roster state of "None + Pending In"), then > > s/roster state/subscription state/ Fixed in my working copy. >> the contact's server MUST simply remove any record of the inbound >> presence subscription request (it cannot remove the user from the >> contact's roster because the user was never added to the contact's >> roster). >> >> Let me know if I missed anything. > > looks quite good now. thanks! Super. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3S+4ACgkQNL8k5A2w/vyhEwCgoWH/damjIe4YgVsAjqwYFDjc CwsAoLC3XPabAMIozs6VOZMZg3PJXkkA =Bfxm -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 3 14:00:33 2009 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 49FBE28C212 for ; Mon, 3 Aug 2009 14:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I0rpUjohvAf for ; Mon, 3 Aug 2009 14:00:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 31CF53A6AD9 for ; Mon, 3 Aug 2009 14:00:32 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21FC840C89; Mon, 3 Aug 2009 15:00:34 -0600 (MDT) Message-ID: <4A774FF0.3030805@stpeter.im> Date: Mon, 03 Aug 2009 15:00:32 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Philipp Hancke References: <4be2be550907090820h245d149ct7c0362c1d312dcce@mail.gmail.com> <4A561E1E.5090902@goodadvice.pages.de> <4A5620F3.40203@stpeter.im> <4A564A30.1040204@mail.symlynx.com> <4A57B145.4080906@stpeter.im> <4A7374C9.5070803@stpeter.im> <4A774332.2050605@goodadvice.pages.de> <4A774BEE.7030809@stpeter.im> In-Reply-To: <4A774BEE.7030809@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] [Standards] none + pending in 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, 03 Aug 2009 21:00:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/3/09 2:43 PM, Peter Saint-Andre wrote: > On 8/3/09 2:06 PM, Philipp Hancke wrote: >> Peter Saint-Andre wrote: >> [...] >>> In my working copy I now have the following text: >>> >>> APPENDIX A.1 >>> >>> 3. "None + Pending In" = contact and user are not subscribed to each >>> other, and contact has sent user a subscription request but user >>> has not replied yet; in fact, the user's server MUST NOT add the >>> contact to the user's roster or and MUST NOT push or deliver >>> roster items to the user in this state, but instead MUST simply >> Remove the "or and MUST NOT push or deliver roster items to the user in >> this state" please - at least the "or" :-) >> There are no roster items in that state unless the user had manually >> added them before and those should still be delivered (see >> http://mail.jabber.org/pipermail/standards/2009-July/022270.html ). > >>> note the existence of the inbound presence subscription request >>> and wait until the user has approved the subscription request >>> before adding the contact to the user's roster. > > Aha, that was unclear. Adjusted/corrected text.... > > 3. "None + Pending In" = contact and user are not subscribed to each > other, and contact has sent user a subscription request but user > has not replied yet; this state might or might not be reflected > in the user's roster, as follows: if the user has created a > roster item for the contact then the server MUST maintain that > roster item and simply note the existence of the inbound presence > subscription request, but if not then the user's server MUST NOT > create a roster item for the user and MUST simply note the > existence of the inbound presence subscription request and wait > until the user has approved the subscription request before > adding the contact to the user's roster. In fact this is even better... 3. "None + Pending In" = contact and user are not subscribed to each other, and contact has sent user a subscription request but user has not replied yet; this state might or might not be reflected in the user's roster, as follows: if the user has created a roster item for the contact then the server MUST maintain that roster item and also note the existence of the inbound presence subscription request, whereas if the user has not created a roster item for the contact then the user's server MUST note the existence of the inbound presence subscription request but MUST NOT create a roster item for the contact (instead, the server MUST wait until the user has approved the subscription request before adding the contact to the user's roster). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3T/AACgkQNL8k5A2w/vxfGACdEymJ0szmev/V2jqURF4qa+ZU Y58An12yS2SJEzQXmEf3WykZ/X3ONQrS =FOCg -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 3 18:04:22 2009 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 AC4843A6922 for ; Mon, 3 Aug 2009 18:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 gjl380SSPREt for ; Mon, 3 Aug 2009 18:04:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2B3C928C0F3 for ; Mon, 3 Aug 2009 18:04:02 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 265B44007B; Mon, 3 Aug 2009 19:04:00 -0600 (MDT) Message-ID: <4A7788FE.9020605@stpeter.im> Date: Mon, 03 Aug 2009 19:03:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Klaus Hartke References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> <4A745170.4030008@gmail.com> <7fc4fa880908011154l4a449004o5adbb6dd55fbc7be@mail.gmail.com> <4A7491AE.9000907@gmail.com> <4d1e95de0908020824o6a916654gde6603e0b358bef8@mail.gmail.com> In-Reply-To: <4d1e95de0908020824o6a916654gde6603e0b358bef8@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] presence subscriptions + desync 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: Tue, 04 Aug 2009 01:04:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/2/09 9:24 AM, Klaus Hartke wrote: > 2009/8/1 Jiří Zárevúcky : >> On 08/01/2009 08:54 PM, Waqas Hussain wrote: >>> What would IQs (or the presence based acks Philipp argued for) achieve? >>> Acknowledgement that the remote server received the request? Stream >>> management would do that just fine. >> Indeed. > > (and ) stanzas are generally one-way -- except > if they generate an error. The *only* way to handle these errors is to > bubble them up to the user interface, regardless of what initiated the > stanza, because the corresponding code will already have "moved on". > > On the other hand, code that sends an request usually blocks and > waits for an result/error, so the error can be handled by the > code itself and will not unconditionally be shown to the user. The > code can decide itself what to with the error, whether to show it to > the user, perform a different action or just ignore it. > > I think it's be desirable to have this behavior for actions that can > fail. One-way stanzas should be used only if an action cannot fail or > if the initiator doesn't need to be informed. Replies to one-way > stanzas should be informational at most. In theory, yes. Are you proposing a modification to the presence subscription protocol? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3iP4ACgkQNL8k5A2w/vyFcwCgzd/1huKLMRtH44csXq+D+zFI 9UoAoI8ZROIajXEYC0CsV0crAxH19uEo =5fvJ -----END PGP SIGNATURE----- From Joe.Hildebrand@webex.com Tue Aug 4 09:49:40 2009 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 9E72E3A68BE for ; Tue, 4 Aug 2009 09:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.232 X-Spam-Level: X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brvDK7a59ATy for ; Tue, 4 Aug 2009 09:49:40 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id BB75028C3C1 for ; Tue, 4 Aug 2009 09:49:27 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 09:48:56 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Aug 2009 16:48:56 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 04 Aug 2009 10:48:55 -0600 From: Joe Hildebrand To: Peter Saint-Andre , =?ISO-8859-2?B?Smn47Q==?= =?ISO-8859-2?B?IFrhcmV2+mNreQ==?= Message-ID: Thread-Topic: [xmpp] #3: whitespace pings are in fact keepalives Thread-Index: AcoVI3Qj//nqAEhiz0q4td10zNgbnw== In-Reply-To: <4A773E24.7000705@stpeter.im> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Aug 2009 16:48:56.0564 (UTC) FILETIME=[75121B40:01CA1523] Cc: xmpp@ietf.org Subject: Re: [xmpp] #3: whitespace pings are in fact keepalives 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: Tue, 04 Aug 2009 16:49:40 -0000 Re: whitespace. Keep in mind that if one side of the connection uses this information to detect that the connection has gone bad in some way, that's great, but one of the main reasons we do the keepalives is to ensure that firewalls and NATs don't close the connection for inactivity. Typically, the traditional TCP keepalive does not occur often enough to meet these needs, so we simulate them in the application layer. -- Joe Hildebrand From kurt.zeilenga@isode.com Tue Aug 4 08:28:13 2009 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 477403A704F for ; Tue, 4 Aug 2009 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] 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 JZ3jAJVoxX9A for ; Tue, 4 Aug 2009 08:28:12 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 71EC03A702D for ; Tue, 4 Aug 2009 08:28:12 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Tue, 4 Aug 2009 16:27:57 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <1CF64405-1494-4647-9801-284D65223601@isode.com> From: Kurt Zeilenga To: xmpp@ietf.org Date: Tue, 4 Aug 2009 08:27:54 -0700 X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Aug 2009 09:50:00 -0700 Subject: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 15:28:13 -0000 While XMPP spec's discussion of extended content (Section 9.4 of 3920bis) says "XMPP uses XML namespaces (see [XML-NAMES] to extend the basic stanza syntax for the purpose of providing additional functionality", the subsequent discussion is limited to extension through addition of child elements. There is no discussion of whether one may extend XMPP elements through additional attributes. The specification should be clarified as whether such extensions are allowed or not. If allowed, the specification should include some guidance especially in regards to what implementations should do in face of attributes they don't recognize. (Note that I am not arguing that such extensions are or are not allowed, or what should or should not be allowed. I'm just asking for the specification to be clear on what is allowed or not.) -- Kurt From metajack@gmail.com Tue Aug 4 09:53:18 2009 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 3C0583A6CF5 for ; Tue, 4 Aug 2009 09:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 AdyuTV8raGAH for ; Tue, 4 Aug 2009 09:53:17 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 451383A6CBE for ; Tue, 4 Aug 2009 09:53:17 -0700 (PDT) Received: by ewy10 with SMTP id 10so484839ewy.37 for ; Tue, 04 Aug 2009 09:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0rP1hjvhVCI8VeO5FlWa7/5r/iWc09pbq8gY7cwUSm0=; b=jtsL4XH2/+dxotmIXa/wUOtXAP7ezvma6DV8h6s+HMwlgUqpJHlrimiWTVf8XlbNbV 8ygOhzZoXFwlrNuOCElEdVY5uxYdvhUcc8BpQAn9ZdviO8/MtZBJAgXlFRQeD+Uzovyu cybYRAZuHcRmziBzti96gjHNldzTsKesFVTpg= 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:content-type :content-transfer-encoding; b=SYDqLdbbRBwBHWkKXs50rUh0YciXr5GMs6uimo3bQMXy4ZB4ZdEQu9F0HTNCmm+8VT cjzxW0qWasYRNFseyvvSfCfO9A9dmJkNBJy1uJxUjnxhtfdTozM3O05Y4WaDXghhEFIB IPgVCq9p1Zkyz5m1nWTg7VAlhqehHBoesFDYQ= MIME-Version: 1.0 Sender: metajack@gmail.com Received: by 10.216.10.72 with SMTP id 50mr1413865weu.127.1249404784834; Tue, 04 Aug 2009 09:53:04 -0700 (PDT) In-Reply-To: <1CF64405-1494-4647-9801-284D65223601@isode.com> References: <1CF64405-1494-4647-9801-284D65223601@isode.com> Date: Tue, 4 Aug 2009 10:53:04 -0600 X-Google-Sender-Auth: a8b95f7629e95b08 Message-ID: <9b58f4550908040953q5b7ee535u605eb49b01c3f886@mail.gmail.com> From: Jack Moffitt To: xmpp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 16:53:18 -0000 > There is no discussion of whether one may extend XMPP elements through > additional attributes. =A0 The specification should be > clarified as whether such extensions are allowed or not. =A0If allowed, t= he > specification should include some guidance especially > in regards to what implementations should do in face of attributes they > don't recognize. I believe several XEPs do you extension attributes, so we should probably add that this is allowed. From stpeter@stpeter.im Tue Aug 4 11:58:34 2009 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 1F54F28C43E for ; Tue, 4 Aug 2009 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 mmDUTxltqVd5 for ; Tue, 4 Aug 2009 11:58:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ADEB028C384 for ; Tue, 4 Aug 2009 11:58:32 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A69F84007B; Tue, 4 Aug 2009 12:58:32 -0600 (MDT) Message-ID: <4A7884D7.1050104@stpeter.im> Date: Tue, 04 Aug 2009 12:58:31 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Kurt Zeilenga References: <1CF64405-1494-4647-9801-284D65223601@isode.com> In-Reply-To: <1CF64405-1494-4647-9801-284D65223601@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 18:58:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/4/09 9:27 AM, Kurt Zeilenga wrote: > While XMPP spec's discussion of extended content (Section 9.4 of > 3920bis) says "XMPP uses XML namespaces (see [XML-NAMES] > to extend the basic stanza syntax for the purpose of providing > additional functionality", the subsequent discussion is > limited to extension through addition of child elements. > > There is no discussion of whether one may extend XMPP elements through > additional attributes. The specification should be > clarified as whether such extensions are allowed or not. Nothing in the spec has ever forbidden extended attributes instead of extended elements. However, there is a tradition in the XMPP community of using only elements for the various extensions, not attributes. I freely grant that this custom might have emerged because of limitations in the earliest implementations. > If allowed, > the specification should include some guidance especially > in regards to what implementations should do in face of attributes they > don't recognize. I would assume that they would ignore unrecognized attributes, just as they currently ignore unrecognized elements. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4hNcACgkQNL8k5A2w/vyL9gCfSJq5cFPumVloi/gtrMmSAtJ8 75IAoIXc0AWK51sBP8rVKlZJcnAtQXBo =rFyU -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Aug 4 12:02:49 2009 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 AA57C3A69B8 for ; Tue, 4 Aug 2009 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] 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 gsxogeZpdxRW for ; Tue, 4 Aug 2009 12:02:49 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D12933A686A for ; Tue, 4 Aug 2009 12:02:48 -0700 (PDT) Received: from [172.16.2.161] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Aug 2009 20:02:36 +0100 Message-ID: <4A7885A8.6040708@isode.com> Date: Tue, 04 Aug 2009 20:02:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <1CF64405-1494-4647-9801-284D65223601@isode.com> <4A7884D7.1050104@stpeter.im> In-Reply-To: <4A7884D7.1050104@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt Zeilenga , xmpp@ietf.org Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 19:02:49 -0000 Peter Saint-Andre wrote: >On 8/4/09 9:27 AM, Kurt Zeilenga wrote: > > >>While XMPP spec's discussion of extended content (Section 9.4 of >>3920bis) says "XMPP uses XML namespaces (see [XML-NAMES] >>to extend the basic stanza syntax for the purpose of providing >>additional functionality", the subsequent discussion is >>limited to extension through addition of child elements. >> >>There is no discussion of whether one may extend XMPP elements through >>additional attributes. The specification should be >>clarified as whether such extensions are allowed or not. >> >> >Nothing in the spec has ever forbidden extended attributes instead of >extended elements. However, there is a tradition in the XMPP community >of using only elements for the various extensions, not attributes. I >freely grant that this custom might have emerged because of limitations >in the earliest implementations. > > >>If allowed, >>the specification should include some guidance especially >>in regards to what implementations should do in face of attributes they >>don't recognize. >> >> >I would assume that they would ignore unrecognized attributes, just as >they currently ignore unrecognized elements. > > I agree with Kurt that this needs to be explicitly stated in the spec. From Joe.Hildebrand@webex.com Tue Aug 4 12:52:07 2009 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 DA5883A6B76 for ; Tue, 4 Aug 2009 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.382 X-Spam-Level: X-Spam-Status: No, score=-104.382 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 SKxN8KJUFDW7 for ; Tue, 4 Aug 2009 12:52:07 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 3FB643A6FFC for ; Tue, 4 Aug 2009 12:52:07 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 12:52:09 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Aug 2009 19:52:09 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 04 Aug 2009 13:52:08 -0600 From: Joe Hildebrand To: Peter Saint-Andre , Kurt Zeilenga Message-ID: Thread-Topic: [xmpp] extensibility of existing XMPP elements Thread-Index: AcoVPQx6KWMm4teiT0W9NYUOhzJXMw== In-Reply-To: <4A7884D7.1050104@stpeter.im> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Aug 2009 19:52:09.0471 (UTC) FILETIME=[0D5A98F0:01CA153D] Cc: xmpp@ietf.org Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 19:52:07 -0000 On 8/4/09 12:58 PM, "Peter Saint-Andre" wrote: > I would assume that they would ignore unrecognized attributes, just as > they currently ignore unrecognized elements. As long as you add "and MAY discard unrecognized elements, particularly on stanza elements", then I'm fine with it. In other words: feel free to send them, but don't expect me to forward them along. -- Joe Hildebrand From metajack@gmail.com Tue Aug 4 13:08:00 2009 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 14A123A692B for ; Tue, 4 Aug 2009 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 6CWE6Oio173B for ; Tue, 4 Aug 2009 13:07:59 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 2854E3A6822 for ; Tue, 4 Aug 2009 13:07:59 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so40127eye.31 for ; Tue, 04 Aug 2009 13:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=AhXSjtUnPWlJl2JiknMcuLvxqsuBxYDzxNNE5mqDNwY=; b=dpgx2F7kJ0Mhu9VkbRKc5XKs3WEUWm3NIrXuLQ4v74YTsU8ZRAl9lct8a/7RDndkK7 wcnNsrBrFpZwW6+bHL8z00WHROvke2PPnbBDAwlhCTgPtN3awYk+xmF5g5oXxKXeE7c/ zO5cmYTiO9AeSe2o9e7Oc6FySxKr5glyE2JJ0= 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:content-type :content-transfer-encoding; b=SNSiP9oNYnW1JVT1BXp4hSCRmr9B/b4IFrWQCLKeb8a0R6Kp8oiU/ZsH36dfJrNb/Z 9PkWPVtrZ80itM71HPO5bhypRscQNSQFNqrT/bCrgUQ4JtxoegMXj3kkl5Rd5YEarN30 ER3YPbO65wZHKRZG8lJKfW4cHKPuZiatItEas= MIME-Version: 1.0 Sender: metajack@gmail.com Received: by 10.216.52.76 with SMTP id d54mr1557967wec.119.1249416477729; Tue, 04 Aug 2009 13:07:57 -0700 (PDT) In-Reply-To: References: <4A7884D7.1050104@stpeter.im> Date: Tue, 4 Aug 2009 14:07:57 -0600 X-Google-Sender-Auth: 81f9d9604313c667 Message-ID: <9b58f4550908041307h1510f746j4220917f50b34912@mail.gmail.com> From: Jack Moffitt To: xmpp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 20:08:00 -0000 > In other words: feel free to send them, but don't expect me to forward them > along. Yuck. Doesn't that defeat the whole purpose? How about we formalize where namespaced things can go so that you can not have these on the top level stanza, but any child element is guaranteed to have the payload forwarded along? I suppose we have to leave some leeway in there for stripping stuff out for mobile clients. Perhaps that's what you meant? jack. From dave@cridland.net Tue Aug 4 13:14:52 2009 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 256ED3A6D72 for ; Tue, 4 Aug 2009 13:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWDFxcak69+l for ; Tue, 4 Aug 2009 13:14:50 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 896E63A709A for ; Tue, 4 Aug 2009 13:14:20 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 4 Aug 2009 21:14:08 +0100 X-SMTP-Protocol-Errors: NORDNS References: <4A7884D7.1050104@stpeter.im> <9b58f4550908041307h1510f746j4220917f50b34912@mail.gmail.com> In-Reply-To: <9b58f4550908041307h1510f746j4220917f50b34912@mail.gmail.com> MIME-Version: 1.0 Message-Id: <30680.1249416758.363996@puncture> Date: Tue, 04 Aug 2009 21:12:38 +0100 From: Dave Cridland To: Jack Moffitt , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 20:14:52 -0000 On Tue Aug 4 21:07:57 2009, Jack Moffitt wrote: > > In other words: feel free to send them, but don't expect me to > forward them > > along. > > Yuck. Doesn't that defeat the whole purpose? How about we > formalize > where namespaced things can go so that you can not have these on the > top level stanza, but any child element is guaranteed to have the > payload forwarded along? I suppose we have to leave some leeway in > there for stripping stuff out for mobile clients. Perhaps that's > what > you meant? Right - the stanza element is for the consumption by the hop, and the peer may (and in some cases almost always will) tweak or entirely replace the attributes before forwarding, but never the contents. 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 randy@qualcomm.com Tue Aug 4 14:14:24 2009 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 171E53A70CC for ; Tue, 4 Aug 2009 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.538 X-Spam-Level: X-Spam-Status: No, score=-105.538 tagged_above=-999 required=5 tests=[AWL=1.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PpHvE2wd7kTG for ; Tue, 4 Aug 2009 14:14:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4B6EA3A70DC for ; Tue, 4 Aug 2009 14:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1249420454; x=1280956454; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<30680.1249416758.363996@puncture> |References:=20<4A7884D7.1050104@stpeter.im>=0D=0A=20=0D=0A=20<9b58f45509 08041307h1510f746j4220917f50b34912@mail.gmail.com>=0D=0A =20<30680.1249416758.363996@puncture>|X-Mailer:=20Eudora =20for=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outloo k=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Tue,=204=20Aug=202009=2014:12:28=20-07 00|To:=20Dave=20Cridland=20,=20Jack=20 Moffitt=20,=0D=0A=20=20=20=20=20=20=20 =20XMPP=0D=0A=20Working=20Group=20|From: =20Randall=20Gellens=20|Subject:=20Re :=20[xmpp]=20extensibility=20of=20existing=20XMPP=20eleme nts|MIME-Version:=201.0|Content-Type:=20text/plain=3B=20c harset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5698"=3B=20a=3D"21660307"; bh=VbbYcNQzRvhwkYpZ1ZRXc6M0k2Ek89fG5TU0EoU7yYg=; b=itsFKpdZpoA9wJlrlUUlGhp6oafW2sxQCBkzCZImHkS5ty5QMncs6VbX GjrlOfbUAaAk1wYEJQKX0Vem2dnb5G5e0kroes9qNHfOR1qdI2DSKK7kT 2yav0zUoZPOPi1lgofQr9qp17xSblj1k27pI7d2EjuA4BUyMSg/pXe5MH k=; X-IronPort-AV: E=McAfee;i="5300,2777,5698"; a="21660307" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2009 14:14:14 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74LEDDp018570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 14:14:14 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74LEBBu026489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Aug 2009 14:14:11 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 4 Aug 2009 14:14:11 -0700 Received: from [78.64.88.186] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 4 Aug 2009 14:14:10 -0700 Message-ID: In-Reply-To: <30680.1249416758.363996@puncture> References: <4A7884D7.1050104@stpeter.im> <9b58f4550908041307h1510f746j4220917f50b34912@mail.gmail.com> <30680.1249416758.363996@puncture> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 4 Aug 2009 14:12:28 -0700 To: Dave Cridland , Jack Moffitt , XMPP Working Group From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 21:14:24 -0000 At 9:12 PM +0100 8/4/09, Dave Cridland wrote: > On Tue Aug 4 21:07:57 2009, Jack Moffitt wrote: >> > In other words: feel free to send them, but don't expect me to >> forward them >>> along. >> >> Yuck. Doesn't that defeat the whole purpose? How about we formalize >> where namespaced things can go so that you can not have these on the >> top level stanza, but any child element is guaranteed to have the >> payload forwarded along? I suppose we have to leave some leeway in >> there for stripping stuff out for mobile clients. Perhaps that's what >> you meant? > > Right - the stanza element is for the consumption by the hop, and > the peer may (and in some cases almost always will) tweak or > entirely replace the attributes before forwarding, but never the > contents. So extension attributes MAY be sent in any stanza, including top-level ones, but unrecognized attributes in a top-level stanza MAY be discarded? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The chance of forgetting something is directly proportional to.....to........uh.............. From Joe.Hildebrand@webex.com Tue Aug 4 14:59:59 2009 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 DCB0B28C461 for ; Tue, 4 Aug 2009 14:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.457 X-Spam-Level: X-Spam-Status: No, score=-104.457 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 4KE7ZoDcr5nH for ; Tue, 4 Aug 2009 14:59:59 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id AFA003A7049 for ; Tue, 4 Aug 2009 14:59:49 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 14:59:52 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Aug 2009 21:59:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 04 Aug 2009 15:59:43 -0600 From: Joe Hildebrand To: Randall Gellens , Dave Cridland , Jack Moffitt , XMPP Working Group Message-ID: Thread-Topic: [xmpp] extensibility of existing XMPP elements Thread-Index: AcoVTt82entokLPW7UKicID1CTlG3Q== In-Reply-To: IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Aug 2009 21:59:52.0242 (UTC) FILETIME=[E4B8A920:01CA154E] Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 22:00:00 -0000 On 8/4/09 3:12 PM, "Randall Gellens" wrote: > At 9:12 PM +0100 8/4/09, Dave Cridland wrote: > >> On Tue Aug 4 21:07:57 2009, Jack Moffitt wrote: >>>> In other words: feel free to send them, but don't expect me to >>> forward them >>>> along. >>> >>> Yuck. Doesn't that defeat the whole purpose? How about we formalize >>> where namespaced things can go so that you can not have these on the >>> top level stanza, but any child element is guaranteed to have the >>> payload forwarded along? I suppose we have to leave some leeway in >>> there for stripping stuff out for mobile clients. Perhaps that's what >>> you meant? >> >> Right - the stanza element is for the consumption by the hop, and >> the peer may (and in some cases almost always will) tweak or >> entirely replace the attributes before forwarding, but never the >> contents Right. I wouldn't expect namespaced attributes on the stanza to make it through all existing implementations, for example. > So extension attributes MAY be sent in any stanza, including > top-level ones, but unrecognized attributes in a top-level stanza MAY > be discarded? Yes, plus: "therefore extension attributes on stanza elements SHOULD be avoided for maximum interoperability" -- Joe Hildebrand From Kurt.Zeilenga@Isode.com Tue Aug 4 15:02:57 2009 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 10A2D28C3EE for ; Tue, 4 Aug 2009 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] 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 A1j-G313eNHk for ; Tue, 4 Aug 2009 15:02:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2DD0C3A69ED for ; Tue, 4 Aug 2009 15:02:56 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 4 Aug 2009 23:02:58 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <8CC3FB93-1557-479B-91EF-31AF389322DD@Isode.com> From: Kurt Zeilenga To: Joe Hildebrand In-Reply-To: Date: Tue, 4 Aug 2009 15:02:54 -0700 References: X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: Randall Gellens , XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Tue, 04 Aug 2009 22:02:57 -0000 On Aug 4, 2009, at 2:59 PM, Joe Hildebrand wrote: > On 8/4/09 3:12 PM, "Randall Gellens" wrote: > >> At 9:12 PM +0100 8/4/09, Dave Cridland wrote: >> >>> On Tue Aug 4 21:07:57 2009, Jack Moffitt wrote: >>>>> In other words: feel free to send them, but don't expect me to >>>> forward them >>>>> along. >>>> >>>> Yuck. Doesn't that defeat the whole purpose? How about we >>>> formalize >>>> where namespaced things can go so that you can not have these on >>>> the >>>> top level stanza, but any child element is guaranteed to have the >>>> payload forwarded along? I suppose we have to leave some leeway in >>>> there for stripping stuff out for mobile clients. Perhaps that's >>>> what >>>> you meant? >>> >>> Right - the stanza element is for the consumption by the hop, and >>> the peer may (and in some cases almost always will) tweak or >>> entirely replace the attributes before forwarding, but never the >>> contents > > Right. I wouldn't expect namespaced attributes on the stanza to > make it > through all existing implementations, for example. I'm more curious about namespaced attributes on children of the stanza, such as . -- Kurt From Kurt.Zeilenga@Isode.com Tue Aug 4 19:32:51 2009 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 635B73A6CEF for ; Tue, 4 Aug 2009 19:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] 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 wtcubGDOHAOZ for ; Tue, 4 Aug 2009 19:32:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3DAE03A70B9 for ; Tue, 4 Aug 2009 19:32:50 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 5 Aug 2009 03:32:51 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> From: Kurt Zeilenga To: XMPP Working Group Date: Tue, 4 Aug 2009 19:32:49 -0700 References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 02:32:51 -0000 The definition of 'id' (9.1.3 of 3920bis) says: > The 'id' attribute MAY be used by a sending entity for internal > tracking of stanzas that it sends and receives (especially for > tracking the request-response interaction inherent in the semantics > of IQ stanzas). The value of the 'id' attribute MAY be unique > globally, within a domain, or within a stream. The semantics of IQ > stanzas impose additional restrictions; see Section 9.2.3. I think the first MAY is trying to do two things at once. It's trying to 1) state that providing the 'id' attribute is at the sending entity's option and 2) what the purpose of the attribute is. I think it would be better to separate these. For instance: The purpose of the id attribute is to allow a response stanza to be associated with a particular request stanza. Except where specified differently, the entity originating a request stanza MAY include an 'id' attribute. I note that 'sending entity' is a term that not well defined. Elsewhere in the document, 'sending entity' simply refers to the entity which sent a particular stanza (and 'receiving entity' simply refers to an entity which received a particular stanza). If we use this meaning here, this sentence could be read that the entity sending a response stanza has the option not to include the id attribute provided in the request stanza as it is 'sending' the response stanza. Even if we took the 'sending entity' to refer to a party sending a request, that would imply that a server sending a request on behalf of a client MAY not include the id attribute the client provided when it originated the request. I would think for this feature to "work" in general, an entity responding to a request containing an id attribute MUST provide an id attribute with the same value as the request contained in the request. This requirement does not appear to be well specified. As far as unique, no uniqueness property should be assumed by the receiving entity. The receiving property should treat id values as opaque value. While the originating entity of a request could ensure values they generate have some uniqueness property, the only actual requirement is that originating entities SHOULD produce values in a manner which ensures that outstanding requests (requests they've sent but have yet to receive a response for) do not share the same value. For instance, an implementation which serializes it requests (never has more than one outstanding) could use the same id value for all requests it generates. -- Kurt From Joe.Hildebrand@webex.com Tue Aug 4 22:35:39 2009 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 71B0E28C393 for ; Tue, 4 Aug 2009 22:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, 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 4n--ODQqCXZ4 for ; Tue, 4 Aug 2009 22:35:35 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 2A74328C47C for ; Tue, 4 Aug 2009 22:34:20 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 22:34:22 -0700 Received: from 10.21.144.221 ([10.21.144.221]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Aug 2009 05:27:54 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 04 Aug 2009 23:27:53 -0600 From: Joe Hildebrand To: Kurt Zeilenga Message-ID: Thread-Topic: [xmpp] extensibility of existing XMPP elements Thread-Index: AcoVjXrmO2/ytvsGZESxFW09NOd3gg== In-Reply-To: <8CC3FB93-1557-479B-91EF-31AF389322DD@Isode.com> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 05:34:23.0168 (UTC) FILETIME=[6375BC00:01CA158E] Cc: Randall Gellens , XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Wed, 05 Aug 2009 05:35:39 -0000 On 8/4/09 4:02 PM, "Kurt Zeilenga" wrote: > I'm more curious about namespaced attributes on children of the > stanza, such as . We've always told people not to muck with the pre-defined stuff. Perhaps instead of saying stanza, we could say anything in jabber:client (or jabber:component:accept of course). -- Joe Hildebrand From fippo@mail.symlynx.com Wed Aug 5 01:39:44 2009 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 E8D9D3A6F0A for ; Wed, 5 Aug 2009 01:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 mXCREmAISSp3 for ; Wed, 5 Aug 2009 01:39:44 -0700 (PDT) Received: from lectern.tobij.de (lectern.tobij.de [62.75.216.40]) by core3.amsl.com (Postfix) with ESMTP id 50C5E3A707A for ; Wed, 5 Aug 2009 01:38:44 -0700 (PDT) Received: from [192.168.178.20] (p548BFD4A.dip.t-dialin.net [84.139.253.74]) (authenticated bits=0) by lectern.tobij.de (8.14.0/8.14.0) with ESMTP id n758cixL017047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2009 10:38:45 +0200 Message-ID: <4A79450C.1040401@mail.symlynx.com> Date: Wed, 05 Aug 2009 10:38:36 +0200 From: Philipp Hancke User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xmpp@ietf.org References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> In-Reply-To: <4A736C06.4000203@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] presence subscriptions + desync 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: Wed, 05 Aug 2009 08:39:45 -0000 Peter Saint-Andre wrote: > On 7/16/09 9:28 PM, Philipp Hancke wrote: >> section 3.1.2 in 3921bis states: >> | If the contact does not approve or deny the subscription request >> | within some configurable amount of time, the user's server SHOULD >> | resend the subscription request to the contact based on an >> | implementation-specific algorithm > >> This change shifts the responsibility for error detection and handling >> from client (rfc 3921, 8.2 step 5) to the server (smart servers!). > > Not exactly, because nothing prevents the client from sending a > subscription request again, too. But in practice clients do not > automatically resend subscription requests, and I expect that end users > rarely use the manual "resend subscription request" feature in clients > like Psi (plus, many clients do not even include such a feature). > >> Why was this responsiblity shifted? Actually, are there clients that >> implement the "old" version? Those that I tested did simply ignore the >> error... > > Correct. This - in combination with servers not handling subscription-related errors - might well be responsible for >90% of the problems. It might be worthwile to describe some presence subscription related error flows in more detail - subscribe is probably the most important one. >> Resending the subscription request as proposed is hardly an option. If >> the contact is offline for some weeks, the user's server will try to >> resend for quite a number of times, without any necessicity. > > Let's say that the user's server resends the subscription request once a > day while the contact is on vacation for five weeks (we'll assume that > the contact lives in Europe :P). That's 35 additional presence stanzas, > and such stanzas are extremely small. I don't see a huge network impact > here. presence subscriptions don't have a big impact on the network anyway - Matthias once said they make up 0.6 percent of all stanzas. And I think it is even less than that. >> The main problem is IMO that the >> lacks a immediate acknowledgment by the contact's server. >> The acknowledgment is only sent after user interaction. > > Hey, let's change presence subscriptions to use IQ stanzas. But then > we'd ack every one and really add some stanzas to the network... Too much backward compat hassle. The current protocol is mostly fine. >> Is that because the subscription protocol predates the concept >> of a "remote server"? > > Certainly not -- Jabber technologies were never envisioned as a service > silo, even at the very beginning. Neither was IRC, but then Jarko wrote killer.c :-) >> A possible solution is to provide a preliminary acknowledgement >> for that request by sending an unavailable presence: >> > type='unavailable' id='subscription1' /> > > Presence leak! That's simply not going to fly. contact@example.org is a bare JID. That stanza would be sent by the contacts server when processing the inbound subscription request. >> This implies that the contact is technically reachable, and - if the >> original subscription request was tagged with an id attribute - is >> an cheap alternative for an iq-based request response protocol. >> Stop resending if you receive this ack. > > If we really think we need this, we'll need to define an ack other than > "unavailable", or specify the polling method that I described in the > text you quoted. You don't need a new type value either, because the proposed ack is uniquely identified by type=unavailable and the id attribute. The polling method is good and should be used especially when an error occured during the subscription mechanism (but not for error cases where the user mistyped the host-part of the JID). >> A similar argument applies to , for which >> there should be an acknowledgment as well. > > "SHOULD" on what basis? If the "unsubscribed" from the contact never > reaches the user, the user's server will send a presence probe to the > contact when the user comes online, and the contact's server will answer > that probe with "unsbuscribed" (because according to the contact's > server the user is not subscribed to the contact). This will happen > every time that the contact comes online. I rather doubt that the Which might be hours or days later or might never happen at all. > connectivity from the contact's server to the user's server will be so > fubar'd that none of these "unsubscribed" stanzas will ever be passed > over the s2s link (and if that is the case, there are bigger problems > than subscription state synchronization). Therefore I don't think that > we would ever need to ack "unsubscribed". Sending unsubscribed already helps alot, yes. > Therefore I conclude that the only direction we need to heal is the > outbound subscription from user to contact. Here the user (or the user's > server) can simply poll once in a while to make sure that the subscribe > request went through and will be answered at some point. No, it's not > beautiful and elegant, but it works with existing infrastructure without > presence leaks or new values of the presence 'type' attribute. so does my proposal :-) philipp From stpeter@stpeter.im Wed Aug 5 05:05:32 2009 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 12DF33A69DD for ; Wed, 5 Aug 2009 05:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] 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 E7HuZma2ozzw for ; Wed, 5 Aug 2009 05:05:31 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D8E9E3A684A for ; Wed, 5 Aug 2009 05:05:30 -0700 (PDT) Received: from squire.local (dsl-205-186.dynamic-dsl.frii.net [216.17.205.186]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0FCF64007B; Wed, 5 Aug 2009 06:05:32 -0600 (MDT) Message-ID: <4A797587.1080409@stpeter.im> Date: Wed, 05 Aug 2009 06:05:27 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Philipp Hancke References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> <4A79450C.1040401@mail.symlynx.com> In-Reply-To: <4A79450C.1040401@mail.symlynx.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] presence subscriptions + desync 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: Wed, 05 Aug 2009 12:05:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/5/09 2:38 AM, Philipp Hancke wrote: > Peter Saint-Andre wrote: >> On 7/16/09 9:28 PM, Philipp Hancke wrote: >>> section 3.1.2 in 3921bis states: >>> | If the contact does not approve or deny the subscription request >>> | within some configurable amount of time, the user's server SHOULD >>> | resend the subscription request to the contact based on an >>> | implementation-specific algorithm >> >>> This change shifts the responsibility for error detection and handling >>> from client (rfc 3921, 8.2 step 5) to the server (smart servers!). >> >> Not exactly, because nothing prevents the client from sending a >> subscription request again, too. But in practice clients do not >> automatically resend subscription requests, and I expect that end users >> rarely use the manual "resend subscription request" feature in clients >> like Psi (plus, many clients do not even include such a feature). >> >>> Why was this responsiblity shifted? Actually, are there clients that >>> implement the "old" version? Those that I tested did simply ignore the >>> error... >> >> Correct. > > This - in combination with servers not handling subscription-related > errors - might well be responsible for >90% of the problems. > > It might be worthwile to describe some presence subscription related > error flows in more detail - subscribe is probably the most important > one. Feel free. :) I probably won't have time to do that until Monday. >>> Resending the subscription request as proposed is hardly an option. If >>> the contact is offline for some weeks, the user's server will try to >>> resend for quite a number of times, without any necessicity. >> >> Let's say that the user's server resends the subscription request once a >> day while the contact is on vacation for five weeks (we'll assume that >> the contact lives in Europe :P). That's 35 additional presence stanzas, >> and such stanzas are extremely small. I don't see a huge network impact >> here. > > presence subscriptions don't have a big impact on the network anyway - > Matthias once said they make up 0.6 percent of all stanzas. And I think > it is even less than that. Sounds about right. >>> The main problem is IMO that the >>> lacks a immediate acknowledgment by the contact's server. >>> The acknowledgment is only sent after user interaction. >> >> Hey, let's change presence subscriptions to use IQ stanzas. But then >> we'd ack every one and really add some stanzas to the network... > > Too much backward compat hassle. The current protocol is mostly fine. > >>> Is that because the subscription protocol predates the concept >>> of a "remote server"? >> >> Certainly not -- Jabber technologies were never envisioned as a service >> silo, even at the very beginning. > > Neither was IRC, but then Jarko wrote killer.c :-) > >>> A possible solution is to provide a preliminary acknowledgement >>> for that request by sending an unavailable presence: >>> >> type='unavailable' id='subscription1' /> >> >> Presence leak! That's simply not going to fly. > > contact@example.org is a bare JID. That stanza would be sent by the > contacts server when processing the inbound subscription request. Ah, I see, you meant the bare JID. That might work. Essentially that tells the user "as far as you're concerned, the contact is offline right now" (if that presence stanza is even delivered by the user's server to the user's client). >>> This implies that the contact is technically reachable, and - if the >>> original subscription request was tagged with an id attribute - is >>> an cheap alternative for an iq-based request response protocol. >>> Stop resending if you receive this ack. >> >> If we really think we need this, we'll need to define an ack other than >> "unavailable", or specify the polling method that I described in the >> text you quoted. > > You don't need a new type value either, because the proposed ack is > uniquely identified by type=unavailable and the id attribute. I think that no clients use 'id' on presence, but naturally they are free to do so if they want tracking. > The polling method is good and should be used especially when an > error occured during the subscription mechanism (but not for error > cases where the user mistyped the host-part of the JID). Yes, that makes sense. >>> A similar argument applies to , for which >>> there should be an acknowledgment as well. >> >> "SHOULD" on what basis? If the "unsubscribed" from the contact never >> reaches the user, the user's server will send a presence probe to the >> contact when the user comes online, and the contact's server will answer >> that probe with "unsubscribed" (because according to the contact's >> server the user is not subscribed to the contact). This will happen >> every time that the contact comes online. I rather doubt that the > > Which might be hours or days later or might never happen at all. That's the nature of presence. :) I really don't see much need for an ack here, but if we defined one what would you propose? >> connectivity from the contact's server to the user's server will be so >> fubar'd that none of these "unsubscribed" stanzas will ever be passed >> over the s2s link (and if that is the case, there are bigger problems >> than subscription state synchronization). Therefore I don't think that >> we would ever need to ack "unsubscribed". > > Sending unsubscribed already helps alot, yes. > >> Therefore I conclude that the only direction we need to heal is the >> outbound subscription from user to contact. Here the user (or the user's >> server) can simply poll once in a while to make sure that the subscribe >> request went through and will be answered at some point. No, it's not >> beautiful and elegant, but it works with existing infrastructure without >> presence leaks or new values of the presence 'type' attribute. > > so does my proposal :-) I think that unavailable from the bare JID would work fine as an ack for subscribe. It would be interesting to map out some of the error cases. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5dYcACgkQNL8k5A2w/vwJ/wCeOqvH1lvzgwQTAYdptfk8pXgV X7sAoNN4K3p+IdRmftaay2xxC23Th7Oc =nkPC -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Aug 5 06:42:02 2009 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 54D193A67DF for ; Wed, 5 Aug 2009 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] 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 OEVyYtB5q928 for ; Wed, 5 Aug 2009 06:42:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 78BD73A6F3A for ; Wed, 5 Aug 2009 06:42:01 -0700 (PDT) Received: from squire.local (dsl-205-186.dynamic-dsl.frii.net [216.17.205.186]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D686240C29; Wed, 5 Aug 2009 07:41:53 -0600 (MDT) Message-ID: <4A798C20.4050105@stpeter.im> Date: Wed, 05 Aug 2009 07:41:52 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Philipp Hancke References: <4A5F7F77.2000608@mail.symlynx.com> <4A736C06.4000203@stpeter.im> <4A79450C.1040401@mail.symlynx.com> <4A797587.1080409@stpeter.im> In-Reply-To: <4A797587.1080409@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] presence subscriptions + desync 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: Wed, 05 Aug 2009 13:42:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/5/09 6:05 AM, Peter Saint-Andre wrote: > On 8/5/09 2:38 AM, Philipp Hancke wrote: > >> It might be worthwile to describe some presence subscription related >> error flows in more detail - subscribe is probably the most important >> one. > I think that unavailable from the bare JID would work fine as an ack for > subscribe. It would be interesting to map out some of the error cases. I was just thinking about this topic some more -- I think that for the true error scenarios (bad hostname in the presence subscription request, server not found, remote connection failed, etc.), it would be helpful to define the appropriate conditions and strongly recommend inclusion of the 'id' attribute for tracking purposes. These are really just the regular old standard error cases, but perhaps it would be helpful to spell them out for people. Then perhaps recommend unavailable presence from the bare JID as an ack so that the user's server knows that the contact's server now has responsibility for the subscription request. As far as I can see, that would handle most of the current failure cases. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jCAACgkQNL8k5A2w/vzbBQCfZkL5qXEeGfrroFH7oH4juiUz hiYAoN+U1qMs3kfr7hcq5tJvoMMxFKDh =WI4v -----END PGP SIGNATURE----- From Kurt.Zeilenga@Isode.com Wed Aug 5 06:50:05 2009 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 CAC7228C588 for ; Wed, 5 Aug 2009 06:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] 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 EeJMW1F5kMjV for ; Wed, 5 Aug 2009 06:50:05 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3D7253A6858 for ; Wed, 5 Aug 2009 06:48:56 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Aug 2009 14:48:56 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> From: Kurt Zeilenga To: Joe Hildebrand In-Reply-To: Date: Wed, 5 Aug 2009 06:48:53 -0700 References: X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Wed, 05 Aug 2009 13:50:05 -0000 On Aug 4, 2009, at 10:27 PM, Joe Hildebrand wrote: > On 8/4/09 4:02 PM, "Kurt Zeilenga" wrote: >> I'm more curious about namespaced attributes on children of the >> stanza, such as . > > We've always told people not to muck with the pre-defined stuff. > Perhaps > instead of saying stanza, we could say anything in jabber:client (or > jabber:component:accept of course). I'm torn a bit on this. I would like for the entity originally adding a child element to a stanza to be able to include extension attributes, properly name spaced, and hope that these would get passed through. In particular, I would to be able to add 'xml:id' attributes to child elements so that one could unambiguously identify elements in a stanza. (Because 'xml:id' uniqueness requirements, values might have to be more unique than unique within stanza. But I digress.) As has been noted, such attributes simply might not get passed. If so, then their useful is limited. However, is the extension that making use of such an attribute has a strong value, I suspect that would drive servers passing of at least that extensions attributes (even if the extension is not otherwise implemented). But I guess I would be okay with: "Extension attributes on stanza and non-extension child elements SHOULD be avoided for interoperability reasons." as this leaves the door open enough... -- Kurt From zarevucky.jiri@gmail.com Wed Aug 5 08:35:10 2009 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 240703A6C09 for ; Wed, 5 Aug 2009 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 Zd63NGlPuGDL for ; Wed, 5 Aug 2009 08:35:09 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1BDD03A693D for ; Wed, 5 Aug 2009 08:34:53 -0700 (PDT) Received: by bwz19 with SMTP id 19so161935bwz.37 for ; Wed, 05 Aug 2009 08:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=apm38Q4GtB40fGRpc8RDt8HbRDyDsUfIPfhflab2fiY=; b=FjmVRyIWg3ya61CTkaDLpLRBLNO5Qng5lFvfg0TDQKasJQjusSG8jH7Pg0iUrN6IME ymEfPri393Tu80vjnqkOzx2kUQeI5mqboqf9x4/v3XaLSRPY4FjMr3N+6zeVBsfExZDQ tIYd1aHleudN9fsTCYZefvB4Kci1t2KXQczm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=asOPlkFy9CDd6QFO7QhJla3p3NWvT2S1fD9ov4CbaEzWAQuEVCERKEUss/f83PVgyh iy/QIIWT5TanV8QhdmVYULsTyE9+0yTZiFyIHzZqmf8tgRuKbwvzBLTAMj56DU6X7eSo /Aucgr2//7sAX5+ujxNFTjZ+MboxGZRr3DkZQ= Received: by 10.103.168.12 with SMTP id v12mr5027740muo.16.1249486371476; Wed, 05 Aug 2009 08:32:51 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id e8sm25828850muf.36.2009.08.05.08.32.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 08:32:51 -0700 (PDT) Message-ID: <4A79A621.8070902@gmail.com> Date: Wed, 05 Aug 2009 17:32:49 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: xmpp@ietf.org References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> In-Reply-To: <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 15:35:10 -0000 On 08/05/2009 04:32 AM, Kurt Zeilenga wrote: > > > The definition of 'id' (9.1.3 of 3920bis) says: >> The 'id' attribute MAY be used by a sending entity for internal >> tracking of stanzas that it sends and receives (especially for >> tracking the request-response interaction inherent in the semantics >> of IQ stanzas). The value of the 'id' attribute MAY be unique >> globally, within a domain, or within a stream. The semantics of IQ >> stanzas impose additional restrictions; see Section 9.2.3. > > I think the first MAY is trying to do two things at once. It's trying > to 1) state that providing the 'id' attribute is at the sending > entity's option and 2) what the purpose of the attribute is. I think > it would be better to separate these. For instance: > > The purpose of the id attribute is to allow a response stanza to > be associated with a particular request stanza. > Except where specified differently, the entity originating a > request stanza MAY include an 'id' attribute. > I find the text clear enough as it is, but it may need some clarification. Anyway, your proposed text is not entirely correct, as the stanza being responded to may not necessarily be a request (for example when some error occurs). Following text would me more appropriate I think: The 'id' attribute is used to associate a response stanza (for example an IQ result or an error) with the stanza that caused it (for example IQ request or a sent message). The value of the 'id' attribute MUST be such that the sending entity is always able to associate the cause and response correctly. This usually means uniqueness to some extent for the sending entity, but it is fully opaque to the receiving entity. Unless otherwise specified, inclusion of the 'id' attribute is OPTIONAL. > I note that 'sending entity' is a term that not well defined. > Elsewhere in the document, 'sending entity' simply refers to the > entity which sent a particular stanza (and 'receiving entity' simply > refers to an entity which received a particular stanza). > If we use this meaning here, this sentence could be read that the > entity sending a response stanza has the option not to include the id > attribute provided in the request stanza as it is 'sending' the > response stanza. Even if we took the 'sending entity' to refer to a > party sending a request, that would imply that a server sending a > request on behalf of a client MAY not include the id attribute the > client provided when it originated the request. > > I would think for this feature to "work" in general, an entity > responding to a request containing an id attribute MUST provide an id > attribute with the same value as the request contained in the > request. This requirement does not appear to be well specified. I think it was there somewhere. For IQ stanzas at least, it's implied. I can't find any mention in the section about stanza errors, though. > As far as unique, no uniqueness property should be assumed by the > receiving entity. The receiving property should treat id values as > opaque value. > While the originating entity of a request could ensure values they > generate have some uniqueness property, the only actual requirement is > that originating entities SHOULD produce values in a manner which > ensures that outstanding requests (requests they've sent but have yet > to receive a response for) do not share the same value. For instance, > an implementation which serializes it requests (never has more than > one outstanding) could use the same id value for all requests it > generates. > -- Kurt > From justin@affinix.com Wed Aug 5 09:08:31 2009 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 CA6FA28C575 for ; Wed, 5 Aug 2009 09:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVyf1w6kUbmW for ; Wed, 5 Aug 2009 09:08:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 1BA8828C0D8 for ; Wed, 5 Aug 2009 09:08:31 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id C8823147AF for ; Wed, 5 Aug 2009 09:08:28 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Wed, 5 Aug 2009 09:08:30 -0700 User-Agent: KMail/1.9.10 References: <4A5F7F77.2000608@mail.symlynx.com> <4A79450C.1040401@mail.symlynx.com> <4A797587.1080409@stpeter.im> In-Reply-To: <4A797587.1080409@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908050908.30566.justin@affinix.com> Subject: Re: [xmpp] presence subscriptions + desync 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: Wed, 05 Aug 2009 16:08:31 -0000 On Wednesday 05 August 2009 05:05:27 Peter Saint-Andre wrote: > On 8/5/09 2:38 AM, Philipp Hancke wrote: > > Peter Saint-Andre wrote: > >> Therefore I conclude that the only direction we need to heal is the > >> outbound subscription from user to contact. Here the user (or the user's > >> server) can simply poll once in a while to make sure that the subscribe > >> request went through and will be answered at some point. No, it's not > >> beautiful and elegant, but it works with existing infrastructure without > >> presence leaks or new values of the presence 'type' attribute. > > > > so does my proposal :-) > > I think that unavailable from the bare JID would work fine as an ack for > subscribe. It would be interesting to map out some of the error cases. I don't know if we should address this here. A lost subscription request is unfortunate, but then so is a lost message and we don't do anything about that. Let XEP-198 take care of it. -Justin From Kurt.Zeilenga@Isode.com Wed Aug 5 11:31:33 2009 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 8337C28C4AE for ; Wed, 5 Aug 2009 11:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Nq+sV99Ghf7D for ; Wed, 5 Aug 2009 11:31:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9F2553A6803 for ; Wed, 5 Aug 2009 11:31:32 -0700 (PDT) Received: from [172.16.2.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Aug 2009 19:31:34 +0100 Message-Id: <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> From: Kurt Zeilenga To: =?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?= In-Reply-To: <4A79A621.8070902@gmail.com> Date: Wed, 5 Aug 2009 11:31:31 -0700 References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 18:31:33 -0000 On Aug 5, 2009, at 8:32 AM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: > The 'id' attribute is used to associate a response stanza (for =20 > example an IQ result or an error) with the stanza that caused it =20 > (for example IQ request or a sent message). > The value of the 'id' attribute MUST be such that the sending =20 > entity is always able to associate the cause and response correctly. I think the term 'sending entity' is ambiguous here. It could refer =20 to any entity sending a stanza with an id attribute, including an entity originating a request, forwarding a request, =20 responding to a request, or forwarding a response to a request. I think you mean 'originating entity', the identity which originated =20 the request stanza and its id attribute. I assume that the MUST applies to the originator, not to any other =20 entity. But this leaves no mandate to forward or return id attributes. > This usually means uniqueness to some extent for the sending =20 > entity, but it is fully opaque to the receiving entity. Again, I think you mean 'originating entity' instead of 'sending =20 entity'. As the sending entity is in the end a receiving entity (of the response), it would be to replace "the =20 receiving entity" with "other entities". > Unless otherwise specified, inclusion of the 'id' attribute is =20 > OPTIONAL. This is bad as it implies that any of those other entities can drop =20 the 'id' attribute the originating provided. -- Kurt= From zarevucky.jiri@gmail.com Wed Aug 5 13:01:37 2009 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 3E8DA3A6C1F for ; Wed, 5 Aug 2009 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 PEo6F1W+B63G for ; Wed, 5 Aug 2009 13:01:36 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 2FE193A68EF for ; Wed, 5 Aug 2009 13:01:36 -0700 (PDT) Received: by fxm26 with SMTP id 26so333404fxm.42 for ; Wed, 05 Aug 2009 13:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0fG3UY8RVsqcXNOyrzL+2yebKwWyxsUF0C8Y6hGNAiQ=; b=amEnhJzeGB8LewcIsYZ7g8lGKwv+Z1r9T6vBkPEvOKpgroWSYM1LpdGXzAPEba6rOI 3Ss8VHcwVq7Jas4oCXKkXsvNW9IoNniIWJZO0HVRM7kiPxMRU4KDfobuhPy0KvAidJIz Tq4v63UTupzp4PBaExMGV1UQhNIaLxKEPN8fs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O02G9rNlVnajVByrx7O1G8GbbC5PEGMA3lXxOcyWbh3wCAz47tERkFwzNYKo/ZmGBb 62LRqGWCA5ollSWNZbYvVwlV5jGwQKnT6g7sAbqiDgwNS0yYAF/Ld4PCNyb4yrq+m/YD 4jANGI4GDDBE9tqd08hWPqPvjVz1x3XjoZeD0= Received: by 10.102.219.9 with SMTP id r9mr2784083mug.31.1249502496477; Wed, 05 Aug 2009 13:01:36 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id w5sm55760252mue.4.2009.08.05.13.01.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 13:01:36 -0700 (PDT) Message-ID: <4A79E51E.2050803@gmail.com> Date: Wed, 05 Aug 2009 22:01:34 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Kurt Zeilenga References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> In-Reply-To: <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 20:01:37 -0000 On 08/05/2009 08:31 PM, Kurt Zeilenga wrote: > > On Aug 5, 2009, at 8:32 AM, Jiří Zárevúcky wrote: > >> The 'id' attribute is used to associate a response stanza (for >> example an IQ result or an error) with the stanza that caused it (for >> example IQ request or a sent message). >> The value of the 'id' attribute MUST be such that the sending >> entity is always able to associate the cause and response correctly. > > I think the term 'sending entity' is ambiguous here. It could refer > to any entity sending a stanza with an id attribute, > including an entity originating a request, forwarding a request, > responding to a request, or forwarding a response to a request. > > I think you mean 'originating entity', the identity which originated > the request stanza and its id attribute. > > I assume that the MUST applies to the originator, not to any other > entity. But this leaves no mandate to forward > or return id attributes. > Yes, I mean "originating entity". >> This usually means uniqueness to some extent for the sending >> entity, but it is fully opaque to the receiving entity. > > Again, I think you mean 'originating entity' instead of 'sending > entity'. As the sending entity is in the end > a receiving entity (of the response), it would be to replace "the > receiving entity" with "other entities". > Yes, "other entities" would be better there as well. >> Unless otherwise specified, inclusion of the 'id' attribute is >> OPTIONAL. > > This is bad as it implies that any of those other entities can drop > the 'id' attribute the originating provided. > Any intermediate entity is not the originator. They just pass the stanza along and so this rule is irrelevant for them, as it applies to entity *creating* the stanza. You are actually suggesting that the server can strip any optional parts from *your* stanzas, which is clearly nonsense. > -- Kurt From Kurt.Zeilenga@Isode.com Wed Aug 5 14:20:58 2009 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 06FE23A6AD5 for ; Wed, 5 Aug 2009 14:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 3dZVYig2qeOX for ; Wed, 5 Aug 2009 14:20:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0E8263A6782 for ; Wed, 5 Aug 2009 14:20:57 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Aug 2009 22:20:59 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: From: Kurt Zeilenga To: =?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?= In-Reply-To: <4A79E51E.2050803@gmail.com> Date: Wed, 5 Aug 2009 14:20:56 -0700 References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> <4A79E51E.2050803@gmail.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 21:20:58 -0000 On Aug 5, 2009, at 1:01 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: > >>> Unless otherwise specified, inclusion of the 'id' attribute is =20 >>> OPTIONAL. >> >> This is bad as it implies that any of those other entities can drop =20= >> the 'id' attribute the originating provided. >> > > Any intermediate entity is not the originator. Yes, but this statement doesn't say it's the originators option. It =20 says it's anyone option (because it fails to say who has the option). > They just pass the stanza along and so this rule is irrelevant for =20 > them, as it applies to entity *creating* the stanza. I understand this is what's intended. I just think the text doesn't =20 clearly state what's is intended. > You are actually suggesting that the server can strip any optional =20 > parts from *your* stanzas, which is clearly nonsense. I'm suggesting that the OPTIONAL statement could be taken as license =20 to strip the 'id'. -- Kurt= From zarevucky.jiri@gmail.com Wed Aug 5 15:46:20 2009 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 D76193A6994 for ; Wed, 5 Aug 2009 15:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 QdBSQGn0DnoS for ; Wed, 5 Aug 2009 15:46:20 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id DEE953A68B5 for ; Wed, 5 Aug 2009 15:46:19 -0700 (PDT) Received: by bwz2 with SMTP id 2so372443bwz.43 for ; Wed, 05 Aug 2009 15:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lQOmgs2wkz6ESY6PgSQotocR/BNpwK4GQ4iugoutfCM=; b=wojB/50HKuWsktTlIt5t48K6MeDgcPLaKp5GJlflpCQxEkWxamkN9xW+gOLGCw66Zo 9Guojrg765ywQg5oSOTi7cW3iKkjdSpgH5IIhK+0nXQ1vDJfU618F6RIF+wldiuMoKmL VPTAMFp4nLym1HPC4rzVVMWEeWnIxJdFqN4As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Rkf5RKVDs/Wx5S59Ln44BkS7H71X5Z9abfwj26aNT1KppPWnNEsrDgFzmMpVL2gBzR SyFiMl9HP7YvfqHxFm4tACudZWzZbGtevdOOg5LxAyfw/2V8ss6MAMPTtysQuxyeuBvO Lv9923DC8pXIEh8JO6+aKYsF8B46oETrIT/6w= Received: by 10.103.252.17 with SMTP id e17mr278247mus.129.1249512379199; Wed, 05 Aug 2009 15:46:19 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id j2sm47356562mue.50.2009.08.05.15.46.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 15:46:18 -0700 (PDT) Message-ID: <4A7A0BB9.70305@gmail.com> Date: Thu, 06 Aug 2009 00:46:17 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Kurt Zeilenga References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> <4A79E51E.2050803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 22:46:20 -0000 On 08/05/2009 11:20 PM, Kurt Zeilenga wrote: > > On Aug 5, 2009, at 1:01 PM, Jiří Zárevúcky wrote: >> >>>> Unless otherwise specified, inclusion of the 'id' attribute is >>>> OPTIONAL. >>> >>> This is bad as it implies that any of those other entities can drop >>> the 'id' attribute the originating provided. >>> >> >> Any intermediate entity is not the originator. > > Yes, but this statement doesn't say it's the originators option. It > says it's anyone option (because it fails to > say who has the option). > >> They just pass the stanza along and so this rule is irrelevant for >> them, as it applies to entity *creating* the stanza. > > I understand this is what's intended. I just think the text doesn't > clearly state what's is intended. > >> You are actually suggesting that the server can strip any optional >> parts from *your* stanzas, which is clearly nonsense. > > I'm suggesting that the OPTIONAL statement could be taken as license > to strip the 'id'. > > -- Kurt The attribute is optional to include, not optional to pass along. Server must pass everything, unless it has some specific rules for processing some specific data. Otherwise it would mean you could freely tamper with anything else, let's say remove 'from' or 'to' attributes, just because they're optional. That would be just absurd. From Kurt.Zeilenga@Isode.com Wed Aug 5 16:21:47 2009 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 6C8713A699C for ; Wed, 5 Aug 2009 16:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 Kr1h5gXMnq6m for ; Wed, 5 Aug 2009 16:21:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5AC433A67DD for ; Wed, 5 Aug 2009 16:21:46 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Aug 2009 00:21:48 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: From: Kurt Zeilenga To: =?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?= In-Reply-To: <4A7A0BB9.70305@gmail.com> Date: Wed, 5 Aug 2009 16:21:45 -0700 References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> <4A79E51E.2050803@gmail.com> <4A7A0BB9.70305@gmail.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 23:21:47 -0000 On Aug 5, 2009, at 3:46 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: > On 08/05/2009 11:20 PM, Kurt Zeilenga wrote: >> >> On Aug 5, 2009, at 1:01 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: >>> >>>>> Unless otherwise specified, inclusion of the 'id' attribute is =20= >>>>> OPTIONAL. >>>> >>>> This is bad as it implies that any of those other entities can =20 >>>> drop the 'id' attribute the originating provided. >>>> >>> >>> Any intermediate entity is not the originator. >> >> Yes, but this statement doesn't say it's the originators option. =20 >> It says it's anyone option (because it fails to >> say who has the option). >> >>> They just pass the stanza along and so this rule is irrelevant for =20= >>> them, as it applies to entity *creating* the stanza. >> >> I understand this is what's intended. I just think the text =20 >> doesn't clearly state what's is intended. >> >>> You are actually suggesting that the server can strip any optional =20= >>> parts from *your* stanzas, which is clearly nonsense. >> >> I'm suggesting that the OPTIONAL statement could be taken as =20 >> license to strip the 'id'. >> >> -- Kurt > > The attribute is optional to include, The statements: "inclusion of the 'id' attribute is optional" and "inclusion of the 'id' attribute is OPTIONAL" do not say the same thing. "optional" means attribute is not required by schema. "OPTIONAL" means that implementation of inclusion of the attribute is =20= elective. As you note that certain entities MUST implement inclusion of the =20 attribute, such as when creating a stanza in forwarding/responding to =20= a request with such an attribute, implementation of the inclusion of =20 the attribute needs to MANDATORY. From zarevucky.jiri@gmail.com Wed Aug 5 16:40:18 2009 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 359193A67D4 for ; Wed, 5 Aug 2009 16:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 jdh1QEnAt1Re for ; Wed, 5 Aug 2009 16:40:16 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 0E2243A71A5 for ; Wed, 5 Aug 2009 16:39:50 -0700 (PDT) Received: by fxm26 with SMTP id 26so435679fxm.42 for ; Wed, 05 Aug 2009 16:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fYRkrr2ttHOcYMr428dlZkWMthrjZmShd3lSSWj+ttg=; b=HChGz/QhhHco0qlfx57ExLgRfQy8gEV1IM9WQ8+FirinhSOGDIylLsvFyli2JrlrfX /ioHOe2AHm8IIfjEJs4sd7/jmfvkKHPHRi05r7ZnabOunb2lbM5r1DfNnkpPSofgmapq MqiMMQ1BFl1ch73pjQqZAikIeQ8PW6Y6cHmig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=drH0HEkidbJh0JAq+/XBbs+OUVkS1wTjUgovBTIr4L9IfrMZZIqM7z7oYwy2YB6nvC dq+SkWvq3Fq7xC9dUjSbUrO8fKf0x6ee+eZ1oxIiYXFFjWr/aLu18k7e/mzRLs9mFXwe S/C8RgylPwC+ufxpuegLbMB4X4Q+D11Y8u6gM= Received: by 10.103.192.2 with SMTP id u2mr2090150mup.21.1249515591262; Wed, 05 Aug 2009 16:39:51 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id g1sm53371654muf.46.2009.08.05.16.39.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 16:39:50 -0700 (PDT) Message-ID: <4A7A1845.6070709@gmail.com> Date: Thu, 06 Aug 2009 01:39:49 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Kurt Zeilenga References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> <4A79E51E.2050803@gmail.com> <4A7A0BB9.70305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Wed, 05 Aug 2009 23:40:19 -0000 On 08/06/2009 01:21 AM, Kurt Zeilenga wrote: > > On Aug 5, 2009, at 3:46 PM, Jiří Zárevúcky wrote: > >> On 08/05/2009 11:20 PM, Kurt Zeilenga wrote: >>> >>> On Aug 5, 2009, at 1:01 PM, Jiří Zárevúcky wrote: >>>> >>>>>> Unless otherwise specified, inclusion of the 'id' attribute is >>>>>> OPTIONAL. >>>>> >>>>> This is bad as it implies that any of those other entities can >>>>> drop the 'id' attribute the originating provided. >>>>> >>>> >>>> Any intermediate entity is not the originator. >>> >>> Yes, but this statement doesn't say it's the originators option. It >>> says it's anyone option (because it fails to >>> say who has the option). >>> >>>> They just pass the stanza along and so this rule is irrelevant for >>>> them, as it applies to entity *creating* the stanza. >>> >>> I understand this is what's intended. I just think the text doesn't >>> clearly state what's is intended. >>> >>>> You are actually suggesting that the server can strip any optional >>>> parts from *your* stanzas, which is clearly nonsense. >>> >>> I'm suggesting that the OPTIONAL statement could be taken as license >>> to strip the 'id'. >>> >>> -- Kurt >> >> The attribute is optional to include, > > The statements: > "inclusion of the 'id' attribute is optional" > and > "inclusion of the 'id' attribute is OPTIONAL" > do not say the same thing. > > "optional" means attribute is not required by schema. > "OPTIONAL" means that implementation of inclusion of the attribute is > elective. > > As you note that certain entities MUST implement inclusion of the > attribute, such as when creating a stanza in forwarding/responding to > a request with such an attribute, implementation of the inclusion of > the attribute needs to MANDATORY. > You're very wrong. These words mean level of requirement for given statement, but they don't have anything to do with implementation by themselves. I don't know how you got the idea. Many specifications wouldn't even make sense that way. See the RFC in question (http://www.ietf.org/rfc/rfc2119.txt). To mean what you think it means, it would need to say "support for 'id' attribute is OPTIONAL", which it doesn't. From Kurt.Zeilenga@Isode.com Wed Aug 5 19:25:07 2009 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 91B353A69CB for ; Wed, 5 Aug 2009 19:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 2Xv3TciAAu47 for ; Wed, 5 Aug 2009 19:25:06 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0BF303A6BB7 for ; Wed, 5 Aug 2009 19:24:08 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Aug 2009 03:24:09 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <24A172B9-F53A-4D8E-8961-0E5F6D9E02D0@Isode.com> From: Kurt Zeilenga To: =?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?= In-Reply-To: <4A7A1845.6070709@gmail.com> Date: Wed, 5 Aug 2009 19:24:06 -0700 References: <2BD0827F-6713-42FD-81E1-FEAE01B331DF@Isode.com> <6169292A-2784-40C2-ABA0-A63ADEB85070@Isode.com> <4A79A621.8070902@gmail.com> <5B5C9AED-62A2-4F17-B427-0501E2460E55@Isode.com> <4A79E51E.2050803@gmail.com> <4A7A0BB9.70305@gmail.com> <4A7A1845.6070709@gmail.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] definition of common attribute '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: Thu, 06 Aug 2009 02:25:07 -0000 On Aug 5, 2009, at 4:39 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: > On 08/06/2009 01:21 AM, Kurt Zeilenga wrote: >> >> On Aug 5, 2009, at 3:46 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky wrote: >> >>> On 08/05/2009 11:20 PM, Kurt Zeilenga wrote: >>>> >>>> On Aug 5, 2009, at 1:01 PM, Ji=C5=99=C3=AD Z=C3=A1rev=C3=BAcky = wrote: >>>>> >>>>>>> Unless otherwise specified, inclusion of the 'id' attribute is =20= >>>>>>> OPTIONAL. >>>>>> >>>>>> This is bad as it implies that any of those other entities can =20= >>>>>> drop the 'id' attribute the originating provided. >>>>>> >>>>> >>>>> Any intermediate entity is not the originator. >>>> >>>> Yes, but this statement doesn't say it's the originators option. =20= >>>> It says it's anyone option (because it fails to >>>> say who has the option). >>>> >>>>> They just pass the stanza along and so this rule is irrelevant =20 >>>>> for them, as it applies to entity *creating* the stanza. >>>> >>>> I understand this is what's intended. I just think the text =20 >>>> doesn't clearly state what's is intended. >>>> >>>>> You are actually suggesting that the server can strip any =20 >>>>> optional parts from *your* stanzas, which is clearly nonsense. >>>> >>>> I'm suggesting that the OPTIONAL statement could be taken as =20 >>>> license to strip the 'id'. >>>> >>>> -- Kurt >>> >>> The attribute is optional to include, >> >> The statements: >> "inclusion of the 'id' attribute is optional" >> and >> "inclusion of the 'id' attribute is OPTIONAL" >> do not say the same thing. >> >> "optional" means attribute is not required by schema. >> "OPTIONAL" means that implementation of inclusion of the attribute =20= >> is elective. >> >> As you note that certain entities MUST implement inclusion of the =20 >> attribute, such as when creating a stanza in forwarding/responding =20= >> to a request with such an attribute, implementation of the =20 >> inclusion of the attribute needs to MANDATORY. >> > > You're very wrong. These words mean level of requirement for given =20 > statement, but they don't have anything to do with implementation by =20= > themselves. I don't know how you got the idea. Many specifications =20 > wouldn't even make sense that way. See the RFC in question = (http://www.ietf.org/rfc/rfc2119.txt=20 > ). Paraphrasing RFC 2119: One vendor (in their implementation) may choose support inclusion =20= of the attribute (in stanzas they send) while another vendor (in their =20= implementation) may choose not to support inclusion of the attribute =20 (in stanzas they send). However, a you noted, for the tracking to work, all XMPP =20 implementations MUST support inclusion of the attribute. In =20 particular, they MUST support inclusion when constructs a stanza when =20= forwarding a request, responding to a request, or forwarding a =20 response, support inclusion in that stanza the identifier they =20 received. What's OPTIONAL, is that in originating a request stanza =20 (using the term here to refer to any stanza which requests an action, =20= including delivery of a message or presence update), the originator of =20= the request stanza MAY provide an id attribute. Note: I use the terms request and response to refer to paired stanzas, =20= such as iq request/response, or message/message-error pair, etc., even =20= though only the second of the pair is not always produced. As RFC 2119 should be used sparingly, I would only use them to express =20= the mandate that XMPP entities constructing a stanza in response to a =20= stanza or in forwarding a stanza SHALL, if the received stanza =20 included an id attribute, include an id attribute with the same value =20= in the stanza they send. As to the option of originator, I actually suggest we don't use MAY or =20= OPTIONAL. Instead, I would use "the originator of the request stanza =20= can provide an id attribute" (or the like) and I would strongly =20 encourage them to do so with every stanza. The reason why is that =20 this promotes proper handling of errors. As stanzas are =20 only responded to when an error occurs, any client which send multiple =20= stanza ought to be placing id's on them so that able to =20 take appropriate action on return of an error. An implementation =20 which chooses not to send ids on stanzas they originate is =20 effectively saying they are ignore errors. Ignoring errors can be =20 quite harmful to the other entities and the Internet, hence one might =20= even argue implementations SHOULD provide id attributes in requests =20 they originate. -- Kurt From Kurt.Zeilenga@Isode.com Thu Aug 6 13:35:05 2009 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 9D30D3A6850 for ; Thu, 6 Aug 2009 13:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz28X6tRzYZz for ; Thu, 6 Aug 2009 13:35:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E644B3A691F for ; Thu, 6 Aug 2009 13:34:43 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 6 Aug 2009 21:33:37 +0100 Message-Id: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> From: Kurt Zeilenga To: XMPP Working Group Date: Thu, 6 Aug 2009 13:33:35 -0700 X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: [xmpp] 9.1.3 replacement text suggestion: 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, 06 Aug 2009 20:35:05 -0000 A another attempt at 9.1.3 replacement text: The 'id' attribute purpose is to allow an entity sending a original stanza to identify the stanza, if any, received in response to that stanza. For instance, it can be used to associate an error stanza with the stanza that caused the error. While the attribute is optional attribute of the element (from a schema perspective), it appear in stanza is at time mandatory in the protocol, at other times its absence is mandatory in the protocol, and otherwise elective. When an entity is sending a stanza in response to a received stanza or is forwarding a received stanza, the entity MUST NOT provide an 'id' attribute if the received stanza did not have an 'id' attribute, otherwise it SHALL provide an 'id' attribute with same value as the 'id' of the received stanza had. In other cases, unless otherwise required (such as in requests), providing a 'id' attribute is elective. Though not required, it is strongly encouraged that entities provide 'id' attributes they can identity stanzas sent in response to those stanzas, such as error stanzas. From Kurt.Zeilenga@Isode.com Thu Aug 6 13:40:16 2009 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 0448E3A6E6F for ; Thu, 6 Aug 2009 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf4shI9mJlJa for ; Thu, 6 Aug 2009 13:40:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0E5E528C18D for ; Thu, 6 Aug 2009 13:40:04 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Aug 2009 21:40:04 +0100 Message-Id: From: Kurt Zeilenga To: Kurt Zeilenga In-Reply-To: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> Date: Thu, 6 Aug 2009 13:40:01 -0700 References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 06 Aug 2009 20:40:16 -0000 Correcting a couple of typos (sorry) and other wordsmithing: The 'id' attribute purpose is to allow an entity sending an original stanza to identify the stanza, if any, received in response to that stanza. For instance, it can be used to associate an error stanza with the stanza that caused the error. While the attribute is optional attribute of the stanza (from a schema/syntax perspective), its appearance in stanza is at time mandatory, at other times its absence is mandatory, and otherwise elective. When an entity is sending a stanza in response to a received stanza or is forwarding a received stanza, the entity MUST NOT provide an 'id' attribute if the received stanza did not have an 'id' attribute, otherwise it SHALL provide an 'id' attribute with same value as the 'id' of the received stanza had. In other cases, unless otherwise required (such as in requests), providing a 'id' attribute is elective. Though not required, it is strongly encouraged that entities provide 'id' attributes they can identity stanzas sent in response to those stanzas, such as error stanzas. From zarevucky.jiri@gmail.com Thu Aug 6 13:46:17 2009 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 7D90328C13A for ; Thu, 6 Aug 2009 13:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 yz90yg+D1MKl for ; Thu, 6 Aug 2009 13:46:16 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 6FD1728C10F for ; Thu, 6 Aug 2009 13:46:16 -0700 (PDT) Received: by bwz25 with SMTP id 25so1167482bwz.11 for ; Thu, 06 Aug 2009 13:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=67dUXKPZ0iy6pWquU12/a1hEkDdpxlp5sFEwjgkDdxk=; b=pevW8CupzEQkxgpVH0/1v8AFUc2MySRsooq+fMWqVrQFzPB609Vg7vMSF51+7Bfl6h 14erps9LOiOScx1i1X59Kfmt0NFcU95E2WZU2fw+rE8A8SYgo/OItfKfe+uxlMxlCIAe VAcQf9juAR+VGiEMKzKI5okXqiyGh4ASrT6a0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ex5iJYqNnBugcP2qMkoLFK8I/w51ja075d/7qvNsuzf/HrlRng+9C6bOmitX38TB5Z 5nMtRY0yDA+UWOfttPbMCPfIk+T/Ckpgoo70rLHQh2gkCgGY4vt561sreIlW8cNvDRP2 qN6J40xn2vGgmKTuIy0H2k4Iw98ncXBUVGIF0= Received: by 10.103.193.10 with SMTP id v10mr123991mup.126.1249591576014; Thu, 06 Aug 2009 13:46:16 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.92.43]) by mx.google.com with ESMTPS id i5sm1789730mue.25.2009.08.06.13.46.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Aug 2009 13:46:15 -0700 (PDT) Message-ID: <4A7B4115.4090400@gmail.com> Date: Thu, 06 Aug 2009 22:46:13 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Kurt Zeilenga References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> In-Reply-To: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 06 Aug 2009 20:46:17 -0000 On 08/06/2009 10:33 PM, Kurt Zeilenga wrote: > A another attempt at 9.1.3 replacement text: > The 'id' attribute purpose is to allow an entity sending a original > stanza to identify the stanza, if any, received in response to that > stanza. For instance, it can be used to associate an error stanza > with the stanza that caused the error. While the attribute is > optional attribute of the element (from a schema perspective), it > appear in stanza is at time mandatory in the protocol, at other times > its absence is mandatory in the protocol, and otherwise elective. > When an entity is sending a stanza in response to a received stanza or > is forwarding a received stanza, the entity MUST NOT provide an 'id' > attribute if the received stanza did not have an 'id' attribute, > otherwise it SHALL provide an 'id' attribute with same value as the > 'id' of the received stanza had. > In other cases, unless otherwise required (such as in requests), > providing a 'id' attribute is elective. Though not required, it is > strongly encouraged that entities provide 'id' attributes they can > identity stanzas sent in response to those stanzas, such as error > stanzas. > For one, you are over-complicating it. Look at the original text (which is just fine IMHO, by the way) and your replacement. At times, I have hard time understanding what you mean. Wording is difficult to comprehend ("sending a original stanza to identify the stanza, " .. the original stanza? you have to read ahead to understand.) It's typical high-school example of using so complicated compound sentences it's actually almost unreadable. It might be just me of course, but I find it worse by orders of magnitude compared to the original text. Sorry for such harsh critics, but I really think this is not the way to go. Jiří From Kurt.Zeilenga@Isode.com Thu Aug 6 14:01:43 2009 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 8D4563A6CE4 for ; Thu, 6 Aug 2009 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 OoJZTJyJwnEM for ; Thu, 6 Aug 2009 14:01:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 77E9D3A6E09 for ; Thu, 6 Aug 2009 14:01:42 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Thu, 6 Aug 2009 22:01:44 +0100 Message-Id: <2630D87B-11E5-4514-808A-9C92F46D74F3@Isode.com> From: Kurt Zeilenga To: XMPP Working Group In-Reply-To: Date: Thu, 6 Aug 2009 14:01:37 -0700 References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 06 Aug 2009 21:01:43 -0000 On Aug 6, 2009, at 1:40 PM, Kurt Zeilenga wrote: > Correcting a couple of typos (sorry) and other wordsmithing: > > The 'id' attribute purpose is to allow an entity sending an original > stanza to identify the stanza, if any, received in response to that > stanza. For instance, it can be used to associate an error stanza > with the stanza that caused the error. While the attribute is > optional attribute of the stanza (from a schema/syntax perspective), > its appearance in stanza is at time mandatory, at other times its > absence is mandatory, and otherwise elective. > > When an entity is sending a stanza in response to a received stanza > or is forwarding a received stanza, the entity MUST NOT provide an > 'id' attribute if the received stanza did not have an 'id' > attribute, otherwise it SHALL provide an 'id' attribute with same > value as the 'id' of the received stanza had. > > In other cases, unless otherwise required (such as in > requests), providing a 'id' attribute is elective. Though not > required, it is strongly encouraged that entities provide 'id' > attributes they can identity stanzas sent in response to those > stanzas, such as error stanzas. The following paragraph would cover the only uniqueness requirement. > The entity originating the value of the 'id' attribute need only > ensure the value is sufficiently unique to allow it to properly > relate its stanzas. -- Kurt From Kurt.Zeilenga@Isode.com Thu Aug 6 15:56:41 2009 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 7A7AB3A69F0 for ; Thu, 6 Aug 2009 15:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, 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 aA75tcNlQ-h6 for ; Thu, 6 Aug 2009 15:56:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6B3CD3A68D2 for ; Thu, 6 Aug 2009 15:56:40 -0700 (PDT) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Aug 2009 23:56:42 +0100 Message-Id: From: Kurt Zeilenga To: =?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?= In-Reply-To: <4A7B4115.4090400@gmail.com> Date: Thu, 6 Aug 2009 15:56:39 -0700 References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A7B4115.4090400@gmail.com> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 06 Aug 2009 22:56:41 -0000 Going back over the original text: --- Sentence 1 --- One could regard the sentence: The 'id' attribute MAY be used by a sending entity for internal tracking of stanzas that it sends and receives (especially for tracking the request-response interaction inherent in the semantics of IQ stanzas). simply a statement of the purpose of the 'id' attribute. That consider the meaning of the sentence if MAY is replaced with may, which simply expresses a possibility. (Whether it really a possibility depends on what others do with it, which this section is quite silent on.) Anyways, here is a restatement of the purpose of the attribute: The 'id' attribute purpose is to allow an entity, at its option, to relate stanzas it receives in response (or in error) to stanzas it originated. Now, it's been noted that the MAY was intended to express either or both: The 'id' attribute is optional component of the stanza (which presence or absence may be required by the protocol in certain cases). The inclusion of the 'id' attribute by the sending entity is OPTIONAL. The latter is quite problematic as 'sending entity' here could be taken as any entity sending any stanza, including stanza which are sent in response (or in error) to another stanza, or in forwarding a stanza. The former is only problematic when one says "The 'id' attribute is optional" without clarification that the protocol mandates its presence/absence in certain cases (so that tracking can work). --- Sentence 2 --- The value of the 'id' attribute MAY be unique globally, within a domain, or within a stream. This sentence appears to be make a broad statement concerning the uniqueness of 'id' values. Simply put, nothing in the protocol requires or ensures values be unique in any way. What I assume this statement was intended to express was that values of the 'id' attribute should be created by the originating entity in a manner which allows for proper tracking. This could simply be stated: The value of the 'id' attribute is any string which allows the originator of the stanza to adequately relate stanzas. --- Sentence 3 --- The semantics of IQ stanzas impose additional restrictions; see Section 9.2.3. No problem. --- Unstated --- Section 9.1.3 doesn't state any general requirements that 'id' values be preserved in responding to stanzas. Section 9.1.3 doesn't state any general requirements that 'id' values be preserved in forwarding. There seems to be no discussion of the stanza's 'id' attribute outside of 9.1.3 and 9.2.3. From stpeter@stpeter.im Mon Aug 10 12:46:40 2009 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 E5A7A28C2C7 for ; Mon, 10 Aug 2009 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-1JmY-MTeRI for ; Mon, 10 Aug 2009 12:46:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 041DE3A67B6 for ; Mon, 10 Aug 2009 12:46:21 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3C404007B for ; Mon, 10 Aug 2009 13:46:22 -0600 (MDT) Message-ID: <4A80790D.3010605@stpeter.im> Date: Mon, 10 Aug 2009 13:46:21 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] SASLprep vs. nodeprep 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, 10 Aug 2009 19:46:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The SCRAM I-D (draft-ietf-sasl-scram-04) says the following: Before sending the username to the server, the client MUST prepare the username using the "SASLPrep" profile [RFC4013] of the "stringprep" algorithm [RFC3454]. This might be perceived as contradicting 3920bis, where we say that the localpart of a JabberID "MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing". However, I think that nodeprep is more strict than SASLprep, so perhaps we are OK. In any case, I think that the text in the SCRAM I-D needs to say that the SASLprep profile can be applied without failing, not that the username must be prepared using SASLprep. Thoughts? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAeQ0ACgkQNL8k5A2w/vwNMQCfSVJ93b2klCDUlgCK80iQSzvj EAkAoObvKtbAo5MJ+G4EDUkSFqeck6E8 =rbG2 -----END PGP SIGNATURE----- From dave@cridland.net Mon Aug 10 13:08:04 2009 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 3C70228C2A1 for ; Mon, 10 Aug 2009 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwO+awKohvzq for ; Mon, 10 Aug 2009 13:08:03 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 0B73628C29C for ; Mon, 10 Aug 2009 13:08:03 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 10 Aug 2009 21:08:04 +0100 X-SMTP-Protocol-Errors: NORDNS References: <4A80790D.3010605@stpeter.im> In-Reply-To: <4A80790D.3010605@stpeter.im> MIME-Version: 1.0 Message-Id: <8048.1249934881.543311@puncture> Date: Mon, 10 Aug 2009 21:08:01 +0100 From: Dave Cridland To: Peter Saint-Andre , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] SASLprep vs. nodeprep 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, 10 Aug 2009 20:08:04 -0000 On Mon Aug 10 20:46:21 2009, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The SCRAM I-D (draft-ietf-sasl-scram-04) says the following: > > Before sending the username to the server, the client MUST > prepare the username using the "SASLPrep" profile [RFC4013] > of the "stringprep" algorithm [RFC3454]. > > This might be perceived as contradicting 3920bis, where we say that > the > localpart of a JabberID "MUST be formatted such that the Nodeprep > profile of [STRINGPREP] can be applied without failing". However, I > think that nodeprep is more strict than SASLprep, so perhaps we are > OK. > > I don't think there's a contradiction: A jid node MUST pass Nodeprep. A simple username MUST be the jid node. A simple username used in SCRAM MUST have SASLprep applied before transmission. None of the above have a conflict I can see - it's merely that a jid's node might be have more restrictions than previously we've considered. It would be worthwhile mentioning this case in particular, and in general, that implementations may have further restrictions on the form of a node identifier, in section 3.3. > In any case, I think that the text in the SCRAM I-D needs to say > that > the SASLprep profile can be applied without failing, not that the > username must be prepared using SASLprep. > > I'll answer this one on the SASL list. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Mon Aug 10 13:27:05 2009 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 8DF3B28C28F for ; Mon, 10 Aug 2009 13:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGV6MfCoaaIR for ; Mon, 10 Aug 2009 13:27:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A200928C28D for ; Mon, 10 Aug 2009 13:27:04 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4332E4007B; Mon, 10 Aug 2009 14:27:08 -0600 (MDT) Message-ID: <4A80829B.4050703@stpeter.im> Date: Mon, 10 Aug 2009 14:27:07 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dave Cridland References: <4A80790D.3010605@stpeter.im> <8048.1249934881.543311@puncture> In-Reply-To: <8048.1249934881.543311@puncture> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] SASLprep vs. nodeprep 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, 10 Aug 2009 20:27:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 2:08 PM, Dave Cridland wrote: > On Mon Aug 10 20:46:21 2009, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> The SCRAM I-D (draft-ietf-sasl-scram-04) says the following: >> >> Before sending the username to the server, the client MUST >> prepare the username using the "SASLPrep" profile [RFC4013] >> of the "stringprep" algorithm [RFC3454]. >> >> This might be perceived as contradicting 3920bis, where we say that the >> localpart of a JabberID "MUST be formatted such that the Nodeprep >> profile of [STRINGPREP] can be applied without failing". However, I >> think that nodeprep is more strict than SASLprep, so perhaps we are OK. >> >> > I don't think there's a contradiction: I don't think there's a contradiction, either, which is why I said that people might perceive a contradiction. > A jid node MUST pass Nodeprep. > > A simple username MUST be the jid node. > > A simple username used in SCRAM MUST have SASLprep applied before > transmission. > > None of the above have a conflict I can see - it's merely that a jid's > node might be have more restrictions than previously we've considered. > It would be worthwhile mentioning this case in particular, and in > general, that implementations may have further restrictions on the form > of a node identifier, in section 3.3. Agreed. But does this mean that an entity must apply two different stringprep profiles, in series (nodeprep then SASLprep)? Isn't that expensive? >> In any case, I think that the text in the SCRAM I-D needs to say that >> the SASLprep profile can be applied without failing, not that the >> username must be prepared using SASLprep. >> >> > I'll answer this one on the SASL list. OK. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAgpsACgkQNL8k5A2w/vxoUQCg2WuzOQEvmmSeXi2OgIBjMetH wVkAoKNfLo7kGuCn64rcOCpiSjeBUose =6lDY -----END PGP SIGNATURE----- From dave@cridland.net Mon Aug 10 13:58:23 2009 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 00E093A6A7F for ; Mon, 10 Aug 2009 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD0qMFCYpweA for ; Mon, 10 Aug 2009 13:58:22 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id CCACD3A68E9 for ; Mon, 10 Aug 2009 13:58:21 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 10 Aug 2009 21:58:23 +0100 X-SMTP-Protocol-Errors: NORDNS References: <4A80790D.3010605@stpeter.im> <8048.1249934881.543311@puncture> <4A80829B.4050703@stpeter.im> In-Reply-To: <4A80829B.4050703@stpeter.im> MIME-Version: 1.0 Message-Id: <8048.1249937902.369962@puncture> Date: Mon, 10 Aug 2009 21:58:22 +0100 From: Dave Cridland To: Peter Saint-Andre , XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] SASLprep vs. nodeprep 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, 10 Aug 2009 20:58:23 -0000 On Mon Aug 10 21:27:07 2009, Peter Saint-Andre wrote: > But does this mean that an entity must apply two different > stringprep > profiles, in series (nodeprep then SASLprep)? Isn't that expensive? I think it's a drop in the ocean compared to the rest of the session-setup experience - TLS and the remainder of SCRAM are much bigger fruit, if higher up. Moreover, trying to solve this neccesitates a "special" SCRAM implementation for XMPP which elides the SASLprep, potentially. I'm certainly not against your proposed changes to SCRAM, but I don't think it's worth worrying over. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Mon Aug 10 14:04:43 2009 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 8E11E28C10B for ; Mon, 10 Aug 2009 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdQvXnaDpdNy for ; Mon, 10 Aug 2009 14:04:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AAC733A6F0B for ; Mon, 10 Aug 2009 14:03:48 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E8ABA4007B; Mon, 10 Aug 2009 15:03:51 -0600 (MDT) Message-ID: <4A808B36.1020302@stpeter.im> Date: Mon, 10 Aug 2009 15:03:50 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Kurt Zeilenga References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> In-Reply-To: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 21:04:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/6/09 2:33 PM, Kurt Zeilenga wrote: > A another attempt at 9.1.3 replacement text: It's not fully clear to me what you find unclear in the original text, but I suggest the following clarifications... *** 9.1.3. id The 'id' attribute is used by the entity that generates a stanza ("the originating entity") to track any response or error stanza that it might receive in relation to the generated stanza from another entity (such as an intermediate server or the intended recipient). The value of the 'id' attribute can be unique globally, within a domain, or within a stream. For and stanzas, it is RECOMMENDED for the originating entity to include an 'id' attribute; for stanzas, it is REQUIRED. If the generated stanza is or then it is RECOMMENDED for the entity that returns a response or error stanza to include an 'id' attribute if the generated stanza included one; for stanzas, it is REQUIRED. The value of the 'id' attribute in a response or error stanza MUST match that of the generated stanza. Note: The semantics of IQ stanzas impose additional restrictions; see Section 9.2.3. *** Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAizYACgkQNL8k5A2w/vwHUwCgmssY405mnQGDCjWX6T0Q7o5T tksAoKjsGBVZTZFDs9S8RjybPpR9bQh+ =oG05 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 10 14:09:19 2009 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 CFE153A6BCF for ; Mon, 10 Aug 2009 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27rmB2EfjtVR for ; Mon, 10 Aug 2009 14:09:19 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5577A28C10B for ; Mon, 10 Aug 2009 14:08:52 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E88E4007B; Mon, 10 Aug 2009 15:08:56 -0600 (MDT) Message-ID: <4A808C67.9000505@stpeter.im> Date: Mon, 10 Aug 2009 15:08:55 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dave Cridland References: <4A80790D.3010605@stpeter.im> <8048.1249934881.543311@puncture> <4A80829B.4050703@stpeter.im> <8048.1249937902.369962@puncture> In-Reply-To: <8048.1249937902.369962@puncture> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] SASLprep vs. nodeprep 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, 10 Aug 2009 21:09:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 2:58 PM, Dave Cridland wrote: > On Mon Aug 10 21:27:07 2009, Peter Saint-Andre wrote: >> But does this mean that an entity must apply two different stringprep >> profiles, in series (nodeprep then SASLprep)? Isn't that expensive? > > I think it's a drop in the ocean compared to the rest of the > session-setup experience - TLS and the remainder of SCRAM are much > bigger fruit, if higher up. True. > Moreover, trying to solve this neccesitates a "special" SCRAM > implementation for XMPP which elides the SASLprep, potentially. That would be bad. I'm not convinced that would be necessary, but if so I would prefer to avoid any XMPP-specific SCRAM libraries (or calls within those libraries). > I'm certainly not against your proposed changes to SCRAM, but I don't > think it's worth worrying over. Point taken. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAjGcACgkQNL8k5A2w/vwUkwCgwK3Pfz9ZbLqGrFZtETWRlkxG qkEAoMH/3ycCHnvQTzOjgAiGnV+ridLE =O25t -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 10 14:36:04 2009 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 82C3D3A6F2B for ; Mon, 10 Aug 2009 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8v3Ot+OejbJ for ; Mon, 10 Aug 2009 14:36:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9E7543A6D6F for ; Mon, 10 Aug 2009 14:36:03 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 36F2E4007B; Mon, 10 Aug 2009 15:36:07 -0600 (MDT) Message-ID: <4A8092C6.1070803@stpeter.im> Date: Mon, 10 Aug 2009 15:36:06 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Justin Karneges References: <4A5F7F77.2000608@mail.symlynx.com> <4A79450C.1040401@mail.symlynx.com> <4A797587.1080409@stpeter.im> <200908050908.30566.justin@affinix.com> In-Reply-To: <200908050908.30566.justin@affinix.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] presence subscriptions + desync 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, 10 Aug 2009 21:36:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/5/09 10:08 AM, Justin Karneges wrote: > On Wednesday 05 August 2009 05:05:27 Peter Saint-Andre wrote: >> On 8/5/09 2:38 AM, Philipp Hancke wrote: >>> Peter Saint-Andre wrote: >>>> Therefore I conclude that the only direction we need to heal is the >>>> outbound subscription from user to contact. Here the user (or the user's >>>> server) can simply poll once in a while to make sure that the subscribe >>>> request went through and will be answered at some point. No, it's not >>>> beautiful and elegant, but it works with existing infrastructure without >>>> presence leaks or new values of the presence 'type' attribute. >>> so does my proposal :-) >> I think that unavailable from the bare JID would work fine as an ack for >> subscribe. It would be interesting to map out some of the error cases. > > I don't know if we should address this here. A lost subscription request is > unfortunate, but then so is a lost message and we don't do anything about > that. Let XEP-198 take care of it. Good point. /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAksYACgkQNL8k5A2w/vxdkgCg8I/tetTck5/tIVdSeYIiYl38 5UEAoO9Dj8HL7EqfrZ8awM9wi/zBUqxc =2QaC -----END PGP SIGNATURE----- From Kurt.Zeilenga@Isode.com Mon Aug 10 15:40:10 2009 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 DF30E3A6CE8 for ; Mon, 10 Aug 2009 15:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] 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 dF6OE3cWb-8U for ; Mon, 10 Aug 2009 15:40:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5BD6B3A6E2D for ; Mon, 10 Aug 2009 15:40:06 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Aug 2009 23:40:08 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> From: Kurt Zeilenga To: Peter Saint-Andre In-Reply-To: <4A808B36.1020302@stpeter.im> Date: Mon, 10 Aug 2009 15:40:05 -0700 References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 22:40:11 -0000 On Aug 10, 2009, at 2:03 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/6/09 2:33 PM, Kurt Zeilenga wrote: >> A another attempt at 9.1.3 replacement text: > > It's not fully clear to me what you find unclear in the original text, > but I suggest the following clarifications... Your suggestion addresses many, but not all, of my concerns. > > *** > > 9.1.3. id > > The 'id' attribute is used by the entity that generates a stanza > ("the originating entity") to track any response or error stanza > that > it might receive in relation to the generated stanza from another > entity (such as an intermediate server or the intended recipient). > > The value of the 'id' attribute can be unique globally, within a > domain, or within a stream. I am slightly concerned that this statement could be taken as meaning the receiving entity can make assumptions about the uniqueness of values it receives, such as two requests originated by the entity in the same stream will have unique id values. I would rather this be worded more clearly as guidance to the originating entity on how to produce suitable values. However, for now, I'm let this lie. > > For and stanzas, it is RECOMMENDED for the > originating entity to include an 'id' attribute; for stanzas, > it is REQUIRED. > > If the generated stanza is or then it is > RECOMMENDED for the entity that returns a response or error stanza > to > include an 'id' attribute if the generated stanza included one; for > stanzas, it is REQUIRED. The value of the 'id' attribute in a > response or error stanza MUST match that of the generated stanza. Why would it be allowed for an entity not to include an 'id' attribute when the "generated stanza" included an 'id' attribute? That is, shouldn't the RECOMMENDED be a REQUIRED. Also, this text does not state a requirement that an entity sending a stanza in forwarding a stanza they receive is in anyway obligated to forward the id value, if any, they received. I don't see where this is elsewhere required by the specification. > > Note: The semantics of IQ stanzas impose additional restrictions; > see > Section 9.2.3. > > *** > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqAizYACgkQNL8k5A2w/vwHUwCgmssY405mnQGDCjWX6T0Q7o5T > tksAoKjsGBVZTZFDs9S8RjybPpR9bQh+ > =oG05 > -----END PGP SIGNATURE----- > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From stpeter@stpeter.im Mon Aug 10 16:11:08 2009 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 2C2AE3A69D5 for ; Mon, 10 Aug 2009 16:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE12HNHtCDeJ for ; Mon, 10 Aug 2009 16:11:07 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EA4C43A6B26 for ; Mon, 10 Aug 2009 16:11:06 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C16A4007B; Mon, 10 Aug 2009 17:11:10 -0600 (MDT) Message-ID: <4A80A90C.1000201@stpeter.im> Date: Mon, 10 Aug 2009 17:11:08 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Kurt Zeilenga References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> In-Reply-To: <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 23:11:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 4:40 PM, Kurt Zeilenga wrote: > > On Aug 10, 2009, at 2:03 PM, Peter Saint-Andre wrote: > > On 8/6/09 2:33 PM, Kurt Zeilenga wrote: >>>> A another attempt at 9.1.3 replacement text: > > It's not fully clear to me what you find unclear in the original text, > but I suggest the following clarifications... > >> Your suggestion addresses many, but not all, of my concerns. > > > *** > > 9.1.3. id > > The 'id' attribute is used by the entity that generates a stanza > ("the originating entity") to track any response or error stanza that > it might receive in relation to the generated stanza from another > entity (such as an intermediate server or the intended recipient). > > The value of the 'id' attribute can be unique globally, within a > domain, or within a stream. > >> I am slightly concerned that this statement could be taken as meaning >> the receiving entity can make assumptions about the uniqueness of values >> it receives, such as two requests originated by the entity in the >> same stream will have unique id values. I would rather this be worded >> more clearly as guidance to the originating entity on how to produce >> suitable values. However, for now, I'm let this lie. It seems sensible to provide clear guidance to the originating entity. I suggest the following: It is up to the originating entity whether the value of the 'id' attribute will be unique only within its current stream (session) or unique globally. > For and stanzas, it is RECOMMENDED for the > originating entity to include an 'id' attribute; for stanzas, > it is REQUIRED. > > If the generated stanza is or then it is > RECOMMENDED for the entity that returns a response or error stanza to > include an 'id' attribute if the generated stanza included one; for > stanzas, it is REQUIRED. The value of the 'id' attribute in a > response or error stanza MUST match that of the generated stanza. > >> Why would it be allowed for an entity not to include an 'id' attribute >> when the "generated stanza" included an 'id' attribute? That is, >> shouldn't the RECOMMENDED be a REQUIRED. Because that's the way it's always been. In large measure, both and stanzas are fire-and-forget communications that the originating entity does not necessarily want or need to track in the way that IQs are tracked. Changing that is part of a larger discussion, I think. >> Also, this text does not state a requirement that an entity sending a >> stanza in forwarding a stanza they receive is in anyway obligated to >> forward the id value, if any, they received. I don't see where this is >> elsewhere required by the specification. I don't understand your concept of forwarding. Do you mean routing or delivering? These concepts are mostly clear in the specs: roughly, to "route" means for a local server to take a stanza it has received and send it along to a remote server, and to "deliver" means for a server to take a stanza it has received and send it along to the intended recipient. (This leaves components out of the description, but I think that is OK for 3920bis and 3921bis.) As far as your point goes, nothing in the specification says that an intermediate entity (server) MUST leave any common attributes ('from', 'to', 'type', 'id', 'xml:lang') or defined elements (say, presence or message ) untouched. This has always been assumed, because it's the whole point of the server to route or deliver stanzas! If we need to spell this out, then I think it belongs somewhere other than in the definition of the 'id' attribute. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAqQwACgkQNL8k5A2w/vwHaACg5NrdawkjbpH2sn1SU1Jtv6bc Z58An2ZVScDotkx5EE4QbJLT0KiQFwF8 =JP81 -----END PGP SIGNATURE----- From metajack@gmail.com Mon Aug 10 16:17:49 2009 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 D750C3A6E5A for ; Mon, 10 Aug 2009 16:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 iqxkDRMtMdOZ for ; Mon, 10 Aug 2009 16:17:49 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id F2D113A6AFA for ; Mon, 10 Aug 2009 16:17:48 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so963084eye.31 for ; Mon, 10 Aug 2009 16:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=k8DWxk66LOszykWqNB4ki9Ex6VndDtUP+ekrl40fIsY=; b=ZEPFmtpHLJWvvNMBJcimQbx6zGpwqNrze7R834+QApVlwlW5bKab4oyVZFCPP1oi38 lo9oEcp8q4WrssLWfwcuPN0vN7Kb1NrndjIkpSj3CXjlYhvC6LEkr1F6m+7lKKQ0g+9z 69SUxSN2n3H9ZZyNZRrGECSb3ptkCY5KezRfw= 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:content-type :content-transfer-encoding; b=NloT23xWB61/aEq4GnpUQy7n84BINs3LEfw/WunFilaUhER6iXtiVzX1gq/czFG7u4 BskyxYtCe3HZqhou+H46fSKRz8eOmo4XLAI27973t+rgsdUSc/GxpAaqM3eXBqFY6zts NQf/b31DtNSBzfDZcce0NfK97JRXMstyGJuDU= MIME-Version: 1.0 Sender: metajack@gmail.com Received: by 10.216.85.213 with SMTP id u63mr1153879wee.15.1249946269289; Mon, 10 Aug 2009 16:17:49 -0700 (PDT) In-Reply-To: <4A80A90C.1000201@stpeter.im> References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> Date: Mon, 10 Aug 2009 17:17:49 -0600 X-Google-Sender-Auth: f89d129e42fea6ea Message-ID: <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> From: Jack Moffitt To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 23:17:49 -0000 >>> Why would it be allowed for an entity not to include an 'id' attribute >>> when the "generated stanza" included an 'id' attribute? =A0That is, >>> shouldn't the RECOMMENDED be a REQUIRED. > > Because that's the way it's always been. In large measure, both > and stanzas are fire-and-forget communications > that the originating entity does not necessarily want or need to track > in the way that IQs are tracked. Changing that is part of a larger > discussion, I think. I think Kurt meant (and if so, I agree), that if hte originating stanza contained an id attribute, the response (if any) should be required to contain the id attribute as well regardless of whether it is an IQ or not. jack. From stpeter@stpeter.im Mon Aug 10 16:20:18 2009 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 6C4473A6AFA for ; Mon, 10 Aug 2009 16:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bnB8+-UKW4z for ; Mon, 10 Aug 2009 16:20:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 931823A6F08 for ; Mon, 10 Aug 2009 16:20:17 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 57ADA4007B; Mon, 10 Aug 2009 17:20:21 -0600 (MDT) Message-ID: <4A80AB34.3080002@stpeter.im> Date: Mon, 10 Aug 2009 17:20:20 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jack Moffitt References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> In-Reply-To: <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 23:20:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 5:17 PM, Jack Moffitt wrote: >>>> Why would it be allowed for an entity not to include an 'id' attribute >>>> when the "generated stanza" included an 'id' attribute? That is, >>>> shouldn't the RECOMMENDED be a REQUIRED. >> Because that's the way it's always been. In large measure, both >> and stanzas are fire-and-forget communications >> that the originating entity does not necessarily want or need to track >> in the way that IQs are tracked. Changing that is part of a larger >> discussion, I think. > > I think Kurt meant (and if so, I agree), that if hte originating > stanza contained an id attribute, the response (if any) should be > required to contain the id attribute as well regardless of whether it > is an IQ or not. I agree that's what Kurt meant. I am not sure if that's what we want the spec to say. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAqzQACgkQNL8k5A2w/vx4bgCg0F0WXp4/yBphFAlo4tX4cOjs fA0An1uFZvMEG0BwoPe2OVw5mFjqQjre =oyxc -----END PGP SIGNATURE----- From florian.zeitz@gmx.de Mon Aug 10 16:44:21 2009 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 A59253A6BA5 for ; Mon, 10 Aug 2009 16:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm3AdnGYTkuc for ; Mon, 10 Aug 2009 16:44:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7A5833A6957 for ; Mon, 10 Aug 2009 16:44:20 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2009 23:44:22 -0000 Received: from xdsl-81-173-224-203.netcologne.de (EHLO [192.168.0.21]) [81.173.224.203] by mail.gmx.net (mp017) with SMTP; 11 Aug 2009 01:44:22 +0200 X-Authenticated: #30932406 X-Provags-ID: V01U2FsdGVkX19cxgEjLVdcLpPaJpjWrsIpWGjD++CKJ5Sgzbt0yl 1TkPzPTWyDnDZT Message-ID: <4A80B0D5.4010209@gmx.de> Date: Tue, 11 Aug 2009 01:44:21 +0200 From: Florian Zeitz User-Agent: Thunderbird 2.0.0.22 (X11/20090804) MIME-Version: 1.0 To: XMPP Working Group References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> <4A80AB34.3080002@stpeter.im> In-Reply-To: <4A80AB34.3080002@stpeter.im> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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, 10 Aug 2009 23:44:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Saint-Andre wrote: > On 8/10/09 5:17 PM, Jack Moffitt wrote: >>>>> Why would it be allowed for an entity not to include an 'id' attribute >>>>> when the "generated stanza" included an 'id' attribute? That is, >>>>> shouldn't the RECOMMENDED be a REQUIRED. >>> Because that's the way it's always been. In large measure, both >>> and stanzas are fire-and-forget communications >>> that the originating entity does not necessarily want or need to track >>> in the way that IQs are tracked. Changing that is part of a larger >>> discussion, I think. >> I think Kurt meant (and if so, I agree), that if hte originating >> stanza contained an id attribute, the response (if any) should be >> required to contain the id attribute as well regardless of whether it >> is an IQ or not. > > I agree that's what Kurt meant. I am not sure if that's what we want the > spec to say. :) > > Peter > I personally think that is what it should say, too. While I understand that message and presence stanzas are generally fire and forget, I'd argue that at least if the response is an error (which the RFC suggests might happen) it is absolutely usless without an id. Basically I suspect that if a message/presence stanza causes a response it will be wiser to always have an id on that. Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqAsMYACgkQ0JXcdjR+9YSdBwCg2KASW+YQlXxe31ybMx4xFiUQ D/cAn0oUFnIHLTXrntpoZM46iWicpDKw =PpDT -----END PGP SIGNATURE----- From zarevucky.jiri@gmail.com Mon Aug 10 18:16:55 2009 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 C6FC63A6F53 for ; Mon, 10 Aug 2009 18:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 B9cBfra5fqdH for ; Mon, 10 Aug 2009 18:16:55 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id BECCD3A6F82 for ; Mon, 10 Aug 2009 18:16:54 -0700 (PDT) Received: by fxm26 with SMTP id 26so1362855fxm.42 for ; Mon, 10 Aug 2009 18:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=j3ifvl+kV4RmCZrPt/nRb3Qa/exFyKVMt9sEuglSHAE=; b=jdgMAubaQ8GFmu3scdM84NPjeTWKtRds14HlkTgG2gy+c2U0FFyRHYMh2SLKEyITJQ EdbU8jiuxzbYKOhyt0KtRSODNHsyZ0qoBm9sH93c1QxrVsxs3IpPMe7AseU86G3hvWe5 5BZxpY9LWIuKostSDapU4Tzy+RkRCVig1wDyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Ul8BASq4XDYUUEIyypYmanUrfxUU35t1J2bx0hrhYrONOaJlxxTlAHITMY/qfghV6+ cE716IOBQNkneorFtLYUBUxlKd0JrOd9GA0IBoregU5rdSPA0vfW7Nxz4tAk6onp77gi wbG6dS3TERf+JZxv5qis+RDf1yp7ukleiZzRw= Received: by 10.204.57.80 with SMTP id b16mr6614563bkh.85.1249953414846; Mon, 10 Aug 2009 18:16:54 -0700 (PDT) Received: from ?10.10.10.20? ([94.229.94.1]) by mx.google.com with ESMTPS id d13sm7531856fka.2.2009.08.10.18.16.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 18:16:54 -0700 (PDT) Message-ID: <4A80C684.10301@gmail.com> Date: Tue, 11 Aug 2009 03:16:52 +0200 From: =?UTF-8?B?SmnFmcOtIFrDoXJldsO6Y2t5?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: xmpp@ietf.org References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> <4A80AB34.3080002@stpeter.im> <4A80B0D5.4010209@gmx.de> In-Reply-To: <4A80B0D5.4010209@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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: Tue, 11 Aug 2009 01:16:55 -0000 On 08/11/2009 01:44 AM, Florian Zeitz wrote: > Peter Saint-Andre wrote: > >> On 8/10/09 5:17 PM, Jack Moffitt wrote: >> >>>>>> Why would it be allowed for an entity not to include an 'id' attribute >>>>>> when the "generated stanza" included an 'id' attribute? That is, >>>>>> shouldn't the RECOMMENDED be a REQUIRED. >>>>>> >>>> Because that's the way it's always been. In large measure, both >>>> and stanzas are fire-and-forget communications >>>> that the originating entity does not necessarily want or need to track >>>> in the way that IQs are tracked. Changing that is part of a larger >>>> discussion, I think. >>>> >>> I think Kurt meant (and if so, I agree), that if hte originating >>> stanza contained an id attribute, the response (if any) should be >>> required to contain the id attribute as well regardless of whether it >>> is an IQ or not. >>> >> I agree that's what Kurt meant. I am not sure if that's what we want the >> spec to say. :) >> >> Peter >> >> > I personally think that is what it should say, too. > While I understand that message and presence stanzas are generally fire > and forget, I'd argue that at least if the response is an error (which > the RFC suggests might happen) it is absolutely usless without an id. > Basically I suspect that if a message/presence stanza causes a response > it will be wiser to always have an id on that. > > Spec shouldn't require all stanzas to include the id attribute (the resource consumption overhead may be a bit too much for some devices IMO), but I think it's reasonable to require it's mirroring in errors when it's present. It's mostly just a matter of one simple operation, so I doubt it will hurt anyone to implement it. It may also be worthwhile to note that for errors mirroring 'id', it's completely needless to mirror the content. From stpeter@stpeter.im Mon Aug 10 19:41:26 2009 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 9F5323A687C for ; Mon, 10 Aug 2009 19:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] 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 2PN12f4ds0e7 for ; Mon, 10 Aug 2009 19:41:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1E5523A67EC for ; Mon, 10 Aug 2009 19:41:25 -0700 (PDT) Received: from squire.local (dsl-240-80.dynamic-dsl.frii.net [216.17.240.80]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 57A214007B; Mon, 10 Aug 2009 20:41:28 -0600 (MDT) Message-ID: <4A80DA58.5070402@stpeter.im> Date: Mon, 10 Aug 2009 20:41:28 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Florian Zeitz References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> <4A80AB34.3080002@stpeter.im> <4A80B0D5.4010209@gmx.de> In-Reply-To: <4A80B0D5.4010209@gmx.de> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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: Tue, 11 Aug 2009 02:41:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 5:44 PM, Florian Zeitz wrote: > Peter Saint-Andre wrote: >> On 8/10/09 5:17 PM, Jack Moffitt wrote: >>>>>> Why would it be allowed for an entity not to include an 'id' attribute >>>>>> when the "generated stanza" included an 'id' attribute? That is, >>>>>> shouldn't the RECOMMENDED be a REQUIRED. >>>> Because that's the way it's always been. In large measure, both >>>> and stanzas are fire-and-forget communications >>>> that the originating entity does not necessarily want or need to track >>>> in the way that IQs are tracked. Changing that is part of a larger >>>> discussion, I think. >>> I think Kurt meant (and if so, I agree), that if hte originating >>> stanza contained an id attribute, the response (if any) should be >>> required to contain the id attribute as well regardless of whether it >>> is an IQ or not. >> I agree that's what Kurt meant. I am not sure if that's what we want the >> spec to say. :) > >> Peter > > > I personally think that is what it should say, too. > While I understand that message and presence stanzas are generally fire > and forget, I'd argue that at least if the response is an error (which > the RFC suggests might happen) it is absolutely usless without an id. > Basically I suspect that if a message/presence stanza causes a response > it will be wiser to always have an id on that. I thought about this some more after I sent my last message, and I think you're right. It's a change from RFC 3920, but it seems appropriate. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqA2lgACgkQNL8k5A2w/vzy+ACfUF1JRvltYzFa65K1vuaaqKWy Ix4AmwR1byZeoQxpg7ABsR+vIRCtaZy8 =MpqM -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Aug 10 19:47:29 2009 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 DA8143A6A1D for ; Mon, 10 Aug 2009 19:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] 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 Bb1A95wxP0hN for ; Mon, 10 Aug 2009 19:47:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 00C3D3A68BF for ; Mon, 10 Aug 2009 19:47:29 -0700 (PDT) Received: from squire.local (dsl-240-80.dynamic-dsl.frii.net [216.17.240.80]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9EFAF4007B; Mon, 10 Aug 2009 20:47:32 -0600 (MDT) Message-ID: <4A80DBC3.8060606@stpeter.im> Date: Mon, 10 Aug 2009 20:47:31 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Florian Zeitz References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> <9b58f4550908101617n7622de6eg6240fcdd8c951239@mail.gmail.com> <4A80AB34.3080002@stpeter.im> <4A80B0D5.4010209@gmx.de> <4A80DA58.5070402@stpeter.im> In-Reply-To: <4A80DA58.5070402@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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: Tue, 11 Aug 2009 02:47:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/09 8:41 PM, Peter Saint-Andre wrote: > On 8/10/09 5:44 PM, Florian Zeitz wrote: >> Peter Saint-Andre wrote: >>> On 8/10/09 5:17 PM, Jack Moffitt wrote: >>>>>>> Why would it be allowed for an entity not to include an 'id' attribute >>>>>>> when the "generated stanza" included an 'id' attribute? That is, >>>>>>> shouldn't the RECOMMENDED be a REQUIRED. >>>>> Because that's the way it's always been. In large measure, both >>>>> and stanzas are fire-and-forget communications >>>>> that the originating entity does not necessarily want or need to track >>>>> in the way that IQs are tracked. Changing that is part of a larger >>>>> discussion, I think. >>>> I think Kurt meant (and if so, I agree), that if hte originating >>>> stanza contained an id attribute, the response (if any) should be >>>> required to contain the id attribute as well regardless of whether it >>>> is an IQ or not. >>> I agree that's what Kurt meant. I am not sure if that's what we want the >>> spec to say. :) >>> Peter > >> I personally think that is what it should say, too. >> While I understand that message and presence stanzas are generally fire >> and forget, I'd argue that at least if the response is an error (which >> the RFC suggests might happen) it is absolutely usless without an id. >> Basically I suspect that if a message/presence stanza causes a response >> it will be wiser to always have an id on that. > > I thought about this some more after I sent my last message, and I think > you're right. It's a change from RFC 3920, but it seems appropriate. In my working copy I now have this: If the generated stanza includes an 'id' attribute then it is REQUIRED for the response or error stanza to also include an 'id' attribute, where the value of the 'id' attribute MUST match that of the generated stanza. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqA28MACgkQNL8k5A2w/vyV3gCeJQIljZztd/Xhx3zQNTUjxGPc IVMAoIXTbAJlSJRxeDEAhVF88fyHAS2/ =KiWH -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Aug 11 01:31:44 2009 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 0FC9F3A6F98 for ; Tue, 11 Aug 2009 01:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] 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 Jp7md9byN1fU for ; Tue, 11 Aug 2009 01:31:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CA4623A6A95 for ; Tue, 11 Aug 2009 01:31:42 -0700 (PDT) Received: from [92.40.176.19] (92.40.176.19.sub.mbb.three.co.uk [92.40.176.19]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 11 Aug 2009 09:31:45 +0100 Message-ID: <4A812C69.1070107@isode.com> Date: Tue, 11 Aug 2009 09:31:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <8921BFB8-59D2-488E-9C54-109DD47CF34D@Isode.com> <4A808B36.1020302@stpeter.im> <1532507E-6A8E-4984-AFEE-286BCAE1ABAF@Isode.com> <4A80A90C.1000201@stpeter.im> In-Reply-To: <4A80A90C.1000201@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt Zeilenga , XMPP Working Group Subject: Re: [xmpp] 9.1.3 replacement text suggestion: 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: Tue, 11 Aug 2009 08:31:44 -0000 Peter Saint-Andre wrote: >On 8/10/09 4:40 PM, Kurt Zeilenga wrote: > > >>On Aug 10, 2009, at 2:03 PM, Peter Saint-Andre wrote: >> >> [...] >>*** >> >>9.1.3. id >> >> The 'id' attribute is used by the entity that generates a stanza >> ("the originating entity") to track any response or error stanza that >> it might receive in relation to the generated stanza from another >> entity (such as an intermediate server or the intended recipient). >> >> The value of the 'id' attribute can be unique globally, within a >> domain, or within a stream. >> >> >>>I am slightly concerned that this statement could be taken as meaning >>>the receiving entity can make assumptions about the uniqueness of values >>>it receives, such as two requests originated by the entity in the >>>same stream will have unique id values. I would rather this be worded >>>more clearly as guidance to the originating entity on how to produce >>>suitable values. However, for now, I'm let this lie. >>> >>> >It seems sensible to provide clear guidance to the originating entity. I >suggest the following: > > It is up to the originating entity whether the value of the 'id' > attribute will be unique only within its current stream (session) > or unique globally. > > This is better. From alexey.melnikov@isode.com Wed Aug 12 05:26:33 2009 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 BAEA93A6A6C for ; Wed, 12 Aug 2009 05:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] 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 p3-JvSfaK-JP for ; Wed, 12 Aug 2009 05:26:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D067E3A67D9 for ; Wed, 12 Aug 2009 05:26:29 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Aug 2009 13:24:54 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A82B492.4080107@isode.com> Date: Wed, 12 Aug 2009 13:24:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <4A80790D.3010605@stpeter.im> In-Reply-To: <4A80790D.3010605@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] SASLprep vs. nodeprep 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: Wed, 12 Aug 2009 12:26:33 -0000 Peter Saint-Andre wrote: >The SCRAM I-D (draft-ietf-sasl-scram-04) says the following: > > Before sending the username to the server, the client MUST > prepare the username using the "SASLPrep" profile [RFC4013] > of the "stringprep" algorithm [RFC3454]. > >This might be perceived as contradicting 3920bis, where we say that the >localpart of a JabberID "MUST be formatted such that the Nodeprep >profile of [STRINGPREP] can be applied without failing". However, I >think that nodeprep is more strict than SASLprep, so perhaps we are OK. > Peter, there is no contradiction here. Think of the SCRAM authentication mechanism (or any SASL authentication) as of a black box: SCRAM takes a simple username as input; once SCRAM authentication is successful, the protocol that invoked SCRAM authentication would get an identity, that needs to be converted to the format used by the protocol (JID in case of XMPP). This also means that if one enters a bare JID to be used as the SCRAM username, there is an implied conversion step from JID to SCRAM format. This just happens to be noop for bare JIDs. >In any case, I think that the text in the SCRAM I-D needs to say that >the SASLprep profile can be applied without failing, not that the >username must be prepared using SASLprep. > >Thoughts? > > From stpeter@stpeter.im Wed Aug 12 10:14:56 2009 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 F0C9B3A688F for ; Wed, 12 Aug 2009 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9wImW-kmK1y for ; Wed, 12 Aug 2009 10:14:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C3A313A6C79 for ; Wed, 12 Aug 2009 10:14:32 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E927F4007B; Wed, 12 Aug 2009 11:13:55 -0600 (MDT) Message-ID: <4A82F852.2060402@stpeter.im> Date: Wed, 12 Aug 2009 11:13:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexey Melnikov References: <4A80790D.3010605@stpeter.im> <4A82B492.4080107@isode.com> In-Reply-To: <4A82B492.4080107@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] SASLprep vs. nodeprep 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: Wed, 12 Aug 2009 17:14:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/12/09 6:24 AM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> The SCRAM I-D (draft-ietf-sasl-scram-04) says the following: >> >> Before sending the username to the server, the client MUST >> prepare the username using the "SASLPrep" profile [RFC4013] >> of the "stringprep" algorithm [RFC3454]. >> >> This might be perceived as contradicting 3920bis, where we say that the >> localpart of a JabberID "MUST be formatted such that the Nodeprep >> profile of [STRINGPREP] can be applied without failing". However, I >> think that nodeprep is more strict than SASLprep, so perhaps we are OK. >> > Peter, there is no contradiction here. Think of the SCRAM authentication > mechanism (or any SASL authentication) as of a black box: SCRAM takes a > simple username as input; once SCRAM authentication is successful, the > protocol that invoked SCRAM authentication would get an identity, that > needs to be converted to the format used by the protocol (JID in case of > XMPP). > This also means that if one enters a bare JID to be used as the SCRAM > username, there is an implied conversion step from JID to SCRAM format. > This just happens to be noop for bare JIDs. I think you are right, but I want to make sure this is clear in 3920bis so that developers are not confused about which stringprep profile to apply (and when). I'll work on some text about this. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqC+FIACgkQNL8k5A2w/vw7qgCfX6tbTghrCVMRGTn9xmNkfsGI gMkAoLfcbYbQGcPEp3tZ3NVORN9Ra7Wu =urTm -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Aug 12 11:26:56 2009 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 0AC8228C0E1 for ; Wed, 12 Aug 2009 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] 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 RqjGaKbwqJPt for ; Wed, 12 Aug 2009 11:26:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 318C13A6B27 for ; Wed, 12 Aug 2009 11:26:55 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 752854007B; Wed, 12 Aug 2009 12:25:55 -0600 (MDT) Message-ID: <4A830932.6080608@stpeter.im> Date: Wed, 12 Aug 2009 12:25:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Kurt Zeilenga References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> In-Reply-To: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Wed, 12 Aug 2009 18:26:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/5/09 7:48 AM, Kurt Zeilenga wrote: > > On Aug 4, 2009, at 10:27 PM, Joe Hildebrand wrote: > >> On 8/4/09 4:02 PM, "Kurt Zeilenga" wrote: >>> I'm more curious about namespaced attributes on children of the >>> stanza, such as . >> >> We've always told people not to muck with the pre-defined stuff. Perhaps > >> instead of saying stanza, we could say anything in jabber:client (or >> jabber:component:accept of course). > > I'm torn a bit on this. I would like for the entity originally adding a > child element to a stanza to be able to include extension attributes, > properly name spaced, and hope that these would get passed through. In > particular, I would to be able to add 'xml:id' attributes to child > elements so that one could unambiguously identify elements in a stanza. > (Because 'xml:id' uniqueness requirements, values might have to be more > unique than unique within stanza. But I digress.) > > As has been noted, such attributes simply might not get passed. If so, > then their useful is limited. However, is the extension that making use > of such an attribute has a strong value, I suspect that would drive > servers passing of at least that extensions attributes (even if the > extension is not otherwise implemented). > > But I guess I would be okay with: > "Extension attributes on stanza and non-extension child elements > SHOULD be avoided for interoperability reasons." Putting together everything discussed in this thread, I suggest the following text: Stanzas themselves (i.e., the , , and elements qualified by the "jabber:client" or "jabber:server" namespace) and child elements of stanzas MAY also include attributes that are qualified by XML namespaces other than "jabber:client", "jabber:server", or "http://etherx.jabber.org/streams". For the sake of backward compatibility and maximum interoperability, an entity that generates a stanza SHOULD NOT include such attributes in the stanza itself or in child elements of the stanza that are qualified by the "jabber:client" and "jabber:server" namespaces (e.g., the message element). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqDCTIACgkQNL8k5A2w/vxXTQCeMyRSxWmdX0pJlVPZPKnlU6WD wMgAn3mjZEPTy0yXtnLx41fSe/z18nwL =L/eW -----END PGP SIGNATURE----- From metajack@gmail.com Wed Aug 12 13:52:02 2009 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 3C2D528C144 for ; Wed, 12 Aug 2009 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6] 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 KkDJW168+koD for ; Wed, 12 Aug 2009 13:51:58 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id E33C03A6948 for ; Wed, 12 Aug 2009 13:51:57 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so42435eye.31 for ; Wed, 12 Aug 2009 13:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=aT71M8RyjHqrmBd25TMDrn5hPw2cutrb5mlcr7KZsZI=; b=D+xvf+Ob77smiGv6PUS4htuBJU4CaZD/DlA9U1eVeoy/ZRHg0hEO9MI84Y1Y6cGVlb nPHAQj9r0f+i63x/Zpvkm9OBX8ZQeyuRrVtsyll87whzv3PR+18QB/CyHRJtP5f60Bzj YOrZNnlrv/l/BLVPVHRStODQn1+bzoB7YUbiw= 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:content-type :content-transfer-encoding; b=TVdJ9mTUTzM4txAk9FjiREgLgdZHfiF2XI1x6ic/IouAHxd9E23wB842+SxqBsnl3Z PGL27spbjQuTB0dkCKWDPcvUbKRTiFIsupW3939iyP8hvbBRgL/T4g5H89kdITgbyp5i zOv6kNbcmZ8RfMfRgr2R6MfpbLmL7HRJgp7a0= MIME-Version: 1.0 Sender: metajack@gmail.com Received: by 10.216.17.213 with SMTP id j63mr79786wej.140.1250110275530; Wed, 12 Aug 2009 13:51:15 -0700 (PDT) In-Reply-To: <4A830932.6080608@stpeter.im> References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> Date: Wed, 12 Aug 2009 14:51:13 -0600 X-Google-Sender-Auth: b3dfa335e3eb56bc Message-ID: <9b58f4550908121351g255ea362x95b40e1b2e3509ba@mail.gmail.com> From: Jack Moffitt To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Wed, 12 Aug 2009 20:52:02 -0000 > =A0 Stanzas themselves (i.e., the , , and > =A0 elements qualified by the "jabber:client" or "jabber:server" > =A0 namespace) and child elements of stanzas MAY also include attributes > =A0 that are qualified by XML namespaces other than "jabber:client", > =A0 "jabber:server", or "http://etherx.jabber.org/streams". =A0For the sa= ke > =A0 of backward compatibility and maximum interoperability, an entity > =A0 that generates a stanza SHOULD NOT include such attributes in the > =A0 stanza itself or in child elements of the stanza that are qualified > =A0 by the "jabber:client" and "jabber:server" namespaces (e.g., the > =A0 message element). Don't several XEPs use attributes currently? I was happy to say that extended attributes on the top level element MAY be removed/ignored by the server, but I fail to see what is backward-incompatible with including them on child elements? XEP 206 uses extended attributes at the top level (although it's extending httpbind elements). There are all kinds of good reasons to use attributes. xml:lang is one that is used in lots of examples on /message/body elements. It seems to me that implementations which do not recognize these elements will simply keep forwarding them along and ignore them, just like they do with unknown children. jack. From stpeter@stpeter.im Wed Aug 12 14:13:15 2009 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 6BEFF28C148 for ; Wed, 12 Aug 2009 14:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6] 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 1QrVPV+UldMa for ; Wed, 12 Aug 2009 14:13:14 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 87FC228C117 for ; Wed, 12 Aug 2009 14:13:14 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B0B4A4007B; Wed, 12 Aug 2009 15:11:46 -0600 (MDT) Message-ID: <4A833011.5050004@stpeter.im> Date: Wed, 12 Aug 2009 15:11:45 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jack Moffitt References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <9b58f4550908121351g255ea362x95b40e1b2e3509ba@mail.gmail.com> In-Reply-To: <9b58f4550908121351g255ea362x95b40e1b2e3509ba@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Wed, 12 Aug 2009 21:13:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/12/09 2:51 PM, Jack Moffitt wrote: >> Stanzas themselves (i.e., the , , and >> elements qualified by the "jabber:client" or "jabber:server" >> namespace) and child elements of stanzas MAY also include attributes >> that are qualified by XML namespaces other than "jabber:client", >> "jabber:server", or "http://etherx.jabber.org/streams". For the sake >> of backward compatibility and maximum interoperability, an entity >> that generates a stanza SHOULD NOT include such attributes in the >> stanza itself or in child elements of the stanza that are qualified >> by the "jabber:client" and "jabber:server" namespaces (e.g., the >> message element). > > Don't several XEPs use attributes currently? Mostly SOAP (XEP-0072), I'd guess. > I was happy to say that > extended attributes on the top level element MAY be removed/ignored by > the server, but I fail to see what is backward-incompatible with > including them on child elements? Perhaps some testing is in order? > XEP 206 uses extended attributes at the top level (although it's > extending httpbind elements). Right, that's different. > There are all kinds of good reasons to use attributes. xml:lang is > one that is used in lots of examples on /message/body elements. Well, xml:lang is grandfathered in by RFC 3920. Probably it makes to exempt all xml:foo attributes, since XMPP is supposed to be an XML application... > It seems to me that implementations which do not recognize these > elements will simply keep forwarding them along and ignore them, just > like they do with unknown children. That strikes me as a reasonable expectation. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqDMBEACgkQNL8k5A2w/vy/2wCfYcuwZ3h2CZQumBkZXaymWooE IhoAoPyC4WBQmGXVjKFdifWOlSjFvid5 =dV/m -----END PGP SIGNATURE----- From turners@ieca.com Wed Aug 12 14:17:31 2009 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 C65193A67B2 for ; Wed, 12 Aug 2009 14:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh+T5DLyN1EM for ; Wed, 12 Aug 2009 14:17:31 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id E203B3A6902 for ; Wed, 12 Aug 2009 14:17:30 -0700 (PDT) Received: (qmail 95499 invoked from network); 12 Aug 2009 21:16:41 -0000 Received: from unknown (HELO thunderfish.local) (turners@71.191.12.61 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 12 Aug 2009 21:16:41 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: CBQcXjUVM1mQwt.gUbCNcCtyeDKrpWe3OQukjOotHwmGd3W56HJAm01iFxBBNT0FVyMm9kx3P.aLOANz7XOg2hHcrbDaeJHGzmbySl6peNQ6o6RdyQ2MuroxdaNg74ZLAh8.3c0FZYyG1sFJgrGCYR_tYALi_4HDnafMPXkkos8dCdtvGryZK603b6aqlAdWxMETJ2rT9A7VIFUFKWhrGr_2Lvn0ElFpRwsZmOCCtYitHFPOuLzxPaQnfE5D2N.ZQ9FVqvysiif3_h38UYMq0QmkISdAuOr77Uer1JnJwQjmqZITkIWwcRulXomGQh9kzBJWWnmst2oOCrHhNcIE7if0e4nhABg_5w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A833139.4050302@ieca.com> Date: Wed, 12 Aug 2009 17:16:41 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: XMPP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [xmpp] IETF 75 XMPP Minutes 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: Wed, 12 Aug 2009 21:17:31 -0000 Many thanks go to Avshalom Houri for taking the minutes at the meeting. The meeting minutes for our session have been uploaded to the meeting material website. They can be found at: http://www.ietf.org/proceedings/75/minutes/xmpp.txt spt From ralphm@ik.nu Thu Aug 13 02:55:21 2009 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 876BB3A6902 for ; Thu, 13 Aug 2009 02:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68A+F7+MYzlY for ; Thu, 13 Aug 2009 02:55:20 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [80.255.245.75]) by core3.amsl.com (Postfix) with ESMTP id 814E13A67AC for ; Thu, 13 Aug 2009 02:55:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 05DB1A1044; Thu, 13 Aug 2009 11:51:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by localhost (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id Drrd+VKxYbjq; Thu, 13 Aug 2009 11:50:28 +0200 (CEST) Received: from [192.168.3.103] (s559155b2.adsl.wanadoo.nl [85.145.85.178]) by mag.ik.nu (Postfix) with ESMTPSA id CA488A1043; Thu, 13 Aug 2009 11:50:27 +0200 (CEST) From: Ralph Meijer To: Peter Saint-Andre In-Reply-To: <4A830932.6080608@stpeter.im> References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> Content-Type: text/plain Date: Thu, 13 Aug 2009 11:50:26 +0200 Message-Id: <1250157026.16747.25.camel@dwaal> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Aug 2009 04:50:24 -0700 Cc: Joe Hildebrand , Kurt Zeilenga , XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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, 13 Aug 2009 11:43:26 -0000 On Wed, 2009-08-12 at 12:25 -0600, Peter Saint-Andre wrote: > [..] > > Putting together everything discussed in this thread, I suggest the > following text: > > Stanzas themselves (i.e., the , , and > elements qualified by the "jabber:client" or "jabber:server" > namespace) and child elements of stanzas MAY also include attributes > that are qualified by XML namespaces other than "jabber:client", > "jabber:server", or "http://etherx.jabber.org/streams". For the sake > of backward compatibility and maximum interoperability, an entity > that generates a stanza SHOULD NOT include such attributes in the > stanza itself or in child elements of the stanza that are qualified > by the "jabber:client" and "jabber:server" namespaces (e.g., the > message element). This is not correct. Attributes without a prefix DO NOT inherit the namespace of the containing element. They are in the empty namespace. This is documented here: http://www.w3.org/TR/REC-xml-names/#defaulting As it is worded now, this would be ok: and this wouldn't be: -- Groetjes, ralphm From stpeter@stpeter.im Thu Aug 13 07:16:58 2009 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 A04793A698F for ; Thu, 13 Aug 2009 07:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] 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 3WDaJwcl-WkF for ; Thu, 13 Aug 2009 07:16:57 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 68EC43A6834 for ; Thu, 13 Aug 2009 07:16:57 -0700 (PDT) Received: from squire.local (ip-216-17-182-239.rev.frii.com [216.17.182.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C27E4007B; Thu, 13 Aug 2009 08:14:30 -0600 (MDT) Message-ID: <4A841FC5.80503@stpeter.im> Date: Thu, 13 Aug 2009 08:14:29 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ralph Meijer References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> In-Reply-To: <1250157026.16747.25.camel@dwaal> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , Kurt Zeilenga , XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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, 13 Aug 2009 14:16:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/13/09 3:50 AM, Ralph Meijer wrote: > On Wed, 2009-08-12 at 12:25 -0600, Peter Saint-Andre wrote: >> [..] >> >> Putting together everything discussed in this thread, I suggest the >> following text: >> >> Stanzas themselves (i.e., the , , and >> elements qualified by the "jabber:client" or "jabber:server" >> namespace) and child elements of stanzas MAY also include attributes >> that are qualified by XML namespaces other than "jabber:client", >> "jabber:server", or "http://etherx.jabber.org/streams". For the sake >> of backward compatibility and maximum interoperability, an entity >> that generates a stanza SHOULD NOT include such attributes in the >> stanza itself or in child elements of the stanza that are qualified >> by the "jabber:client" and "jabber:server" namespaces (e.g., the >> message element). > > This is not correct. Attributes without a prefix DO NOT inherit the > namespace of the containing element. They are in the empty namespace. > This is documented here: http://www.w3.org/TR/REC-xml-names/#defaulting > As it is worded now, this would be ok: > > > > and this wouldn't be: > > xmlns:client="jabber:client"/> The text I proposed does not talk about prefixing, but about whether an attribute is qualified by a namespace other than the default namespace or the streams namespace (perhaps the term "bound to" would be clearer than the term "qualified by"?). In your first example, the attribute 'myfancyattribute' is qualified by the default namespace according to the defaulting rules you have quoted, but it is not defined in the schema for the default namespace (assuming the default is 'jabber:client' or 'jabber:server') and therefore I think it is invalid content. In your second example, the entity is unnecessarily defining the attribute 'myfancyattribute' as qualified by the 'jabber:client' namespace, yet that is a mere assertion because that attribute is not to be found in the schema. Here again, invalid content. The example that people are concerned about is something like this (which is valid but not recommended): The content that Kurt would like to include is something like this (see http://www.w3.org/TR/xml-id/ for reference): content It strikes me that we might make an exception for attributes that are bound to the namespace name http://www.w3.org/XML/1998/namespace since we assume that all XMPP applications are XML applications, but that we don't necessarily want to generalize beyond that. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqEH8UACgkQNL8k5A2w/vxXLwCeIS9cpOXcwrh0/zZlURqzjXAB uFcAn2fQRNji8oNIlvh11NbDPIMpp+3b =AVvj -----END PGP SIGNATURE----- From metajack@gmail.com Thu Aug 13 09:05:56 2009 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 BCCBF3A6A76 for ; Thu, 13 Aug 2009 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6] 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 E9xbXENQDJwQ for ; Thu, 13 Aug 2009 09:05:56 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id CC10D3A68A6 for ; Thu, 13 Aug 2009 09:05:55 -0700 (PDT) Received: by ewy10 with SMTP id 10so889864ewy.37 for ; Thu, 13 Aug 2009 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7GW6Scyu+eveA6MoWfLzbtmmbHx0UgjG4dBZEUTV4oE=; b=aTG7hR5k+xb5/9k1p25GRd/i2RagrGlnzFdO8ZZHwCxKPP/D1GpJw3fRSGJXgevq2F SgQiFpJaiExV0lEURtbnM1d97UW6LVLyrnwz/1OiqjWBP/W+N3OJ1dlK9ltOONRMwfqO HTl+JO2a8NIPd8F1m+5tTQZ3NGMN6Okh3q88E= 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:content-type :content-transfer-encoding; b=SqqzwwMfkmpFHbm6uO+L2QhDH6+sJCN5JkzR+oMtFCs2cAAvDk4KB/0sYLAgmaFD0H E3cYj+Vn+v9DEAyq6yfgW2Oa+95GlJEQB63gn3B4Yw+ymV7UVNwftQ6+LjFiKyh4RDDn 9Yjh+DwyknnSrIZl4qcfn4dM/tfx4UKw24KlU= MIME-Version: 1.0 Sender: metajack@gmail.com Received: by 10.216.7.67 with SMTP id 45mr193174weo.95.1250179404565; Thu, 13 Aug 2009 09:03:24 -0700 (PDT) In-Reply-To: <4A841FC5.80503@stpeter.im> References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> <4A841FC5.80503@stpeter.im> Date: Thu, 13 Aug 2009 10:03:24 -0600 X-Google-Sender-Auth: d81cdb3f87dbac2b Message-ID: <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> From: Jack Moffitt To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] extensibility of existing XMPP elements 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, 13 Aug 2009 16:05:56 -0000 > In your first example, the attribute 'myfancyattribute' is qualified by > the default namespace according to the defaulting rules you have quoted, > but it is not defined in the schema for the default namespace (assuming > the default is 'jabber:client' or 'jabber:server') and therefore I think > it is invalid content. The text Ralph pointed to specifically says attributes that are unprefixed are not associated with any namespace, regardless of whether there is a default namespace in scope or not. "The interpretation of unprefixed attributes is determined by the element on which they appear", whatever that means. This is certainly counter-intuitive and not at all what I had previously understood. Does this mean that the DTD for jabber:client could say that th to attribute on a element is really from the jabber:server namespace? I'm guessing this is why xmlns doesn't need a prefix. I will have to go read deeper to figure out what the conformance requirements are. I'm guessing they must be the same or there would be no confusion :) > It strikes me that we might make an exception for attributes that are > bound to the namespace name http://www.w3.org/XML/1998/namespace since > we assume that all XMPP applications are XML applications, but that we > don't necessarily want to generalize beyond that. I do think we need to grandfather in the http://www.w3.org/XML/1998/namespace namespace. jack. From stpeter@stpeter.im Thu Aug 13 21:56:20 2009 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 651243A68A8 for ; Thu, 13 Aug 2009 21:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] 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 nt9z8WhMrhl5 for ; Thu, 13 Aug 2009 21:56:19 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2088A3A6407 for ; Thu, 13 Aug 2009 21:56:19 -0700 (PDT) Received: from squire.local (dsl-251-203.dynamic-dsl.frii.net [216.17.251.203]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F18FA4007B; Thu, 13 Aug 2009 22:56:22 -0600 (MDT) Message-ID: <4A84EE6E.2010203@stpeter.im> Date: Thu, 13 Aug 2009 22:56:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jack Moffitt References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> <4A841FC5.80503@stpeter.im> <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> In-Reply-To: <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Fri, 14 Aug 2009 04:56:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/13/09 10:03 AM, Jack Moffitt wrote: >> In your first example, the attribute 'myfancyattribute' is qualified by >> the default namespace according to the defaulting rules you have quoted, >> but it is not defined in the schema for the default namespace (assuming >> the default is 'jabber:client' or 'jabber:server') and therefore I think >> it is invalid content. > > The text Ralph pointed to specifically says attributes that are > unprefixed are not associated with any namespace, regardless of > whether there is a default namespace in scope or not. "The > interpretation of unprefixed attributes is determined by the element > on which they appear", whatever that means. This is certainly > counter-intuitive and not at all what I had previously understood. Ralph was right, I was wrong. Here is the relevant text: "Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.... The namespace name for an unprefixed attribute name always has no value." Ralph interpreted this to mean that "Attributes without a prefix DO NOT inherit the namespace of the containing element. They are in the empty namespace." I'm not sure this really matters, because the text says that "the interpretation of unprefixed attributes is determined by the element on which they appear", which to me sounds like *effectively* inheriting the namespace of the containing element. I think this is what the Namespaces in XML spec means when it says that "The namespace name for an unprefixed attribute name always has no value", which I interpret as equivalent to what Ralph called "the empty namespace" (whatever that is!). I realize that this sounds like a purely philosophical topic, but in practice I don't think it matters whether an unprefixed attribute has an empty namespace, a namespace name with no value, or whatever; what matters is the practical interpretation of an unprefixed attribute, which "is determined by the element on which [it] appear[s]". > Does this mean that the DTD for jabber:client could say that the to > attribute on a element is really from the jabber:server > namespace? I'm guessing this is why xmlns doesn't need a prefix. Among other things, it means that the second 'type' attribute in the following example is not qualified by the default namespace, because "the interpretation of unprefixed attributes is determined by the element on which they appear"... I don't think it means that the 'to' attribute on a stanza in a stream whose default namespace is "jabber:client" is really qualified by the "jabber:server" namespace, because in this case the stanza is qualified by the default namespace and therefore the "to" attribute is also qualified by that namespace (since it is unprefixed). As a reminder, here is the text I suggested: Stanzas themselves (i.e., the , , and elements qualified by the "jabber:client" or "jabber:server" namespace) and child elements of stanzas MAY also include attributes that are qualified by XML namespaces other than "jabber:client", "jabber:server", or "http://etherx.jabber.org/streams";. For the sake of backward compatibility and maximum interoperability, an entity that generates a stanza SHOULD NOT include such attributes in the stanza itself or in child elements of the stanza that are qualified by the "jabber:client" and "jabber:server" namespaces (e.g., the message element). Ralph says that according to the text I provided, the following stanza is acceptable... ... whereas the following stanza is not acceptable ... I suggest that these two are practically equivalent, for the reasons I mentioned above. However, I think that the text can be clarified appropriately by changing "attributes" to "prefixed attributes" and making a few additional clarifications, as follows: Stanzas themselves (i.e., the , , and elements qualified by the "jabber:client" or "jabber:server" namespace declared as the default namespace for the stream) and child elements of such stanzas MAY also include prefixed attributes that are qualified by XML namespaces other than the default namespace for the stream or the reserved "xml" prefix. For the sake of backward compatibility and maximum interoperability, an entity that generates a stanza SHOULD NOT include such attributes in the stanza itself or in child elements of the stanza that are qualified by the default namespace (e.g., the message element). > I will have to go read deeper to figure out what the conformance > requirements are. I'm guessing they must be the same or there would > be no confusion :) In fact I think they might be reasonable, but not clearly expressed. >> It strikes me that we might make an exception for attributes that are >> bound to the namespace name http://www.w3.org/XML/1998/namespace since >> we assume that all XMPP applications are XML applications, but that we >> don't necessarily want to generalize beyond that. > > I do think we need to grandfather in the > http://www.w3.org/XML/1998/namespace namespace. Agreed. See above. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqE7m4ACgkQNL8k5A2w/vwlRgCfV+adgkZCGxJ/gcENu9lxnJji P7sAni6fr3Qmd2PYhwmqwCTlXUzBrf85 =SR9z -----END PGP SIGNATURE----- From waqas20@gmail.com Thu Aug 13 23:04:54 2009 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 194EA3A6C16 for ; Thu, 13 Aug 2009 23:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByvmQINy0N+f for ; Thu, 13 Aug 2009 23:04:52 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id B382A3A69E2 for ; Thu, 13 Aug 2009 23:04:52 -0700 (PDT) Received: by yxe3 with SMTP id 3so1806888yxe.29 for ; Thu, 13 Aug 2009 23:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FzfrgFeyuH6EyUPBhmCMvNAfvwguNKeLAkIGXnuyh8Y=; b=QZCormTAGrFJRcyBD6PmSWiOklnn5+wiaEC1eiYxHmg6G8ILFt0HbncA4DQ0PBxNTP pfzNFkEaADfWkVAIoA2KOrrwsnjn79rMNisyIyILx9z7PhZ13U/XHcJd8gxaiaQZpOqr hGS3G/3Etd+scNxp4lhlV103vxoZRV/cd41x0= 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=i/Vz8dJDzqEmIJTN+JMICijvA2EW32D8c9p3QQWLeE2L1srgvxLyk7K2zeI7OwTTWO EWIclqBMhe4bKxp2KLvPK/S3WiV76EfpCbS/IqQC/xVxhUCAUvtyRiyxlDe1LLW413gu 8WCP0pCLOjivVySFsXHMmGwFbNLmu9cR4MrY0= MIME-Version: 1.0 Received: by 10.150.116.13 with SMTP id o13mr2196610ybc.134.1250229894534; Thu, 13 Aug 2009 23:04:54 -0700 (PDT) In-Reply-To: <4A84EE6E.2010203@stpeter.im> References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> <4A841FC5.80503@stpeter.im> <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> <4A84EE6E.2010203@stpeter.im> Date: Fri, 14 Aug 2009 11:04:54 +0500 Message-ID: <7fc4fa880908132304t9bbcb03g6f59d4389bf8e2a0@mail.gmail.com> From: Waqas Hussain To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Fri, 14 Aug 2009 06:04:54 -0000 On Fri, Aug 14, 2009 at 9:56 AM, Peter Saint-Andre wrot= e: > I don't think it means that the 'to' attribute on a stanza in > a stream whose default namespace is "jabber:client" is really qualified > by the "jabber:server" namespace, because in this case the > stanza is qualified by the default namespace and therefore the "to" > attribute is also qualified by that namespace (since it is unprefixed). The 'to' attribute is not qualified by the default stream namespace, but the default empty "" namespace. > Ralph says that according to the text I provided, the following stanza > is acceptable... > > =A0 > > ... whereas the following stanza is not acceptable ... > > =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns:client=3D"jabber:client"/> And that's fine. The two are not equivalent. > I suggest that these two are practically equivalent, for the reasons I > mentioned above. However, I think that the text can be clarified > appropriately by changing "attributes" to "prefixed attributes" and > making a few additional clarifications, as follows: > > =A0Stanzas themselves (i.e., the , , and > =A0elements qualified by the "jabber:client" or "jabber:server" > =A0namespace declared as the default namespace for the stream) > =A0and child elements of such stanzas MAY also include prefixed > =A0attributes that are qualified by XML namespaces other than > =A0the default namespace for the stream or the reserved "xml" > =A0prefix. =A0For the sake of backward compatibility and maximum > =A0interoperability, an entity that generates a stanza SHOULD NOT > =A0include such attributes in the stanza itself or in child elements > =A0of the stanza that are qualified by the default namespace (e.g., > =A0the message element). Why make a special case for prefixed attributes qualified by the default stream namespace? We don't use them in any specification, and they wouldn't make sense otherwise. And again, they are not the same as non-prefixed attributes. >> I will have to go read deeper to figure out what the conformance >> requirements are. =A0I'm guessing they must be the same or there would >> be no confusion :) > > In fact I think they might be reasonable, but not clearly expressed. Namespace prefixes, particularly for attributes cause a lot of confusion. It might help to 'roll-out' the prefixes when thinking about them. Think of as <{jabber:client}presence {}myfancyattribute=3D"yay!"/> and maps to <{jabber:client}presence {jabber:client}myfancyattribute=3D"yay!"/> (expansion notation stolen from http://www.jclark.com/xml/xmlns.htm - which might be a useful read) As should be apparent, both a namespace aware, and namespace unaware XML processor (conforming ones at least) would see both of the above as different. There is no reason for attributes qualified by "jabber:client" to get any special consideration. >>> It strikes me that we might make an exception for attributes that are >>> bound to the namespace name http://www.w3.org/XML/1998/namespace since >>> we assume that all XMPP applications are XML applications, but that we >>> don't necessarily want to generalize beyond that. >> >> I do think we need to grandfather in the >> http://www.w3.org/XML/1998/namespace namespace. > > Agreed. See above. That depends. It's pretty much an implicit requirement (or it could be explicit, I didn't look it up right now) for XML processors. Expat in namespace aware mode for example reports the namespace with attributes (i.e., it reports finding "http://www.w3.org/XML/1998/namespace|lang" and not "xml:lang"). Also, while we are talking about prefixed attributes on stanzas, what about namespace prefix declarations? They are not the same for a namespace aware XML processor. Expat for example does not report finding "xmlns" or "xmlns:*" attributes (because they are special, qualified by the magical "http://www.w3.org/2000/xmlns/" namespace, which can neither be seen, nor used). Also, why prevent prefixed attributes on children of stanzas? Prefixed attributes are pretty much in the spirit of XML namespaces, and I don't think there are any interop problems. Heck, being able to stick attributes in arbitrary locations without conflicts is the sole reason prefixed attributes exist. Are there any known problems with any implementation? I think it's unlikely, since you would pretty much have to work at it to make it fail. > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ -- Waqas Hussain From Joe.Hildebrand@webex.com Fri Aug 14 13:24:49 2009 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 87B173A6BD8 for ; Fri, 14 Aug 2009 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.182 X-Spam-Level: X-Spam-Status: No, score=-104.182 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 MqbNKE8UjlOS for ; Fri, 14 Aug 2009 13:24:48 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id D32073A6BAA for ; Fri, 14 Aug 2009 13:24:48 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 13:24:53 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Aug 2009 20:24:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 14 Aug 2009 14:24:45 -0600 From: Joe Hildebrand To: Waqas Hussain , Peter Saint-Andre Message-ID: Thread-Topic: [xmpp] extensibility of existing XMPP elements Thread-Index: AcodHUMSp3XS2xANrEmrAggDuDvq5Q== In-Reply-To: <7fc4fa880908132304t9bbcb03g6f59d4389bf8e2a0@mail.gmail.com> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Aug 2009 20:24:53.0145 (UTC) FILETIME=[47ECF890:01CA1D1D] Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Fri, 14 Aug 2009 20:24:49 -0000 On 8/14/09 12:04 AM, "Waqas Hussain" wrote: > Also, why prevent prefixed attributes on children of stanzas? Prefixed > attributes are pretty much in the spirit of XML namespaces, and I > don't think there are any interop problems. Heck, being able to stick > attributes in arbitrary locations without conflicts is the sole reason > prefixed attributes exist. Are there any known problems with any > implementation? I think it's unlikely, since you would pretty much > have to work at it to make it fail. The most important thing is that you can't use a prefix that was declared outside the stanza (for example, on a stream:stream element), since that context will be lost when the stanza is resent through multiple servers. A lesser issue at this point was that we used to have servers that were almost completely namespace unaware, that were likely to serialize prefixed content oddly when it was resent. That may not be as much of an issue now, but we should do some testing for real-world backward compatibility before loosening up the prefix restriction. Regardless, if we do allow prefixes, it may be difficult to guarantee that the prefix string would stay constant through a series of parse/serialize operations. If prefixes are allowed, we should point out that processors SHOULD try to maintain prefixes when serializing, but receivers MUST NOT rely on the prefix strings having any particular value. -- Joe Hildebrand From stpeter@stpeter.im Fri Aug 14 15:15:38 2009 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 09F5E28C205 for ; Fri, 14 Aug 2009 15:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] 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 axo+IJbwseml for ; Fri, 14 Aug 2009 15:15:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 21F9F28C20A for ; Fri, 14 Aug 2009 15:15:36 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 082604007B; Fri, 14 Aug 2009 16:15:37 -0600 (MDT) Message-ID: <4A85E208.3060909@stpeter.im> Date: Fri, 14 Aug 2009 16:15:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Waqas Hussain References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> <4A841FC5.80503@stpeter.im> <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> <4A84EE6E.2010203@stpeter.im> <7fc4fa880908132304t9bbcb03g6f59d4389bf8e2a0@mail.gmail.com> In-Reply-To: <7fc4fa880908132304t9bbcb03g6f59d4389bf8e2a0@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Fri, 14 Aug 2009 22:15:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/14/09 12:04 AM, Waqas Hussain wrote: > On Fri, Aug 14, 2009 at 9:56 AM, Peter Saint-Andre wrote: >> I don't think it means that the 'to' attribute on a stanza in >> a stream whose default namespace is "jabber:client" is really qualified >> by the "jabber:server" namespace, because in this case the >> stanza is qualified by the default namespace and therefore the "to" >> attribute is also qualified by that namespace (since it is unprefixed). > > The 'to' attribute is not qualified by the default stream namespace, > but the default empty "" namespace. > >> Ralph says that according to the text I provided, the following stanza >> is acceptable... >> >> >> >> ... whereas the following stanza is not acceptable ... >> >> > xmlns:client="jabber:client"/> > > And that's fine. The two are not equivalent. > >> I suggest that these two are practically equivalent, for the reasons I >> mentioned above. However, I think that the text can be clarified >> appropriately by changing "attributes" to "prefixed attributes" and >> making a few additional clarifications, as follows: >> >> Stanzas themselves (i.e., the , , and >> elements qualified by the "jabber:client" or "jabber:server" >> namespace declared as the default namespace for the stream) >> and child elements of such stanzas MAY also include prefixed >> attributes that are qualified by XML namespaces other than >> the default namespace for the stream or the reserved "xml" >> prefix. For the sake of backward compatibility and maximum >> interoperability, an entity that generates a stanza SHOULD NOT >> include such attributes in the stanza itself or in child elements >> of the stanza that are qualified by the default namespace (e.g., >> the message element). > > Why make a special case for prefixed attributes qualified by the > default stream namespace? We don't use them in any specification, and > they wouldn't make sense otherwise. And again, they are not the same > as non-prefixed attributes. We make a special case for "extensions" in the sense of "extended content" as described in 3920/3920bis. In the case of elements this is clear. In the case of attributes this is not clear because of the crazy no-namespace rules in the namespaces spec. Therefore we need to make this as clear as we can, which is what we're trying to do in this thread. If you have text suggestions, feel free to provide them on the list. I don't understand the exact nature of your suggestions. >>> I will have to go read deeper to figure out what the conformance >>> requirements are. I'm guessing they must be the same or there would >>> be no confusion :) >> In fact I think they might be reasonable, but not clearly expressed. > > Namespace prefixes, particularly for attributes cause a lot of > confusion. It might help to 'roll-out' the prefixes when thinking > about them. > > Think of > > > > as > > <{jabber:client}presence {}myfancyattribute="yay!"/> > > and > > > > maps to > > <{jabber:client}presence {jabber:client}myfancyattribute="yay!"/> > > (expansion notation stolen from http://www.jclark.com/xml/xmlns.htm - > which might be a useful read) Yes, that's good. > As should be apparent, both a namespace aware, and namespace unaware > XML processor (conforming ones at least) would see both of the above > as different. There is no reason for attributes qualified by > "jabber:client" to get any special consideration. They don't. The intent of the text I provided was to say that if you want to include "extension attributes" then you need to be careful, and an "extension attribute" is an attribute that is qualifed by a namespace other than the default namespace for the stream. What we're trying to specify is exactly what we mean by an "extension attribute", as we have done for "extension elements". If the current text is not clear, then we need to make it clear. Does removing the word "prefixed" help? I don't really think so. >>>> It strikes me that we might make an exception for attributes that are >>>> bound to the namespace name http://www.w3.org/XML/1998/namespace since >>>> we assume that all XMPP applications are XML applications, but that we >>>> don't necessarily want to generalize beyond that. >>> I do think we need to grandfather in the >>> http://www.w3.org/XML/1998/namespace namespace. >> Agreed. See above. > > That depends. It's pretty much an implicit requirement (or it could be > explicit, I didn't look it up right now) for XML processors. Expat in > namespace aware mode for example reports the namespace with attributes > (i.e., it reports finding "http://www.w3.org/XML/1998/namespace|lang" > and not "xml:lang"). > > Also, while we are talking about prefixed attributes on stanzas, what > about namespace prefix declarations? They are not the same for a > namespace aware XML processor. Expat for example does not report > finding "xmlns" or "xmlns:*" attributes (because they are special, > qualified by the magical "http://www.w3.org/2000/xmlns/" namespace, > which can neither be seen, nor used). > > Also, why prevent prefixed attributes on children of stanzas? Prefixed > attributes are pretty much in the spirit of XML namespaces, and I > don't think there are any interop problems. Heck, being able to stick > attributes in arbitrary locations without conflicts is the sole reason > prefixed attributes exist. Are there any known problems with any > implementation? I think it's unlikely, since you would pretty much > have to work at it to make it fail. See Joe's email. I don't think we want to prevent prefixed attributes, but you need to be careful about how you handle them. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqF4ggACgkQNL8k5A2w/vzNFQCcCRBsh4xNuINDmBBswkqZIvKE hhUAoJLTMUCviQrs0V2bmFEGVsfa8+cA =ECnp -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Aug 14 15:37:02 2009 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 034113A682F for ; Fri, 14 Aug 2009 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrPmT3gtMFxK for ; Fri, 14 Aug 2009 15:37:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E73563A6872 for ; Fri, 14 Aug 2009 15:37:00 -0700 (PDT) Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF8054007B; Fri, 14 Aug 2009 16:37:04 -0600 (MDT) Message-ID: <4A85E70F.40306@stpeter.im> Date: Fri, 14 Aug 2009 16:37:03 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Waqas Hussain References: <9EFD9CD5-70A0-496A-AAB8-E9FE1883CE38@Isode.com> <4A830932.6080608@stpeter.im> <1250157026.16747.25.camel@dwaal> <4A841FC5.80503@stpeter.im> <9b58f4550908130903h63dce821p54fe082057b94f25@mail.gmail.com> <4A84EE6E.2010203@stpeter.im> <7fc4fa880908132304t9bbcb03g6f59d4389bf8e2a0@mail.gmail.com> <4A85E208.3060909@stpeter.im> In-Reply-To: <4A85E208.3060909@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] extensibility of existing XMPP elements 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: Fri, 14 Aug 2009 22:37:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The text for this section now reads as follows... *** 9.4. Extended Content While the message, presence, and IQ stanzas provide basic semantics for messaging, availability, and request-response interactions, XMPP uses XML namespaces (see [XML-NAMES] to extend the basic stanza syntax for the purpose of providing additional functionality. A message or presence stanza MAY contain one or more optional child elements specifying content that extends the meaning of the message (e.g., an XHTML-formatted version of the message body as described in [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one such child element. Such a child element MAY have any name and MUST possess a namespace declaration (other than "jabber:client", "jabber: server", or "http://etherx.jabber.org/streams") that defines all data contained within the child element. Such a child element is called an "extension element". Similarly, "extension attributes" are allowed. That is: a stanza itself (i.e., the , , and elements qualified by the "jabber:client" or "jabber:server" namespace declared as the default namespace for the stream) and any child element of such a stanza (whether a child element qualifed by the default namespace or an extension element) MAY also include one or more attributes that are qualified by XML namespaces other than the default namespace or the reserved "xml" prefix (including the "empty namespace" if the attribute is not prefixed). For the sake of backward compatibility and maximum interoperability, an entity that generates a stanza SHOULD NOT include such attributes in the stanza itself or in child elements of the stanza that are qualified by the default namespace (e.g., the message element). An extension element or extension attribute is said to be EXTENDED CONTENT and the namespace name for such an element or attribute is said to be an EXTENDED NAMESPACE. Because an XML stanza is the primary unit of meaning in XMPP, any prefixed element or attribute included in a stanza MUST use a prefix that is declared in the stanza itself or a child element of the stanza, not outside the context of the stanza (e.g., not on the stream header). Routing entities (typically servers) SHOULD try to maintain prefixes when serializing XML stanzas for processing, but receiving entities MUST NOT rely on the prefix strings having any particular value. Support for any given extended namespace is OPTIONAL on the part of any implementation. If an entity does not understand such a namespace, the entity's expected behavior depends on whether the entity is (1) the recipient or (2) an entity that is routing the stanza to the recipient. Recipient: If a recipient receives a stanza that contains a child element it does not understand, it MUST silently ignore that particular XML data, i.e., it MUST NOT process it or present it to a user or associated application (if any). In particular: * If an entity receives a message or presence stanza that contains XML data qualified by a namespace it does not understand, the portion of the stanza that qualified by the unknown namespace MUST be ignored. * If an entity receives a message stanza whose only child element is qualified by a namespace it does not understand, it MUST ignore the entire stanza. * If an entity receives an IQ stanza of type "get" or "set" containing a child element qualified by a namespace it does not understand, the entity MUST return an IQ stanza of type "error" with an error condition of . Router: If a routing entity (typically a server) handles a stanza that contains a child element it does not understand, it MUST ignore the associated XML data by routing or delivering it untouched to the recipient. *** This text is in the -01 draft, which I have just submitted. It can be further cleaned up in -02. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqF5w8ACgkQNL8k5A2w/vzrpwCfQLaE8oS5NhRMk534+nu6raAD TjoAnj4hCy7hcyMHe/52PdotkAkEoYEQ =GhBy -----END PGP SIGNATURE----- From root@core3.amsl.com Fri Aug 14 15:45:01 2009 Return-Path: X-Original-To: xmpp@ietf.org Delivered-To: xmpp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5EDDE3A68B1; Fri, 14 Aug 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090814224501.5EDDE3A68B1@core3.amsl.com> Date: Fri, 14 Aug 2009 15:45:01 -0700 (PDT) Cc: xmpp@ietf.org Subject: [xmpp] I-D Action:draft-ietf-xmpp-3921bis-01.txt 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: Fri, 14 Aug 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence Author(s) : P. Saint-Andre Filename : draft-ietf-xmpp-3921bis-01.txt Pages : 99 Date : 2009-08-14 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 RFC 2779. This document obsoletes RFC 3921. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3921bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xmpp-3921bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-14153522.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Aug 14 15:45:01 2009 Return-Path: X-Original-To: xmpp@ietf.org Delivered-To: xmpp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 69A703A68DA; Fri, 14 Aug 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090814224501.69A703A68DA@core3.amsl.com> Date: Fri, 14 Aug 2009 15:45:01 -0700 (PDT) Cc: xmpp@ietf.org Subject: [xmpp] I-D Action:draft-ietf-xmpp-3920bis-01.txt 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: Fri, 14 Aug 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Core Author(s) : P. Saint-Andre Filename : draft-ietf-xmpp-3920bis-01.txt Pages : 165 Date : 2009-08-14 This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3920bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xmpp-3920bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-14153525.I-D@ietf.org> --NextPart-- From stpeter@stpeter.im Mon Aug 24 08:36:29 2009 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 45F8528C127 for ; Mon, 24 Aug 2009 08:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] 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 h5+v6AP7t17S for ; Mon, 24 Aug 2009 08:36:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 485813A6B52 for ; Mon, 24 Aug 2009 08:36:28 -0700 (PDT) Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3A4464007B for ; Mon, 24 Aug 2009 09:36:30 -0600 (MDT) Message-ID: <4A92B381.20509@stpeter.im> Date: Mon, 24 Aug 2009 09:36:33 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] [Fwd: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard] 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, 24 Aug 2009 15:36:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Given that XMPP has a dependency on TLS, this might be of interest... /psa - -------- Original Message -------- Subject: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard Date: Mon, 24 Aug 2009 07:01:46 -0700 (PDT) From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: tls@ietf.org The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - - 'Transport Layer Security (TLS) Extensions: Extension Definitions ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16186&rfc_flag=0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqSs4AACgkQNL8k5A2w/vwNdQCgr2UefXiJU2bijgQ6uWTshDqp 0awAoI5cvSgntezsVHm983EOiwVqq6OO =bLgy -----END PGP SIGNATURE----- From root@core3.amsl.com Thu Aug 27 15:45:01 2009 Return-Path: X-Original-To: xmpp@ietf.org Delivered-To: xmpp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D81AC3A6DC1; Thu, 27 Aug 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090827224501.D81AC3A6DC1@core3.amsl.com> Date: Thu, 27 Aug 2009 15:45:01 -0700 (PDT) Cc: xmpp@ietf.org Subject: [xmpp] I-D Action:draft-ietf-xmpp-e2e-requirements-00.txt 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, 27 Aug 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) Author(s) : P. Saint-Andre Filename : draft-ietf-xmpp-e2e-requirements-00.txt Pages : 9 Date : 2009-08-27 This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-requirements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xmpp-e2e-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-27153147.I-D@ietf.org> --NextPart--