Subject: [xmpp] 3921bis: redirect on probe

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 22:38:29 -0700

At the XMPP Summit last week, we discussed the handling of moved
accounts. Here's what we came up with:

1. Contact's server sends probe to old JID.

<presence from=[email-masked]' id='foo' to=[email-masked]'
type='probe'/>

2. User's server returns redirect error.

<presence from=[email-masked]' id='foo' to='contact' type='error'>
  <error type='modify'>
    <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      xmpp:[email-masked]
    </redirect>
  </error>
</presence>

3. Optionally, upon receiving the redirect the contact's server could
add the user's new JID to the contact's roster with type='subscribed'
(thereby pre-authorizing a subscription request from the new jid).

4. If the user's new JID is on the same service as the old JID, the
service could do some other user-friendly things -- also do the
'subscribed' trick upon receiving the probe and perhaps even returning a
redirect error to the user when the user sends available presence to the
old JID (or during the authentication phase). We did not define such
flows at all but they are probably worth discussing.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jack Moffitt <[email-masked]>
Date: Tue, 16 Feb 2010 22:47:46 -0700

>    <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>

<redirect> is good, because I think it will be generally useful beyond
the primary use case that was discussed in Brussels - people changing
their JIDs because of marriage, new job, etc.

However, I think we need to be more specific for that use case, and
copy HTTP's 301/302 errors. I dont' think we need both temporary and
permanent moved, so I suggest we add <redirect> and <moved> both.

For example. I might redirect a request to avoid service outage
temporarily, but if I change JIDs, the change is permanent and should
cause stored pointers to update, etc.

jack.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 22:57:06 -0700

> cause stored pointers to update, etc.

RFC 3920 and rfc3920bis have <redirect/> (temporary) and <gone/>
(permanent), so we can use those.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 17 Feb 2010 23:35:11 +0900

Hi,

answers below.

On 2/17/10, Peter Saint-Andre <[email-masked]> wrote:
> [...]

If only one side does this (the contact's server, but not the new
user's server, for instance), it may create issue of not-synchronized
rosters (the contact's server consider that one is subscribed to the
user's presence whereas the new user's server "thinks" the opposite).
So I think if the contact's server does such an optional action, it
should "ask" if it is OK to the user's server in order to keep
synchronized data.

> flows at all but they are probably worth discussing.

It is obviously easier if the new JID is on the same service than on
the old, but I think this should also work if you change service. For
this there should be a discussion between the old and the new service,
once you tell your old service that you "move". Then the old service
can contact the new service and tell «hey "oldjid" user moved to
"newjid" at your place». Of course the user must also tell the new
service that this is true (if not it would be too easy for a fake XMPP
service to add contacts to your roster, thus forcing subscriptions).
Then once both service knows that this jid change is legitimate, they
can safely exchange the rosters (only for the permanently "moved"
case, not the temporary "redirect") so that you don't have to make all
subscriptions again! (and point 3 takes care of adding your new jid to
your contacts' rosters as well)

In fact you could go further, for instance if both services were
supporting the message archiving, they could negotiate to transfer the
archives so that you may still consult them, and other things as well,
like ownership on pubsub nodes, PEP nodes, ownerships and rights on
MUC, etc. Everything which is linked to a JID in fact. Of course there
should be a IQ negotiation between services for this, first, in order
to transfer only what the new service supports (and what can transfer
the old service).

Anyway I think such a feature would be a great improvement.
Bye.

Jehan

---

From: Fabio Forno <[email-masked]>
Date: Wed, 17 Feb 2010 16:13:46 +0100

>    <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>

I do like it, just wondering if it's needed only with probes, but I'm
99% sure it's ok.

-- 
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Feb 2010 08:16:00 -0700

> I do like it, just wondering if it's needed only with probes, but I'm

As Jack noted, we need to use <gone/>, not <redirect/>. Do you think it
would be used for things other than probe? (e.g., presence notification)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Maciek Niedzielski <[email-masked]>
Date: Wed, 17 Feb 2010 16:26:11 +0100

> I do like it, just wondering if it's needed only with probes, but I'm

It could make sense to do this for messages, too.
Maybe I found your old JID somewhere and tried sending a message without
adding you to my roster?
On the other hand, maybe you don't want to tell your new JID to anyone
who knew your old JID.

BTW: What if I sent you a probe and I am not in your roster? Would I
then get the information about your new JID, too? Maybe this should be
user-configurable? (some people may want everyone to find their new JID,
other might have change JID because too many people contact them)

-- 
Maciek
 xmpp:[email-masked]

---

From: Fabio Forno <[email-masked]>
Date: Wed, 17 Feb 2010 16:27:33 +0100

On Wed, Feb 17, 2010 at 4:16 PM, Peter Saint-Andre <[email-masked]> wrote:
> As Jack noted, we need to use <gone/>, not <redirect/>.

Yep, read

> Do you think it

No, if the error presence is delivered to the client too.  I've just
raised the interrupt in order to have more minds thinking about it
since I've never had a full vision about actual probe usage (I send
probes only from components and gateways, when they initially go
online, but I don't know if all servers send probes when a user goes
online, or they just dispatch the online presence stanza)

-- 
ff

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 18 Feb 2010 01:21:51 +0900

Hi,

> On the other hand, maybe you don't want to tell your new JID to anyone

I guess that maybe it should be a case by case. Then the best way may
be that instead of answering to the message telling that the user has
moved, the server may forward the message to the new JID, adding the
precision that it arrived to the old JID (then it is up to the user to
answer and tell one's JID has changed... if wanted, ignore the message
otherwise).

Or maybe, as you propose below, it can be configurable when the user
aknowledge one's old server that one moves. It could be interesting to
be able to make rules for how the old server must treat stanzas coming
to the old JID, and depending or not whether they are in the roster:
for instance advertising your new JID in answer to any stanza from
someone in your roster, but drop the rest. Or simply forward stanzas.
Etc.

> other might have change JID because too many people contact them)

