[Standards] XEP-136 and XEP-59 implementation comments: threading
stpeter at stpeter.im
Sun May 11 04:40:15 UTC 2008
On 05/10/2008 1:03 AM, Alexander Tsvyashchenko wrote:
> Hello Peter,
>>> 1) JIDs matching: the conclusion seemd to be to use 'exactMatch'
>>> attribute (?), but as you've pointed out this is the problem not only
>>> for XEP-136.
>> I added that:
> Ah, sorry - it seems I missed that :-(
> Some comments then ;-)
>> If the client or server wishes to match an exact bare JID, the boolean
>> 'exactmatch' attribute MUST be included and MUST be set yo "true" or
>> "0" .
> 1) I think there is a typo, last phrase should read as "true" or "1".
> 2) I would not restrict it to bare JIDs: instead it seems to me more
> logical to write smth similar to "if the client or server wishes to
> match an exact bare JID or domain JID,
Right, I'll clarify that.
> the boolean 'exactmatch'
> attribute MUST be included and MUST be set yo "true" or "1", thus JIDs
> like example.com matching exactly example.com instead of
> *@example.com/*, and JIDs like user at example.com matching exactly
> user at example.com instead of user at example.com/*" - the latter one may be
> important as some collections may be recorded with bare JIDs like
> user at example.com, so we might need to access them somehow.
> 3) 'exactmatch' is currently present only in 'chat' element: however, it
> doesn't look like it belongs there, as 'chat' element is in fact not
> used for matching.
Isn't it? It is used to specify the JID with whom you have been chatting
(via the 'with' attribute).
> Instead, it should belong to commands description
> (such as 'remove' or 'list' elements) and in preferences (such as 'item'
Yes, I think <remove/> and <list/> make sense. I'm not so sure about
<item/> because I don't think that is used for any wildcards.
> Maybe it should be specified in some separate sub-section that
> 'exactmatch' attribute may be present in every element where JID is
> included and 'matching' makes sence?
Maybe -- I'll look at that soon.
> 4) XML Schema probably should be updated too?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards