From stpeter@stpeter.im Fri Dec 9 12:38:20 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E610521F84C1 for ; Fri, 9 Dec 2011 12:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSFBYCvoqO6k for ; Fri, 9 Dec 2011 12:38:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85421F841A for ; Fri, 9 Dec 2011 12:38:20 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0202942381; Fri, 9 Dec 2011 13:45:39 -0700 (MST) Message-ID: <4EE271B7.1020700@stpeter.im> Date: Fri, 09 Dec 2011 13:38:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Holler References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> In-Reply-To: <4E4EAD68.5050300@ahsoftware.de> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:38:21 -0000 Old thread alert! On 8/19/11 12:37 PM, Alexander Holler wrote: > Am 19.08.2011 19:03, schrieb Peter Saint-Andre: >> On 8/14/11 12:44 PM, Alexander Holler wrote: >>> Hello, >>> >>> RFC 6121 doesn't mention what happens with JIDs in roster items with an >>> non empty resource part. >>> >>> Because subscription requests should be treated with the bare JID only, >>> such roster items doesn't seem to make much sence. >>> >>> So, if I don't miss something, the attribute jid of a roster item should >>> be a bare JID (or changed by the server to such). >>> >>> And it might be worth to mention that the change of 'to' in >>> (un)subscribes from full to bare JIDs by the server might lead to error >>> stanzas where the 'from' and 'to' attributes are not only exchanged >>> (because 'to' got modified). Verbose: a presence with type 'subscribe' >>> to 'user@example.com/nick' might result in a presence of type error from >>> 'user@example.com' and not from 'user@example.com/nick' (e.g. with >>> remote-server-not-found) >> >> Section 3.1.1 says: >> >> A user's client generates a subscription request by sending a >> presence stanza of type "subscribe" and specifying a 'to' address of >> the potential contact's bare JID . > > I've read that and the following sections. But I've written the above > complain because nowhere in section 2 is something written about the > type of JIDs in rosters. So according to RFC 6121 it is possible to add > a JID with a resource part to the roster, even if it doesn't make sense, > at least not in regard to subscriptions. Yes, it is possible, but not encouraged. The reason we don't prohibit this behavior is that we don't want to unnecessarily constrain users from adding any JID to the roster or constrain applications regarding the addresses they use (e.g., a bot might be located at example.com/bot and we don't want to say that you can't add such a thing to your roster). Peter -- Peter Saint-Andre https://stpeter.im/ From holler@ahsoftware.de Sun Dec 11 01:56:46 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365321F8ABE for ; Sun, 11 Dec 2011 01:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QWXg9V5uJQX for ; Sun, 11 Dec 2011 01:56:46 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id D035E21F8A62 for ; Sun, 11 Dec 2011 01:56:45 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id D188CA834F; Sun, 11 Dec 2011 10:56:41 +0100 (CET) Received: from eiche.ahsoftware (p57B20F9D.dip0.t-ipconnect.de [87.178.15.157]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id DF27EA834F for ; Sun, 11 Dec 2011 10:56:35 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id EC6753FDAE; Sun, 11 Dec 2011 10:56:32 +0100 (CET) Received: from krabat.ahsoftware (unknown [192.168.207.2]) by eiche.ahsoftware (Postfix) with ESMTP id 38E743FCD4; Sun, 11 Dec 2011 09:56:29 +0000 (UTC) Message-ID: <4EE47E4C.90400@ahsoftware.de> Date: Sun, 11 Dec 2011 10:56:28 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> <4EE271B7.1020700@stpeter.im> In-Reply-To: <4EE271B7.1020700@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 09:56:46 -0000 Am 09.12.2011 21:38, schrieb Peter Saint-Andre: > Old thread alert! > > On 8/19/11 12:37 PM, Alexander Holler wrote: >> Am 19.08.2011 19:03, schrieb Peter Saint-Andre: >>> On 8/14/11 12:44 PM, Alexander Holler wrote: >>>> Hello, >>>> >>>> RFC 6121 doesn't mention what happens with JIDs in roster items with an >>>> non empty resource part. >>>> >>>> Because subscription requests should be treated with the bare JID only, >>>> such roster items doesn't seem to make much sence. >>>> >>>> So, if I don't miss something, the attribute jid of a roster item should >>>> be a bare JID (or changed by the server to such). >>>> >>>> And it might be worth to mention that the change of 'to' in >>>> (un)subscribes from full to bare JIDs by the server might lead to error >>>> stanzas where the 'from' and 'to' attributes are not only exchanged >>>> (because 'to' got modified). Verbose: a presence with type 'subscribe' >>>> to 'user@example.com/nick' might result in a presence of type error from >>>> 'user@example.com' and not from 'user@example.com/nick' (e.g. with >>>> remote-server-not-found) >>> >>> Section 3.1.1 says: >>> >>> A user's client generates a subscription request by sending a >>> presence stanza of type "subscribe" and specifying a 'to' address of >>> the potential contact's bare JID. >> >> I've read that and the following sections. But I've written the above >> complain because nowhere in section 2 is something written about the >> type of JIDs in rosters. So according to RFC 6121 it is possible to add >> a JID with a resource part to the roster, even if it doesn't make sense, >> at least not in regard to subscriptions. > > Yes, it is possible, but not encouraged. The reason we don't prohibit > this behavior is that we don't want to unnecessarily constrain users > from adding any JID to the roster or constrain applications regarding > the addresses they use (e.g., a bot might be located at example.com/bot > and we don't want to say that you can't add such a thing to your roster). That doesn't answer what a server is supposed to do with such roster items (or the request to add them). Just putting them into the roster, ignoring them otherwise (the subscriptions state would be always none)? Because I currently don't have the time to work on my server, I don't know out of my memories what I've choosen to do, but I tend to just forbid such requests. Regards, Alexander From stpeter@stpeter.im Thu Dec 15 16:41:11 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22811F0C60 for ; Thu, 15 Dec 2011 16:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYw1UFbEt7is for ; Thu, 15 Dec 2011 16:41:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E6AA621F8448 for ; Thu, 15 Dec 2011 16:41:10 -0800 (PST) Received: from squire.local (unknown [216.17.140.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 32C3E42409; Thu, 15 Dec 2011 17:48:50 -0700 (MST) Message-ID: <4EEA891B.2030702@stpeter.im> Date: Thu, 15 Dec 2011 16:56:11 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Holler References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> <4EE271B7.1020700@stpeter.im> <4EE47E4C.90400@ahsoftware.de> In-Reply-To: <4EE47E4C.90400@ahsoftware.de> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 00:41:11 -0000 On 12/11/11 2:56 AM, Alexander Holler wrote: > Am 09.12.2011 21:38, schrieb Peter Saint-Andre: >> Old thread alert! >> >> On 8/19/11 12:37 PM, Alexander Holler wrote: >>> Am 19.08.2011 19:03, schrieb Peter Saint-Andre: >>>> On 8/14/11 12:44 PM, Alexander Holler wrote: >>>>> Hello, >>>>> >>>>> RFC 6121 doesn't mention what happens with JIDs in roster items >>>>> with an >>>>> non empty resource part. >>>>> >>>>> Because subscription requests should be treated with the bare JID >>>>> only, >>>>> such roster items doesn't seem to make much sence. >>>>> >>>>> So, if I don't miss something, the attribute jid of a roster item >>>>> should >>>>> be a bare JID (or changed by the server to such). >>>>> >>>>> And it might be worth to mention that the change of 'to' in >>>>> (un)subscribes from full to bare JIDs by the server might lead to >>>>> error >>>>> stanzas where the 'from' and 'to' attributes are not only exchanged >>>>> (because 'to' got modified). Verbose: a presence with type 'subscribe' >>>>> to 'user@example.com/nick' might result in a presence of type error >>>>> from >>>>> 'user@example.com' and not from 'user@example.com/nick' (e.g. with >>>>> remote-server-not-found) >>>> >>>> Section 3.1.1 says: >>>> >>>> A user's client generates a subscription request by sending a >>>> presence stanza of type "subscribe" and specifying a 'to' address of >>>> the potential contact's bare JID. >>> >>> I've read that and the following sections. But I've written the above >>> complain because nowhere in section 2 is something written about the >>> type of JIDs in rosters. So according to RFC 6121 it is possible to add >>> a JID with a resource part to the roster, even if it doesn't make sense, >>> at least not in regard to subscriptions. >> >> Yes, it is possible, but not encouraged. The reason we don't prohibit >> this behavior is that we don't want to unnecessarily constrain users >> from adding any JID to the roster or constrain applications regarding >> the addresses they use (e.g., a bot might be located at example.com/bot >> and we don't want to say that you can't add such a thing to your roster). > > That doesn't answer what a server is supposed to do with such roster > items (or the request to add them). Just putting them into the roster, > ignoring them otherwise (the subscriptions state would be always none)? > > Because I currently don't have the time to work on my server, I don't > know out of my memories what I've choosen to do, but I tend to just > forbid such requests. Postel's Law saith: "Be liberal in what you accept, conservative in what you send." IMHO it would be best for the server to accept such a roster item, and for human-oriented clients to discourage their users from sending such a roster item. I don't see it as the server's place to return an error (e.g., malformed-jid) in this case. Peter -- Peter Saint-Andre https://stpeter.im/ From holler@ahsoftware.de Thu Dec 15 19:58:52 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2798111E80C0 for ; Thu, 15 Dec 2011 19:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uFA-F4du3tY for ; Thu, 15 Dec 2011 19:58:51 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5168B11E80A5 for ; Thu, 15 Dec 2011 19:58:50 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 2EA74A8366; Fri, 16 Dec 2011 04:58:48 +0100 (CET) Received: from eiche.ahsoftware (p57B206A2.dip0.t-ipconnect.de [87.178.6.162]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 0221AA8361 for ; Fri, 16 Dec 2011 04:58:41 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id BE58A3FDAE; Fri, 16 Dec 2011 04:58:39 +0100 (CET) Received: from krabat.ahsoftware (unknown [192.168.207.2]) by eiche.ahsoftware (Postfix) with ESMTP id 56BC53FCD4; Fri, 16 Dec 2011 03:58:36 +0000 (UTC) Message-ID: <4EEAC1EB.2060006@ahsoftware.de> Date: Fri, 16 Dec 2011 04:58:35 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> <4EE271B7.1020700@stpeter.im> <4EE47E4C.90400@ahsoftware.de> <4EEA891B.2030702@stpeter.im> In-Reply-To: <4EEA891B.2030702@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 03:58:52 -0000 Am 16.12.2011 00:56, schrieb Peter Saint-Andre: > On 12/11/11 2:56 AM, Alexander Holler wrote: >> Am 09.12.2011 21:38, schrieb Peter Saint-Andre: >>> Old thread alert! >>> >>> On 8/19/11 12:37 PM, Alexander Holler wrote: >>>> Am 19.08.2011 19:03, schrieb Peter Saint-Andre: >>>>> On 8/14/11 12:44 PM, Alexander Holler wrote: >>>>>> Hello, >>>>>> >>>>>> RFC 6121 doesn't mention what happens with JIDs in roster items >>>>>> with an >>>>>> non empty resource part. >>>>>> >>>>>> Because subscription requests should be treated with the bare JID >>>>>> only, >>>>>> such roster items doesn't seem to make much sence. >>>>>> >>>>>> So, if I don't miss something, the attribute jid of a roster item >>>>>> should >>>>>> be a bare JID (or changed by the server to such). >>>>>> >>>>>> And it might be worth to mention that the change of 'to' in >>>>>> (un)subscribes from full to bare JIDs by the server might lead to >>>>>> error >>>>>> stanzas where the 'from' and 'to' attributes are not only exchanged >>>>>> (because 'to' got modified). Verbose: a presence with type 'subscribe' >>>>>> to 'user@example.com/nick' might result in a presence of type error >>>>>> from >>>>>> 'user@example.com' and not from 'user@example.com/nick' (e.g. with >>>>>> remote-server-not-found) >>>>> >>>>> Section 3.1.1 says: >>>>> >>>>> A user's client generates a subscription request by sending a >>>>> presence stanza of type "subscribe" and specifying a 'to' address of >>>>> the potential contact's bare JID. >>>> >>>> I've read that and the following sections. But I've written the above >>>> complain because nowhere in section 2 is something written about the >>>> type of JIDs in rosters. So according to RFC 6121 it is possible to add >>>> a JID with a resource part to the roster, even if it doesn't make sense, >>>> at least not in regard to subscriptions. >>> >>> Yes, it is possible, but not encouraged. The reason we don't prohibit >>> this behavior is that we don't want to unnecessarily constrain users >>> from adding any JID to the roster or constrain applications regarding >>> the addresses they use (e.g., a bot might be located at example.com/bot >>> and we don't want to say that you can't add such a thing to your roster). >> >> That doesn't answer what a server is supposed to do with such roster >> items (or the request to add them). Just putting them into the roster, >> ignoring them otherwise (the subscriptions state would be always none)? >> >> Because I currently don't have the time to work on my server, I don't >> know out of my memories what I've choosen to do, but I tend to just >> forbid such requests. > > Postel's Law saith: "Be liberal in what you accept, conservative in what > you send." > > IMHO it would be best for the server to accept such a roster item, and > for human-oriented clients to discourage their users from sending such a > roster item. I don't see it as the server's place to return an error > (e.g., malformed-jid) in this case. Hmm, I see more problems when accepting something which can't be used afterwards. Changing it (by the server), will end in other problems, e.g. what happens if an item without resource already exists? But regardless how it is solved, I think the best solution is to add a sentence to the next revision or version of the RFC which remarks that rosters with resource parts aren't functional and should not be used. ;) Regards, Alexander From stpeter@stpeter.im Fri Dec 16 08:29:35 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A145521F8B43 for ; Fri, 16 Dec 2011 08:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Zb1x3qKUAo for ; Fri, 16 Dec 2011 08:29:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BAD2B21F8B10 for ; Fri, 16 Dec 2011 08:29:34 -0800 (PST) Received: from dhcp-64-101-72-220.cisco.com (unknown [64.101.72.220]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4011142410; Fri, 16 Dec 2011 09:37:17 -0700 (MST) Message-ID: <4EEB6E37.5090003@stpeter.im> Date: Fri, 16 Dec 2011 09:13:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Holler References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> <4EE271B7.1020700@stpeter.im> <4EE47E4C.90400@ahsoftware.de> <4EEA891B.2030702@stpeter.im> <4EEAC1EB.2060006@ahsoftware.de> In-Reply-To: <4EEAC1EB.2060006@ahsoftware.de> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 16:29:35 -0000 On 12/15/11 8:58 PM, Alexander Holler wrote: > Am 16.12.2011 00:56, schrieb Peter Saint-Andre: >> On 12/11/11 2:56 AM, Alexander Holler wrote: >>> Am 09.12.2011 21:38, schrieb Peter Saint-Andre: >>>> Old thread alert! >>>> >>>> On 8/19/11 12:37 PM, Alexander Holler wrote: >>>>> Am 19.08.2011 19:03, schrieb Peter Saint-Andre: >>>>>> On 8/14/11 12:44 PM, Alexander Holler wrote: >>>>>>> Hello, >>>>>>> >>>>>>> RFC 6121 doesn't mention what happens with JIDs in roster items >>>>>>> with an >>>>>>> non empty resource part. >>>>>>> >>>>>>> Because subscription requests should be treated with the bare JID >>>>>>> only, >>>>>>> such roster items doesn't seem to make much sence. >>>>>>> >>>>>>> So, if I don't miss something, the attribute jid of a roster item >>>>>>> should >>>>>>> be a bare JID (or changed by the server to such). >>>>>>> >>>>>>> And it might be worth to mention that the change of 'to' in >>>>>>> (un)subscribes from full to bare JIDs by the server might lead to >>>>>>> error >>>>>>> stanzas where the 'from' and 'to' attributes are not only exchanged >>>>>>> (because 'to' got modified). Verbose: a presence with type >>>>>>> 'subscribe' >>>>>>> to 'user@example.com/nick' might result in a presence of type error >>>>>>> from >>>>>>> 'user@example.com' and not from 'user@example.com/nick' (e.g. with >>>>>>> remote-server-not-found) >>>>>> >>>>>> Section 3.1.1 says: >>>>>> >>>>>> A user's client generates a subscription request by sending a >>>>>> presence stanza of type "subscribe" and specifying a 'to' address of >>>>>> the potential contact's bare JID. >>>>> >>>>> I've read that and the following sections. But I've written the above >>>>> complain because nowhere in section 2 is something written about the >>>>> type of JIDs in rosters. So according to RFC 6121 it is possible to >>>>> add >>>>> a JID with a resource part to the roster, even if it doesn't make >>>>> sense, >>>>> at least not in regard to subscriptions. >>>> >>>> Yes, it is possible, but not encouraged. The reason we don't prohibit >>>> this behavior is that we don't want to unnecessarily constrain users >>>> from adding any JID to the roster or constrain applications regarding >>>> the addresses they use (e.g., a bot might be located at example.com/bot >>>> and we don't want to say that you can't add such a thing to your >>>> roster). >>> >>> That doesn't answer what a server is supposed to do with such roster >>> items (or the request to add them). Just putting them into the roster, >>> ignoring them otherwise (the subscriptions state would be always none)? >>> >>> Because I currently don't have the time to work on my server, I don't >>> know out of my memories what I've choosen to do, but I tend to just >>> forbid such requests. >> >> Postel's Law saith: "Be liberal in what you accept, conservative in what >> you send." >> >> IMHO it would be best for the server to accept such a roster item, and >> for human-oriented clients to discourage their users from sending such a >> roster item. I don't see it as the server's place to return an error >> (e.g., malformed-jid) in this case. > > Hmm, I see more problems when accepting something which can't be used > afterwards. In fact it can be used. I can add example.com/bot to my roster just fine. The roster *can* be used as an address book of sorts even without presence subscriptions. And I can have a presence subscription to that bot but not example.com. Etc. > Changing it (by the server), will end in other problems, > e.g. what happens if an item without resource already exists? I agree that we'd have problems if the server were to change it. > But regardless how it is solved, I think the best solution is to add a > sentence to the next revision or version of the RFC which remarks that > rosters with resource parts aren't functional and should not be used. ;) But they can be functional. And RFC 6121 already has text similar to what you want. If you don't like the current text, please propose revised text. Peter -- Peter Saint-Andre https://stpeter.im/ From holler@ahsoftware.de Sun Dec 18 02:43:56 2011 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD90121F84FD for ; Sun, 18 Dec 2011 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.11 X-Spam-Level: ** X-Spam-Status: No, score=2.11 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpgMYuMi7hqQ for ; Sun, 18 Dec 2011 02:43:56 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id ECBF821F84FA for ; Sun, 18 Dec 2011 02:43:55 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 2341AA8365; Sun, 18 Dec 2011 11:43:53 +0100 (CET) Received: from eiche.ahsoftware (p57B20512.dip0.t-ipconnect.de [87.178.5.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 28617A8355 for ; Sun, 18 Dec 2011 11:43:50 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 112EA3FDB3; Sun, 18 Dec 2011 11:43:47 +0100 (CET) Received: from krabat.ahsoftware (unknown [192.168.207.2]) by eiche.ahsoftware (Postfix) with ESMTP id 4AC473FCB6; Sun, 18 Dec 2011 10:43:44 +0000 (UTC) Message-ID: <4EEDC3DF.1070704@ahsoftware.de> Date: Sun, 18 Dec 2011 11:43:43 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E48177A.7060206@ahsoftware.de> <4E4E975D.1060702@stpeter.im> <4E4EAD68.5050300@ahsoftware.de> <4EE271B7.1020700@stpeter.im> <4EE47E4C.90400@ahsoftware.de> <4EEA891B.2030702@stpeter.im> <4EEAC1EB.2060006@ahsoftware.de> <4EEB6E37.5090003@stpeter.im> In-Reply-To: <4EEB6E37.5090003@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:43:56 -0000 Hello, Am 16.12.2011 17:13, schrieb Peter Saint-Andre: >> Hmm, I see more problems when accepting something which can't be used >> afterwards. > > In fact it can be used. I can add example.com/bot to my roster just > fine. The roster *can* be used as an address book of sorts even without# That should be a bookmark or whatever. > presence subscriptions. And I can have a presence subscription to that > bot but not example.com. Etc. I don't see how you can have a subscription for such a roster item. Section 3 says "the server MUST stamp the outgoing presence stanza with the bare JID" and 3.1.3 says about incoming requests "the contact's server SHOULD check the syntax of the JID contained in the 'to' attribute. If the JID is of the form instead of , the contact's server SHOULD treat it as if the request had been directed to the contact's bare JID and modify the 'to' address accordingly." and "Security Warning: Until and unless the contact approves the subscription request as described under Section 3.1.4, the contact's server MUST NOT add an item for the user to the contact's roster." 3.1.5 has a similiar text about removing the resource part. >> Changing it (by the server), will end in other problems, >> e.g. what happens if an item without resource already exists? > > I agree that we'd have problems if the server were to change it. > >> But regardless how it is solved, I think the best solution is to add a >> sentence to the next revision or version of the RFC which remarks that >> rosters with resource parts aren't functional and should not be used. ;) > > But they can be functional. And RFC 6121 already has text similar to > what you want. If you don't like the current text, please propose > revised text. Sorry, maybe I'm dumb, but I still don't see how roster items with an resource part can be functional in regard to presence (besides the usage by the client as a bookmark) and what that similiar text is. So I'm unable to propose a revised text. Regards, Alexander