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
>> and do they see any problems with the spec as it is currently written
>> (Version 1.0)?
>> 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