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 <[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? > > 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 <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". > > 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?
