[Standards] NEW: XEP-0291 (Service Delegation)

David Ammouial da at weeno.net
Thu Jan 27 04:56:14 UTC 2011


(First of all, sorry if I'm not answering in the proper place. The
'Discussion venue' section of the XEP makes me think I am, though.)

27/01/11, XMPP Extensions Editor:
> Version 0.1 of XEP-0291 (Service Delegation) has been released.
> Abstract: This specification defines an approach for users to
> delegate certain services (e.g. pubsub) to alternative JIDs.
> Changelog: Initial published version. (psa)
> URL: http://xmpp.org/extensions/xep-0291.html

I see the use case that this XEP addresses as an equivalent of HTTP
301 and 302 return codes.

As such, I'm not sure that asking and receiving the whole list of
delegations of a given entity is the right way to go, or at least the
most sensible one. If you want to, say, play chess with someone, you
don't really care about their pubsub service, or the other 50 services
they're announcing delegation for. And caching is not an answer,
because it puts the complexity on the client's side.

This approach also only works well if the list of delegated services
doesn't grow too much, which means it's not scalable. Also, it's a bad
thing for mobile or generally low-bandwith devices. We don't want to
have to "fix" this XEP in 3 years with a "delegation list versioning"

Do you ask an HTTP server about all redirected URLs, cache that answer,
and the check that list against any URL you want to fetch?

Instead, I would say that the "regular" use case is that you try to
play chess with someone, and receive an answer that says "please talk
to JID xxx for that".

I might have overlooked something obvious though.

What do you think?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110126/07dfc072/attachment.sig>

More information about the Standards mailing list