[Standards] Proposed XMPP Extension: Metacontacts

Joe Hildebrand hildjj at gmail.com
Wed Mar 28 20:03:28 UTC 2007

On Mar 28, 2007, at 11:56 AM, Yann Le Boulanger wrote:

> Joe Hildebrand wrote:
>> I like this a lot.  Really funny Office Space references.  I can  
>> think
>> of a couple of quick additions:
>> - (nit) In section 5, each of the sections should specify a re-iqset
>> after the modification is made.
> I don't understand :/

I would re-write section 5 like this:

5.1 Creating a metacontact

To create a new metacontact, add a meta element with a new tag  
attribute to the list from the appropriate account, then re-submit  
the list to that account by sending an IQ set.

>> - Would a syntax like this be easier for people to deal with?
>> <iq type='result' id='get1'>
>>   <query xmlns='jabber:iq:private'>
>>     <storage xmlns='storage:metacontacts'>
>>       <meta tag='ae18f2'>
>>         <jid order='1'>mike.bolton at raplovers.org</jid>
> I don't think it's easier, cause this is multi-account. so you still
> have to parse answer from several accounts.

This is functionally equivalent to what you propose, but does not  
require repetition of the tag attribute nor a grouping operation on  
behalf of the receiver before processing.  As such, I like it better,  
but that's mostly a matter of aesthetics.

>> - It might be nice to include some hints for clients to help deal  
>> with
>> out-of-sync lists on different accounts.  For example, a timestamp:

> There can't be out-of-sync lists: on each server you store data  
> only for
> contacts in this server. This way data are not duplicated, and you  
> don't
> put a part of your contact list on another server (privacy issue).

I'm worried about two resources for the same account.  I see your  
point, however.  Timestamps won't help that, but something that did  
notifications on change would.  Maybe "use PEP if it exists,  
otherwise fall back on private and hope for the best, but beware of  
this potential issue"?

Perhaps there needs to be more text in the XEP about why conflicts  
don't happen; reading more carefully I see it, but more explicit  
would be nice.

More information about the Standards mailing list