[Standards] vCard4: IQ vs. PEP
waqas20 at gmail.com
Wed Apr 6 19:49:18 UTC 2011
On Thu, Apr 7, 2011 at 12:13 AM, Dave Cridland <dave at cridland.net> wrote:
> On Wed Apr 6 19:55:17 2011, Waqas Hussain wrote:
>> Also, PEP in MUC is not a solved problem. I do like avatars in MUC.
> I'd note that in Belgium, the consensus seemed to be to solve that problem
> rather than continue to work around it. Additionally, a recall the consensus
> as being to deprecate vcard4-for-avatars in favour of XEP-0084.
+1 to solving that problem.
XEP-0084's way is sensible. It does have issues though, described later.
Aside: I note XEP-0084 has an example with an avatar posted at a HTTP
URL. XEP-0153 explicitly said "The <PHOTO/> element SHOULD NOT contain
an <EXTVAL/> that points to a URI for the image file." Has our stand
on the data leak changed?
>> All that said, I would really really love to have a generic framework
>> to do for PEP and pubsub and disco and everything what we currently do
>> for avatars via hash in presence. We added hashes in presence to avoid
>> iq:avatar, iq:disco and iq:version floods on login. When we start
>> having large data in PEP/PubSub, PEP floods are going to become a
>> serious problem.
>> One obvious solution is a 'hashes' node in PEP. You subscribe to that,
>> and you get hash updates. A hash update is a set of hashes for avatar,
>> versions, custom namespace, etc. You send a manual request for what
>> you want to actually get, and cache the result for the future. It
>> would be nice to have this also requestable via IQ (possibly a pubsub
> Perhaps a subscription option?
> We treat PEP's auto-subscribe from the bare jid, plus filtered
> notifications, as an auto-subscribe from each full-jid, incidentally, which
> makes this easier (if semantically wrong), but if these subscriptions could
> (by dint of an additional disco#info feature advertised via caps) indicate
> that a they only wishes to receive a hash of the last item on subscribe,
> that might work.
What's the hashing function? We don't have a standardized hashing
function for arbitrary XML payloads in the XMPP community.
Perhaps id of the last item would work.
> But I suspect it places us into a canonicalization trap, and in any case it
> will increase, not decrease, the number of stanzas.
> Alternatives are to send a timestamp with initial presence - possibly
> managed by the server on a per contact basis to mitigate the privacy issues.
Unless you send a per-PEP-node-per-contact timestamp, you get issues
where you miss one update, and never know of it until the next change,
and/or get a lot more updates than you need.
(I note, timestamp here can be replaced by id or hash)
More information about the Standards