On Jan 31, 2011, at 08:58 , tpatnoe wrote: > On 1/30/11 20:26, "Evgeniy Khramtsov" <[email protected]> wrote: > >> 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. > > I believe you are referring to the stanza level error "gone" in section > 8.3.3.5 of RFC-3920bis. We may be using that error too. We wanted to do > actions pro-actively before waiting for a stanza sent from a contact.
That was my thoughts; this is a good indicator to a client (or possibly that client's server). Gone has uses, but not for unsolicited notifications. We don't want clients or servers to resort to "probe polls" just to determine an account has migrated! XEP-0283 probably should include a discussion of the <gone/> error in relation to this spec. From the client's perspective, I see this as an optional extension; it lets a client "be smarter" if the implementation so chooses. Otherwise, clients do what they do today; ignore the extra info and carry on with their pre-existing subscription handling logic. The hint might also make it easier for a server to be smart on behalf of clients, although I'm not sure how comfortable I feel about that aspect. One (other) thing I think XEP-0283 needs is an informative note about old/removed accounts; something to hint to implementors/deployers that such accounts SHOULD be placed on an "off limits" list for some longish amount of time (e.g. 2-6 weeks). - m&m
smime.p7s
Description: S/MIME cryptographic signature
