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] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
Hi, 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. 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. Regards, Sachin Khandelwal Sr. Software Engineer | Mundu Sever Geodesic Limited | www.geodesic.com Tel: +91 22 4031 5815 On Wednesday 08 April 2009 03:25:24 Peter Saint-Andre wrote: On 4/7/09 3:44 PM, Peter Saint-Andre wrote: On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote: Peter, On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: I see two possible solutions: 1) Keep things like they were before, so that retrieve may return messages from one collection only. Requires rollback of the last change to XEP and removing exactmatch support by retrieve from 10.1 and from XML Schema. I now think that is the right approach. Alexander, what do you think? I think that would be both the best and the easiest solution (the rare case when these qualities do not interfere ;-) OK, good. I will update XEP-0136 accordingly Done: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diff Mode=u%40diffWrap=sr1=2993r2=3008u=3ignore=k= Peter
Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
Hi, 2Sachin: does it correspond to your suggestions? yeah, I also feel its better to have JID Matching section. Regards, Sachin Khandelwal On Wednesday 08 April 2009 14:40:24 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? 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. 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. 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. 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. 2Sachin: does it correspond to your suggestions?
Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: I see two possible solutions: 1) Keep things like they were before, so that retrieve may return messages from one collection only. Requires rollback of the last change to XEP and removing exactmatch support by retrieve from 10.1 and from XML Schema. I now think that is the right approach. Alexander, what do you think? 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/7/09 3:32 PM, Alexander Tsvyashchenko wrote: Peter, On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: I see two possible solutions: 1) Keep things like they were before, so that retrieve may return messages from one collection only. Requires rollback of the last change to XEP and removing exactmatch support by retrieve from 10.1 and from XML Schema. I now think that is the right approach. Alexander, what do you think? I think that would be both the best and the easiest solution (the rare case when these qualities do not interfere ;-) OK, good. I will update XEP-0136 accordingly and then the Council can decide whether to approve the changes. 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/7/09 3:44 PM, Peter Saint-Andre wrote: On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote: Peter, On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: I see two possible solutions: 1) Keep things like they were before, so that retrieve may return messages from one collection only. Requires rollback of the last change to XEP and removing exactmatch support by retrieve from 10.1 and from XML Schema. I now think that is the right approach. Alexander, what do you think? I think that would be both the best and the easiest solution (the rare case when these qualities do not interfere ;-) OK, good. I will update XEP-0136 accordingly Done: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u%40diffWrap=sr1=2993r2=3008u=3ignore=k= 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/6/09 12:28 AM, Alexander Tsvyashchenko wrote: Hello Peter, On Sun, 05 Apr 2009 16:24:33 -0600, Peter Saint-Andre stpe...@stpeter.im wrote: You are right -- the words participating full JID in the first paragraph of Section 7.2 unnecessarily and incorrectly limit the matching for collection retrieval. I've fixed that: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u%40diffWrap=sr1=2415r2=2993u=3ignore=k= ... in fact it seems I've managed to convince several people in the opposite already (including topic-starter) based on current XEP-136 wording ;-) See discussion starting from this comment: https://www.ndl.kiev.ua/content/modarchiveodbc-release#comment-117 Oops. The original poster was right that the following text is confusing: *** To request a page of messages from a collection the client sends a retrieve/ element. The 'with' and 'start' attributes specify the participating full JID and the start time (see XEP-0082). Both attributes MUST be included to uniquely identify a collection. In addition, the client MAY match an exact bare JID (localp...@domain.tld or domain.tld) by setting the boolean 'exactmatch' attribute to a value of true or 1 [14] -- for details, refer to the Exact JID Matching section of this document. *** There is no need for 'exactmatch' if you can specify only a full JID. I'll look at this more tomorrow... 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 12/10/08 3:28 PM, Paolo Nesti Poggi wrote: Hi, writing about XEP-0136. I't seems to me that there is an inconsistency between section 7.2 http://xmpp.org/extensions/xep-0136.html#manage-retrieve To request a page of messages from a collection the client sends a retrieve/ element. The 'with' and 'start' attributes specify the participating full JID and the start time (see XEP-0082). Both attributes MUST be included to uniquely identify a collection. That is, the participating full JID is stated here, and section 10.2 http://xmpp.org/extensions/xep-0136.html#impl-exactmatch that is referred to by the previous section: When the 'exactmatch' attribute is set to true or 1 on an element of item/, list/, remove/, or retrieve/, a 'with' value such as example.com matches that exact JID only rather than *...@example.com, *...@example.com, or example.com/* where including the element retrieve/ among those with wich the exactmatch attribute can be used seems to imply that a collection can be retrieved using only a part of the JID. You are right -- the words participating full JID in the first paragraph of Section 7.2 unnecessarily and incorrectly limit the matching for collection retrieval. I've fixed that: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u%40diffWrap=sr1=2415r2=2993u=3ignore=k= Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