As you propose, for this case too, a configurable "move" could be a
good idea. But in any case, if this is not configurable (or as a
default, if it is), I think that the server should not aknowledge a
JID which you do not have in your roster, with your new JID.

Bye.

Jehan

> --
> Maciek
>  xmpp:[email-masked]
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Adrian Hornsby <[email-masked]>
Date: Thu, 18 Feb 2010 10:20:55 +0200

Hi, 
Sorry to take this on the fly ..

> someone in your roster, but drop the rest. Or simply forward stanzas.

This is a good idea. I see two cases that need to be considered: 
1- the user changes its JID and wants its old account to 'die out". The server should then simply answer to a contact that the JID is unknown and the server might send a message to the user' s new JID to inform an old contact tried to message on his old JID. The user is then given the choice to inform the change of JID to the contact. 
2- change of job, address forwarding type of things (migration to new server): for a period of time, message to the old JID are forwarded to the new JID. Of course, it should remain more or less configurable. 
3- more ?

bye

Adrian

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 18 Feb 2010 19:44:28 +0900

Hi,

On 2/18/10, Adrian Hornsby <[email-masked]> wrote:
> 1- the user changes its JID and wants its old account to 'die out". The
> server should then simply answer to a contact that the JID is unknown and
> the server might send a message to the user' s new JID to inform an old
> contact tried to message on his old JID. The user is then given the choice
> to inform the change of JID to the contact.
> 2- change of job, address forwarding type of things (migration to new
> server): for a period of time, message to the old JID are forwarded to the
> new JID. Of course, it should remain more or less configurable.
> 3- more ?
>
> bye
>
> Adrian
>

I think there are many more cases because each person may have a
different desire on how he wants incoming messages to the old JID to
be addressed (some may just don't care about anything out of his
roster, and ask to drop it; some may want to forward; some think it is
easier to answer automatically everyone the new JID, even out of
roster, etc.), so the best for such a feature would be to make it
configurable, but with well thought default values (I imagine a good
default would be to answer with the new JID to roster's contacts, and
to forward for the rest. But maybe a "drop the rest" is better
default, for instance if someone changes JID because he receives too
many spams from out of one's roster).

Then the recommandation may be that an acceptable partial
implementation is to implement a non-customizable move feature with
the default configuration, and a perfect implementation is to make it
fully customizable.

Note that someone may want an old JID to really die (completely, does
not care about forwarding or advertizing anyone) then he can just
erase one's account without configuring any "move" feature.
Bye.

Jehan

---

From: Adrian Hornsby <[email-masked]>
Date: Thu, 18 Feb 2010 10:14:43 +0200

Hi, 

bye

Adrian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 22:15:34 -0700

> should "ask" if it is OK to the user's server in order to keep

Sorry, I mis-communicated. I add you to my roster with ask='subscribed'
(not type='subscribed') so that when you send me a subscription request
my server can automatically approve it.

> the old, but I think this should also work if you change service. 

I envision this only for the same service, and only for cases that are
service-initiated -- someone gets married or otherwise changes their
name, the entire service moves from foo.example.com to bar.example.com,
that kind of thing.

> For

Naturally.

> to transfer only what the new service supports (and what can transfer

Sheesh, such complexities! If you want to define protocols for all that,
feel free, but it'll have to be an XMPP extension, not part of rfc3921bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 22:16:50 -0700

On 2/17/10 8:26 AM, Maciek Niedzielski wrote:
> then get the information about your new JID, too? 

IMHO normal probe rules apply, so I don't think you'd get to discover my
new JID this way.

> Maybe this should be

What users want to configure this?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/