[Standards] Proposed XMPP Extension: Metacontacts

Ian Paterson ian.paterson at clientside.co.uk
Fri Mar 30 11:34:52 UTC 2007

Mridul wrote:
> Yes, this is indeed a problem - especially for the well known namespaces
> like bookmarks, etc which clients sometimes expect to be in sync.
> We have faced this issue in the past too w.r.t conference bookmarks.

I'm glad to hear we're fixing a real world problem.

>> PEP also allows multiple items to be published to the same node
>> (namespace) and then updated individually. Whereas, with iq:private,
>> updating a small part of the data associated with a namespace requires
>> *all* the data to be read, edited and then completely rewritten!
> Use different namespaces with a namespace hierarchy ?
> I am not sure why we need to put disjoint data within same namespace.

Well, what if there are a lot of small items, and I want to fetch all of 
them. If I give each item it's own iq:private namespace then I will have 
to generate many requests/response pairs to receive all the items. And 
how do I know the names of the namespaces (i.e. which items are 
available in cases where the names of the items are not well known)? We 
had to implement this once already, the only way was to save an index in 
a "well known" (for our client) iq:private namespace, read the index, 
and then read the data with multiple item namespace requests. This was 
very nasty, but we had no choice. PEP will solve that.

>> PEP also gives us a registry of well known nodes.
> private data is going to be specific to a application in most cases.
> So I am not sure why we would need this ...
> Typically pref's for gaim would not be useful for sun im
> client/exodus/psi/etc.
> The data which is going to be reusable is already standardized (or could
> be) like bookmarks, etc.

Yes, this is only a subtle advantage. I think XEP authors will leverage 
PEP much more than they have employed iq:private. Personally I feel the 
existance of a node registry helps encourage that. IIRC there is no one 
place where you can discover which iq:private namespaces have been 
reserved. That has left us all with the (incorrect?) feeling that 
iq:private is intended mainly for proprietary use (as you pointed out).

- Ian

More information about the Standards mailing list