[Standards] XEP-283

Ben Schumacher bschumac at cisco.com
Thu Feb 3 17:02:09 UTC 2011

On 1/30/11 8:26 PM, Evgeniy Khramtsov wrote:
> 31.01.2011 08:52, tpatnoe wrote:
>> Our team is starting work on using XEP-283. Has anyone else looked at 
>> this
>> and do they see any problems with the spec as it is currently written
>> (Version 1.0)?
>> http://xmpp.org/extensions/xep-0283.html
>> One item which came up in our discussion, is linking an unsubscribe 
>> from an
>> old JID to a new subscribe from the new JID with a token. However, we
>> decided that just including the new JID in the unsubscribe from the 
>> old JID,
>> and the old JID in a subscribe from the new JID were enough. A token
>> provided no more assurance of authenticity.
> What I really don't like in this XEP is that it contradicts the idea 
> of "keep clients simple". I think we can do the same using server-side 
> redirects (we have such error type already defined in the core RFC). 
> In that case a client just need to set a redirect and his/her contacts 
> should process presence redirects correctly. Also, redirects can be 
> used for temporary migration and not only for account removal.

Attempting to "keep clients simple" shouldn't come before all other 
considerations. In this case I believe that using a redirect so greatly 
complicates the security model (not to mention the server 
implementation) that it's necessary to have some work on both sides. 
There is a widely held belief among protocol snobs that the email 
system's flexibility in this regard leads to a lot of the exploits that 
have made it so ripe for abuse.

Being able to balance the work between the server and the client for 
XEP-283 means a user still has the ability to maintain their 
subscriptions while changing their username but is flexible and scalable 
enough to work in a globally federated environment and still gives the 
individual the opportunity to review any action before it is taken.


More information about the Standards mailing list