On 4/8/09 3:10 AM, Alexander Tsvyashchenko wrote: > Hello Sachin, > > On Wed, 8 Apr 2009 13:30:58 +0530, Sachin Khandelwal <[email protected]> > 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 > <[email protected]>, 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 <retrieve/> 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 <retrieve/> 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
