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.
Cheers,
Ben
