Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Hi, Addition of this feature is highly appreciated. There is a small issue which will occur in rare scenario : In sec 2.4, Example 4. Roster result with no items iq from='ro...@montague.lit' id='r1' to='ro...@montague.lit/home' type='result' query xmlns='jabber:iq:roster' ver='317' /iq The above example is for the case when server will send the individual roster pushes for the changes rather then sending the complete roster. But the server will return the same response (while returning complete roster) when user has deleted all the rosteritems present previous version (say 316). Also a minor correction is the 'query' element in the above example is not closed. Regards, Sachin Khandelwal On Thursday 09 April 2009 01:34:40 XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0237 (Roster Versioning). Abstract: This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not changed, thus saving bandwidth during session establishment. URL: http://www.xmpp.org/extensions/xep-0237.html This Last Call begins today and shall end at the close of business on 2009-04-21. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] unavailable presence from bare JID
On Thu, Apr 9, 2009 at 1:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact I suppose someday (not anytime soon!) some people might want to get rid of resource entirely, but that'll happen in XMPP 2.0 after I've retired. :) we are already discouraging them with eco xmpp :D -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] unavailable presence from bare JID
On Thu, Apr 09, 2009 at 11:25:15AM +0200, Jonathan Schleifer wrote: Am 09.04.2009 um 00:11 schrieb Justin Karneges: However, transport contacts often have no resource. These are not real logged in XMPP clients, but faked contacts from a server component. You will get presence from='screenn...@aim.transport'/ and have to deal with it. You usually get presence from screenn...@foo.transport/ - so it's not _that_ would be even worse than a bare JID, as the resource part MUST NOT be empty. A resource string is always at least 1 character long. a bare JID, but a JID with empty resource. At least, I haven't seen getting presence from a bare JID so far. Robin -- Robin Redeker | Deliantra, the free code+content MORPG el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] unavailable presence from bare JID
--- On Thu, 9/4/09, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: From: Justin Karneges justin-keyword-jabber.093...@affinix.com Subject: Re: [Standards] unavailable presence from bare JID To: XMPP Standards standards@xmpp.org Date: Thursday, 9 April, 2009, 3:41 AM On Wednesday 08 April 2009 14:30:14 Mridul Muralidharan wrote: I am not sure what an empty resource means in context of available presence from a user - since you cant bind to an empty resource for a user : so what is the user expectation on seeing something like that in psi ? No XMPP server would allow you to log in with an empty resource. However, transport contacts often have no resource. These are not real logged in XMPP clients, but faked contacts from a server component. You will get presence from='screenn...@aim.transport'/ and have to deal with it. You are right, you can/will get non-unavailable presence with from as barejid from components (and so I tried to carefully word it as user in my mail :-) ). That being said, before you receive the presence, the client would know that the bare jid corresponds to a component right ? IIRC the presence received is in response to client action (subsequent to disco, etc) - any time this is not the case ? So the split is not so much between bare jid and full jid - but between components and users. Components can have bare jid available presence, while users cant. Or did I misunderstand something ? Thanks, Mridul -Justin From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/
Re: [Standards] unavailable presence from bare JID
Robin Redeker el...@x-paste.de wrote: _that_ would be even worse than a bare JID, as the resource part MUST NOT be empty. A resource string is always at least 1 character long. I disagree. Having an empty C string as a resource is most of the time a smaller issue than having it NULL because it's missing entirely. And having an available presence from a bare JID is completely undefined, whereas from a resource is defined. So, this would be only a violation of the naming policies for resources, but not trigger undefined behaviour. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] unavailable presence from bare JID
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 09.04.2009 um 00:11 schrieb Justin Karneges: However, transport contacts often have no resource. These are not real logged in XMPP clients, but faked contacts from a server component. You will get presence from='screenn...@aim.transport'/ and have to deal with it. You usually get presence from screenn...@foo.transport/ - so it's not a bare JID, but a JID with empty resource. At least, I haven't seen getting presence from a bare JID so far. - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJJ3b77AAoJEMtRg9d5cXHkbEgP/RIYaYO1HaP7fzdtHmrHyi96 yKcF41hwEXTUqGYNGILfipRATcPcpJB7hJhQs/oi5dJeh3bEVTrBlan89CTtKhrP 7zauMP72HDUw4PQXtlsZFXgDcD9GfMzIgTVsOk3EgxexefCY8G9MphAUtp16Jusu rybb6H4Xr2OecdPgDTJTECd59DzTWCGzyujYTSKxKYV7ozRUl/pPKJnBJrXpEppo hlfSjI97WW3KH9MyK6Jlx6nWnZOtCEg6dXJ0fTIue4K5etKszVqvf9e013upMoxh JKeNr6C7ZBcaVxVWL6mv97bg55bXOAg/wP3y0lrdC31QQSdTlK2phNDnOdE7B+I4 BZLf/xgF0TGDkGEc/Q9SHH3LFhsyY+CstFatgsoF+TuQJVPYloJqIJ/hzSXO+EFp G4V1fhCILoHSq1l3D0usoYos7GiVg46l1vp9OFEGHPZYvkCnsZgE+rXOgGbsQe3R c0jkQ60aSYgELDFdomWTpb9FM1W+bPrq2HUs5vQGEquXKngkqHPt5dFZeoa4uzQ2 HJZkgxwlpMpspVTp/tzpKVf3NOpT6MmeNi9T7dvVomevDiG8vqnmhqmLFO/T5dFU cTx/xTI4vXmnDPlxbHyLFk/2P8Ffn+H5ABrRd0CaRVmpOUKtPB2eZ8a7xVGDBB9k fcTpU1sW+1Q4P0lOPWgx =MbAW -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal sac...@geodesic.com wrote: Hi, Addition of this feature is highly appreciated. There is a small issue which will occur in rare scenario : In sec 2.4, Example 4. Roster result with no items iq from='ro...@montague.lit' id='r1' to='ro...@montague.lit/home' type='result' query xmlns='jabber:iq:roster' ver='317' /iq The above example is for the case when server will send the individual roster pushes for the changes rather then sending the complete roster. But the server will return the same response (while returning complete roster) when user has deleted all the rosteritems present previous version (say 316). this-space-intentionally-left-blank/ I'm not sure that I see this as a problem. If a client requests r317 then it already knows that the contacts have been deleted, there will be no roster pushes, and there needn't be any. If it requests 316 then it can be notified of the deletion of the single contact and then upgraded to 317. Am I missing something? Matthew.
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Hi, Let me elaborate this : Consider user 'xmpp1' uses two clients to login (say one from home and one from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster version is 316. Both the office client and home client are upgraded to version 316. Now from office client user deletes the contact ( home client is not logged in that time). Now when xmpp1 login from home client the response of roster retrieval will be same as Example 4. Here my concern was how the client will come to know that the response is actually a zero rosteritem (empty roster) condition and not that the roster changes will be sent later as interim roster pushes as mentioned in sec 2.4. Also consider that the server is implemented to send the complete roster and not the interim roster pushes. Regards, Sachin Khandelwal On Thursday 09 April 2009 18:09:57 Matthew Wild wrote: On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal sac...@geodesic.com wrote: Hi, Addition of this feature is highly appreciated. There is a small issue which will occur in rare scenario : In sec 2.4, Example 4. Roster result with no items iq from='ro...@montague.lit' id='r1' to='ro...@montague.lit/home' type='result' query xmlns='jabber:iq:roster' ver='317' /iq The above example is for the case when server will send the individual roster pushes for the changes rather then sending the complete roster. But the server will return the same response (while returning complete roster) when user has deleted all the rosteritems present previous version (say 316). this-space-intentionally-left-blank/ I'm not sure that I see this as a problem. If a client requests r317 then it already knows that the contacts have been deleted, there will be no roster pushes, and there needn't be any. If it requests 316 then it can be notified of the deletion of the single contact and then upgraded to 317. Am I missing something? Matthew.
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
On Thu Apr 9 14:57:44 2009, Sachin Khandelwal wrote: Here my concern was how the client will come to know that the response is actually a zero rosteritem (empty roster) condition and not that the roster changes will be sent later as interim roster pushes as mentioned in sec 2.4. I'm not sure there is a concrete problem here without more thought, but assuming there is, I think it can be avoided by including a count in the responses, which might well be useful for debugging purposes anyway. I need to think more on this, though - which I'll do after Easter. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
On 4/9/09 7:57 AM, Sachin Khandelwal wrote: Hi, Hi. Could you please refrain from top-posting, please? :) Let me elaborate this : Consider user 'xmpp1' uses two clients to login (say one from home and one from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster version is 316. Both the office client and home client are upgraded to version 316. Now from office client user deletes the contact ( home client is not logged in that time). Now when xmpp1 login from home client the response of roster retrieval will be same as Example 4. Here my concern was how the client will come to know that the response is actually a zero rosteritem (empty roster) condition and not that the roster changes will be sent later as interim roster pushes as mentioned in sec 2.4. Also consider that the server is implemented to send the complete roster and not the interim roster pushes. That's an interesting edge case. I'm not yet sure how to solve it. You're right that with roster versioning an empty query/ element now can mean two different things. This requires further thought. Thinking out loud: perhaps if the roster is empty the server must not include the sequence number? Or some other notation that the roster is empty? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
Now I'm being bad and replying to 2 mails at once, sorry :) On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/9/09 7:57 AM, Sachin Khandelwal wrote: Let me elaborate this : Consider user 'xmpp1' uses two clients to login (say one from home and one from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster version is 316. Both the office client and home client are upgraded to version 316. Now from office client user deletes the contact ( home client is not logged in that time). Now when xmpp1 login from home client the response of roster retrieval will be same as Example 4. No, xmpp1 at home will request the version it knows about... 316. The server will reply with an empty 317, and also send a roster pushe for the removal of the 316 contact. No? Here my concern was how the client will come to know that the response is actually a zero rosteritem (empty roster) condition and not that the roster changes will be sent later as interim roster pushes as mentioned in sec 2.4. I don't think it has to know (though see above, since it I believe it *will* know). It simply presents the roster it knows about, until it receives further notice from the server (which will be the roster pushes). Also consider that the server is implemented to send the complete roster and not the interim roster pushes. That's an interesting edge case. I'm not yet sure how to solve it. You're right that with roster versioning an empty query/ element now can mean two different things. This requires further thought. I wouldn't be opposed to making an empty roster explicit, or preferably a non-empty roster explicit, e.g. some way to say updates are coming or better X updates are coming. Thinking out loud: perhaps if the roster is empty the server must not include the sequence number? Or some other notation that the roster is empty? I'm not sure I like leaving out the sequence number. An empty roster still has a version, that version needs to be known to keep track of item deletions. Matthew.
Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)
On 4/9/09 9:16 AM, Matthew Wild wrote: Now I'm being bad and replying to 2 mails at once, sorry :) On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/9/09 7:57 AM, Sachin Khandelwal wrote: Let me elaborate this : Consider user 'xmpp1' uses two clients to login (say one from home and one from office). Currently 'xmpp1' has only one rosteritem 'xmpp2' and the roster version is 316. Both the office client and home client are upgraded to version 316. Now from office client user deletes the contact ( home client is not logged in that time). Now when xmpp1 login from home client the response of roster retrieval will be same as Example 4. No, xmpp1 at home will request the version it knows about... 316. The server will reply with an empty 317, and also send a roster pushe for the removal of the 316 contact. No? I think Sachin's point is that if the server is sending complete roster (not subsequent roster pushes), then the client won't know if the empty query/ means (1) here is the complete roster but there's nothing in it (2) no changes. But I think that reasoning is not quite right. 1. xmpp1 requests 316 (which had one item in it) 2. server returns 317 with empty query element So xmpp1 knows that the roster has changed. And the change is, there's nothing in the roster. Here my concern was how the client will come to know that the response is actually a zero rosteritem (empty roster) condition and not that the roster changes will be sent later as interim roster pushes as mentioned in sec 2.4. I don't think it has to know (though see above, since it I believe it *will* know). It simply presents the roster it knows about, until it receives further notice from the server (which will be the roster pushes). Also consider that the server is implemented to send the complete roster and not the interim roster pushes. That's an interesting edge case. I'm not yet sure how to solve it. You're right that with roster versioning an empty query/ element now can mean two different things. This requires further thought. I wouldn't be opposed to making an empty roster explicit, or preferably a non-empty roster explicit, e.g. some way to say updates are coming or better X updates are coming. I suppose there would be no harm in defining a flag in the roster result that says expect roster pushes with the diff. I'm not yet sure that's needed, though. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] unavailable presence from bare JID
--- On Thu, 9/4/09, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: From: Justin Karneges justin-keyword-jabber.093...@affinix.com Subject: Re: [Standards] unavailable presence from bare JID To: XMPP Standards standards@xmpp.org Date: Thursday, 9 April, 2009, 8:30 PM On Thursday 09 April 2009 04:16:32 Mridul Muralidharan wrote: --- On Thu, 9/4/09, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: However, transport contacts often have no resource. These are not real logged in XMPP clients, but faked contacts from a server component. You will get presence from='screenn...@aim.transport'/ and have to deal with it. You are right, you can/will get non-unavailable presence with from as barejid from components (and so I tried to carefully word it as user in my mail :-) ). That being said, before you receive the presence, the client would know that the bare jid corresponds to a component right ? IIRC the presence received is in response to client action (subsequent to disco, etc) - any time this is not the case ? No, presence from contacts faked by transports is received automatically, just like with regular contacts. No client action is necessary. To get it clarified (since I am looking at client libraries right now), that is still within the component's domain right ? Not outside of it ? What I mean is : user disco's/connects to component transport.server.domain component sends back presence for us...@transport.server.domain, us...@transport.server.domain/res , etc Or do you mean something different ? So in essence, I am trying to see if a client can infer if the presence from a bare jid is coming from a component (and so handled separately) or from an xmpp user where barejid does not make sense. Thanks for clarifying. Regards, Mridul Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Re: [Standards] unavailable presence from bare JID
On 4/9/09 10:31 AM, Mridul Muralidharan wrote: So in essence, I am trying to see if a client can infer if the presence from a bare jid is coming from a component (and so handled separately) or from an xmpp user where barejid does not make sense. I don't think you can tell just from the presence. If the presence includes entity capabilities or you disco the entity then you can find out what it is. But I don't know how many gateways support disco or entity capabilities... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] unavailable presence from bare JID
On Thu, Apr 09, 2009 at 10:01:09PM +0530, Mridul Muralidharan wrote: [.snip.] To get it clarified (since I am looking at client libraries right now), that is still within the component's domain right ? Not outside of it ? What I mean is : user disco's/connects to component transport.server.domain component sends back presence for us...@transport.server.domain, us...@transport.server.domain/res , etc Or do you mean something different ? So in essence, I am trying to see if a client can infer if the presence from a bare jid is coming from a component (and so handled separately) or from an xmpp user where barejid does not make sense. If _presence_ semantics don't allow presence from bare JIDs it's wrong for components to try to fit the presence into them. I certainly don't want to build disco-hacks into presence handling just for some broken components who don't know how to gateway presence information in a well defined RFC compliant way. IMO either the RFC should specify presence from bare JIDs or components should introduce 'fake' resources. For the moment mapping presence from bare JIDs to an empty resource (resource string with length 0) is probably the best workaround a client (library) can do. And some special rules in general for bare JIDs (like unavailability from a bare JID stands for 'no resource online anymore'). Greetings, Robin -- Robin Redeker | Deliantra, the free code+content MORPG el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] unavailable presence from bare JID
I was trying to understand how current components and clients behave ... particularly since psi and others would have already faced and worked around/solved this issue. That being said, I completely agree with you - it does not really make much sense for available present from a bare jid as far as I can make out. Regards, Mridul --- On Thu, 9/4/09, Robin Redeker el...@x-paste.de wrote: From: Robin Redeker el...@x-paste.de Subject: Re: [Standards] unavailable presence from bare JID To: standards@xmpp.org Date: Thursday, 9 April, 2009, 10:42 PM On Thu, Apr 09, 2009 at 10:01:09PM +0530, Mridul Muralidharan wrote: [.snip.] To get it clarified (since I am looking at client libraries right now), that is still within the component's domain right ? Not outside of it ? What I mean is : user disco's/connects to component transport.server.domain component sends back presence for us...@transport.server.domain, us...@transport.server.domain/res , etc Or do you mean something different ? So in essence, I am trying to see if a client can infer if the presence from a bare jid is coming from a component (and so handled separately) or from an xmpp user where barejid does not make sense. If _presence_ semantics don't allow presence from bare JIDs it's wrong for components to try to fit the presence into them. I certainly don't want to build disco-hacks into presence handling just for some broken components who don't know how to gateway presence information in a well defined RFC compliant way. IMO either the RFC should specify presence from bare JIDs or components should introduce 'fake' resources. For the moment mapping presence from bare JIDs to an empty resource (resource string with length 0) is probably the best workaround a client (library) can do. And some special rules in general for bare JIDs (like unavailability from a bare JID stands for 'no resource online anymore'). Greetings, Robin -- Robin Redeker | Deliantra, the free code+content MORPG el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net http://www.ta-sa.org/ | Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Re: [Standards] unavailable presence from bare JID
On Thursday 09 April 2009 10:26:10 Mridul Muralidharan wrote: I was trying to understand how current components and clients behave ... particularly since psi and others would have already faced and worked around/solved this issue. Psi doesn't try to detect the type of contact to know if presence without a resource could happen. I'm willing to be no client does that, actually.. Besides, a transport contact could actually send a resource, and probably some of them do. I don't think it's fair to assume a transport would always send presence without a resource. So, a client has to be prepared to accept both. I don't see much point in having special handling depending on contact type. I agree with Robin, that the RFC should at least clarify what it means to have presence from no resource. Probably it should just be treated as a resource of 0-length, that does not overshadow other resources from the same bare jid. I think this would describe current practice. The alternative approach of changing all existing implementations to never send nor support presence from no resource is not practical. That ship has sailed. -Justin
Re: [Standards] unavailable presence from bare JID
On 4/9/09 11:47 AM, Justin Karneges wrote: On Thursday 09 April 2009 10:26:10 Mridul Muralidharan wrote: I was trying to understand how current components and clients behave ... particularly since psi and others would have already faced and worked around/solved this issue. Psi doesn't try to detect the type of contact to know if presence without a resource could happen. I'm willing to be no client does that, actually.. Besides, a transport contact could actually send a resource, and probably some of them do. I don't think it's fair to assume a transport would always send presence without a resource. So, a client has to be prepared to accept both. I don't see much point in having special handling depending on contact type. I agree with Robin, that the RFC should at least clarify what it means to have presence from no resource. Probably it should just be treated as a resource of 0-length, that does not overshadow other resources from the same bare jid. I think this would describe current practice. +1 The alternative approach of changing all existing implementations to never send nor support presence from no resource is not practical. That ship has sailed. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
On 4/8/09 3:10 AM, Alexander Tsvyashchenko wrote: Hello Sachin, On Wed, 8 Apr 2009 13:30:58 +0530, Sachin Khandelwal sac...@geodesic.com wrote: I feel it'll create inconsistency due to changes in section 7.1 and 7.2 . As per section sec 4.5 the with attribute can be JID (not only full jid). so due to this change, it'll not be possible retrieve the collections having with attribute as bare JID. Not directly related to this particular change, but looks like you're right that section 4.5 is a bit strange: it describes ch...@with], but talks about matching - I believe it does not make sense in this context. 2Peter: does it make sense to remove If the JID is of the form localp...@domain.tld, any resource matches; if the JID is of the form domain.tld, any node matches paragraph from 4.5, as it describes 'with' attribute of 'chat' element, not 'with' attribute of any command, so there's no matching to talk about? I don't think that's right. See these examples: http://xmpp.org/extensions/xep-0136.html#example-23 (MUC) http://xmpp.org/extensions/xep-0136.html#example-24 http://xmpp.org/extensions/xep-0136.html#example-25 This paragraph might be moved to 10.1 section, for example: probably it might be renamed from Exact JID Matching to JID Matching then and in 2.2.3.2, 7.1 and 7.3 all info about 'jid'/'with' meaning might be removed and the link to JID Matching might be just given instead (yes, I'm a real fan of DRY principle ;-) ) 7.2 will have slightly different wording (discussed below) and 2.2.3.2 (or 2.2.3?) additionally might mention that more specific JIDs settings override less specific ones. Shall I give you SVN access to the XEPs repository so that you can make proposed changes? That might be productive for all of us. Poke me on IM if you're interested. :) As for the inconsistency: yes, recent change might introduce some inconsistency, see below. One solution I think of is to keep sec 7.1 Retrieving a List of Collections as it is and for sec. 7.2 Retrieving a Collection, remove the 'exactmatch' attribute and the value of with attribute should always be exactly matched by default. Yes, I believe 'exactmatch' in '7.2' was left just by the accident and I agree the wording should be slightly adjusted also. Now I'm not so sure. See the MUC examples I noted above. 2Peter: I would suggest the following further changes (that's basically what Sachin says, I believe, just slightly more expanded): 1. Remove 'In addition, the client MAY match an exact bare JID BAREJID; by setting the boolean 'exactmatch' attribute to a value of true or 1 BOOLEANNOTE; -- for details, refer to the link url='#impl-exactmatch'Exact JID Matching/link section of this document.' paragraph from 7.2 2. Move Note: Collections are retrieved only based on the full JID ... from 7.1 to 7.2 (as it belongs there, not to the retrieving a list of collections) and rephrase it like Note: the lt;retrieve/gt; shall not possess the 'exactmatch' attribute, as exact JID matching (see the link url='#impl-exactmatch'Exact JID Matching/link section of this document) is always implied for this command. This is done to prevent returning multiple collections from the lt;retrieve/gt; command, as current wording implies that only full JIDs might be specified, but in fact we should enforce not full JIDs but exact matching. See above. If you agree on changing 10.1 to become JID Matching instead of Exact JID Matching the link and wording around it would be slightly different in (2), but the idea is the same. I'm not sure yet. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0136 - Message Archiving Preferences doubt
On 4/7/09 2:42 AM, Alexander Tsvyashchenko wrote: On Tue, 7 Apr 2009 11:50:04 +0530, Sachin Khandelwal sac...@geodesic.com wrote: snip/ Once again: the server is just storage back-end, and it does only what client told it to do. If client told the server enable auto-archiving - so be it, it's client responsibility to ensure that this command didn't violate OTR negotiation results or whatever else part of XEP-136. There's no point in server knowing about OTR and trying to enforce it when clients may easily violate it by local messages recording. Correct. 2Peter: in fact XEP-136 might be slightly confusing in its current form regarding preferences interpretation in auto-archiving mode - probably, it might be a good idea to list explicitly which preferences server takes into account when auto-archiving is enabled. I believe these are auto (per stream), defau...@expire, @save] and it...@expire, @jid, @save] in normal auto-archiving mode and no preferences are taken into account in forced auto-archiving mode. It also might be useful to explicitly state that all other preferences are for clients interpretation only. That would be helpful, yes. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0198 (Stream Management)
Version 0.8 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. Changelog: [See revision history] (ff/jk/jjh/psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u%40diffWrap=sr1=2933r2=3028u=3ignore=k= URL: http://xmpp.org/extensions/xep-0198.html
Re: [Standards] roster partial activation privacy lists
On 3/18/09 8:19 AM, Fabio Forno wrote: A quick recap about all the discussions we had since Brussels and some new thoughts on roster optimizations - Roster sequencing rocks, it should be inserted into rfc3921bis and all the world will implement it Last Call in progress. :) - Partial roster retrieval: it's not clear whether it should be just retrieval or something modifying also the behavior of presence broadcast. I'd prefer to stick it just retrieval, without affecting presence and implement it as an optional xep, letting what I call activation to a different mechanism. The main reason is that these are two different things which can be needed in different situations; partial retrieval has sever distinct use cases, which are independent from presence delivery: - just discover the groups - retrieve just a group - retrieve accordingly the subscription state (I feel this is pretty important since I don't want to retrieve 1000 contacts with subscription == none on my mobile, as it can happen if I use the roster as address book for contacts I have very infrequent communications with) - retrieve additional information bound to contacts (certificate, vcard, ...) That sounds like a reasonable approach. - About partial roster activation there are different points of view, some say it's not necessary, some is fearing a new monster like privacy lists, others say just use privacy lists! The only thing I'm sure about it is that we need it, since from few tests when I go online with my mobile (compression enabled), I get the following figures: - ~ 1.5 KB for logging in with all the stream features and sasl thing - ~ 4-5 KB for a ~ 150 contact roster - ~ 12-14 KB for the inbound presence storm, most of it completely unwanted. So we did some internal brainstorming and here is what is our implementation plan: - privacy lists have the nice feature of being there and ready, so we will use them - we don't implement them, but just use them, that's to say users will be not aware of the existence of such a baffling thing like privacy lists, we just add a group VIPs (an perhaps some other more in future) and the the user: if you want to save bits just add there all the people you want to see whether they are only or not - If the VIPs group has items we create a privacy list in which all incoming presence is blocked but that of VIPs - Before going online we set the VIPs privacy list as the active one The only problem is that if we want to probe some contacts not in them VIPs group we must either put them temporarily in the VIPs group or unset the privacy list, and I don't know if there ar workarounds for this (but a service with which we can poke the presence of somebody using an iq/ Another possible hack is to create a temp group and add/subtract people in that group (leaving VIPs alone). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0255 (Location Query)
Version 0.6 of XEP-0255 (Location Query) has been released. Abstract: This specification defines an XMPP protocol extension for querying a compliant server or service for information about the geographical or physical location of an entity. Changelog: Defined registry; added nic type from list discussion. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0255.xml?%40diffMode=u%40diffWrap=sr1=2893r2=3034u=3ignore=k= URL: http://xmpp.org/extensions/xep-0255.html
