XEP-xxxx: Moved 2.0

Abstract
This specification details a way for a user to notify their contacts about an account move.
Author
Matthew Wild
Copyright
© 2021 – 2021 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

ProtoXEP

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <https://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Type
Standards Track
Version
0.0.1 (2021-06-05)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

This document introduces a way for a user to notify contacts of a change to their JID, e.g. if they move to a new server.

2. Requirements

This document aims to satisfy the following requirements:

3. Glossary

Moved notification
An XML <moved/> element sent to a contact to inform them that the user is moving to a new address.
Moved statement
An XML <moved/> element published by the user on their old account. It is used by contacts to verify that moved notifications are genuine.

4. Use Cases

We start with the situation where the user, let's call them Juliet, has two accounts - her original account juliet@im.example.net and a shiny new account on her personal domain, juliet@capulet.example.

Juliet would like to migrate all her data and contacts to her new account, with minimal disruption.

4.1 User publishes moved statement

Before notifying contacts of the move, Juliet must connect to her old account and publish a "statement" that the account is no longer in use. This statement includes the address of her new account.

The statement should be posted to a PEP node with the name 'urn:xmpp:moved:1'. The payload should be a <moved/> element in the 'urn:xmpp:moved:1' namespace. This element should in turn contain a single <new-jid/> element with the user's new JID as its text content.

Example 1. Juliet's client publishes a moved statement on her old account
<iq from='juliet@im.example.net/VR0sAGae'
    type='set'
    id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:moved:1'>
      <item id='current'>
        <moved xmlns='urn:xmpp:moved:1'>
          <new-jid>juliet@capulet.example</new-jid>
        </moved>
      </item>
    </publish>
  </pubsub>
</iq>

4.2 User notifies contacts of move

After publishing a moved statement on her old account, Juliet proceeds to notify her contacts about the move.

Juliet connects to her new account, and sends a subscription request to each of her contacts. These subscription requests MUST contain a <moved/> element in the 'urn:xmpp:moved:1' namespace. This element contains a single <old-jid/> element with the old JID as its text content.>

Example 2. Juliet sends a subscription request to Romeo from her new account
<presence type='subscribe' to='romeo@montague.example' id='sub1'>
  <moved xmlns='urn:xmpp:moved:1'>
    <old-jid>juliet@im.example.net</old-jid>
  </moved>
</presence>

4.3 Contact receives subscription request with moved notification

Juliet's contact, Romeo, receives the subscription request from Juliet's new JID. At this point Romeo has not verified that the new account actually belongs to Juliet, and MUST perform such verification before acting on the request any differently to usual.

If the value of <old-jid/> is not in the roster with an approved incoming subscription ('from' or 'both'), the <moved/> element MUST be ignored entirely.

To verify the request, Romeo makes a request to the JID specified in <old-jid/> (which MUST be a bare JID) to fetch a published move statement.

Example 3. Romeo requests a moved statement from Juliet's old account
<iq type='get'
    from='romeo@capulet.example/laptop'
    to='juliet@im.example.net'
    id='83hKgF'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:moved:1'>
      <item id='current'/>
    </items>
  </pubsub>
</iq>

On success, Juliet's server will return the moved statement that Juliet published.

Example 4. Juliet's old server returns the published moved statement to Romeo
<iq type='result'
    from='juliet@im.example.net'
    to='romeo@capulet.example/laptop'
    id='83hKgF'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:moved:1'>
      <item id='current'>
        <moved xmlns='urn:xmpp:moved:1'>
          <new-jid>juliet@capulet.example</new-jid>
        </moved>
      </item>
    </items>
  </pubsub>
</iq>

Romeo MUST now verify that the received subscription request was from the same bare JID contained in the <new-jid/> element in the moved statement. If the JIDs do not match, or if there was an error fetching the moved statement (except for "gone" - see note below), the <moved/> element in the incoming subscription request MUST be ignored entirely.

Note: As a special case, if the attempt to retrieve the moved statement results in an error with the <gone/> condition as defined in RFC 6120, and that <gone/> element contains a valid XMPP URI (e.g. xmpp:user@example.com), then the error response MUST be handled equivalent to a <moved/> statement containing a <new-jid/> element with the JID provided in the URI (e.g. user@example.com).

Upon successful verification, Romeo's client may present an appropriate user interface, informing about Juliet's change of address, and a prompt to accept the subscription request from the new address. On the user's approval of such a subscription request, the client will typically want to also send a subscription request to the contact's new JID to establish a mutual subscription.

Due to the potential for races between multiple clients connected to the same account, it is NOT RECOMMENDED for a client to automatically act upon migration notifications, but instead await manual interaction from the user. As with any inbound subscription request it SHOULD pay attention to roster pushes related to the contact, and update the UI appropriately if the new contact address is authorized from another device.

4.4 Server-side processing of inbound moved notification

It is not required for Romeo's server to support this specification. However if Romeo's server does understand this extension, it SHOULD handle the inbound subscription request on behalf of Romeo's clients. This improves the user experience for Romeo, especially when he has multiple devices.

Broadly the server should follow exactly the same process as a client would. Specifically:

  1. Receive subscription request with 'moved' payload.
  2. Verify that the old JID has an approved subscription to the user (i.e. a subscription of 'both' or 'from').
  3. Request moved statement from the old account JID.
  4. Verify that the new JID in the moved statement matches the 'from' of the subscription request.
Example 5. Romeo's server requests a moved statement from Juliet's old account
<iq type='get'
    from='romeo@capulet.example'
    to='juliet@im.example.net'
    id='83hKgF'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:moved:1'>
      <item id='current'/>
    </items>
  </pubsub>
</iq>
Example 6. Juliet's old server returns the published moved statement to Romeo's server
<iq type='result'
    from='juliet@im.example.net'
    to='romeo@capulet.example/laptop'
    id='83hKgF'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:moved:1'>
      <item id='current'>
        <moved xmlns='urn:xmpp:moved:1'>
          <new-jid>juliet@capulet.example</new-jid>
        </moved>
      </item>
    </items>
  </pubsub>
</iq>

If verification fails (e.g. due to a missing or incorrect moved statement), the server MUST ignore the <moved/> element in the subscription request, and process the stanza as a normal subscription request. It MUST NOT strip the <moved/> element before forwarding, even if verification fails.

Upon successful verification, the server MUST NOT forward the stanza to Romeo's clients, but instead MUST create a roster entry for the new JID with a subscription of 'from' (sending out the appropriate roster push), and then auto-reply to the subscription request with a presence of type 'subscribed'.

Example 7. Romeo's server notifies Romeo about the new roster entry
<iq id='a78b4q6ha463'
    to='romeo@montague.example/orchard'
    type='set'>
  <query xmlns='jabber:iq:roster'>
    <item jid='juliet@capulet.example''
          subscription='from'/>
  </query>
</iq>

After authorizing the new JID, the server should revoke the presence subscription of the old account.

Example 8. Romeo's server notifies Juliet's old account about unsubscription
<presence to='juliet@im.example.net' type='unsubscribed'/>
Example 9. Romeo's server notifies Romeo's clients about the old roster entry
<iq id='a78b4q6ha463'
    to='romeo@montague.example/orchard'
    type='set'>
  <query xmlns='jabber:iq:roster'>
    <item jid='juliet@im.example.net''
          subscription='to'/>
  </query>
</iq>

Finally, if the old JID was in the user's roster with a subscription of 'both', the server MUST also send a presence of type 'subscribe' to the new JID in order to seek establishment of a mutual subscription.

Example 10. Romeo's server sends subscription request to Juliet's new JID
<presence type='subscribe' id='uc51xs63' from='romeo@montague.example' to='juliet@capulet.example'/>

5. Implementation Notes

5.1 Lifetime of moved statement

The moved statement is required for contacts to automatically verify the authenticity of moved notifications. After publishing a moved statement, the user should keep the statement published and the account active for long enough for contacts to switch to the user's new account.

It is not necessary to remain connected to the old account during the transition period. However the account must not be deleted, and the server must be available.

In the event that the move statement is unpublished, the account is deleted, or the server becomes unavailable, any contacts that have not yet transitioned to the user's new JID will be unable to verify the migration. Those contacts will have to manually approve the subscription from the user's new address.

Migration progress of contacts is obervable through subscription revocations to the old account, and subscription approvals to the new account.

5.2 Alternative verification methods

Future revisions of this document, or alternative documents, may define alternative verification methods. Such methods SHOULD be communicated via child elements of <moved/> in an appropriate namespace. As is usual throughout XMPP, entities MUST ignore unknown child elements of <moved/> in unrecognised namespaces.

6. Security Considerations

6.1 User considerations

The following are considerations for the user (exemplified by Juliet in this document):

6.2 Contact considerations

The following are considerations for the contact (exemplified by Romeo in this document), and the contact's server:

7. IANA Considerations

None.

8. XMPP Registrar Considerations

This specification defines the following XML namespace:

9. Design Considerations

9.1 Verification methods

There are two general approaches for verification - network-based verification, or cryptographic verification. Network-based verification (as described in this document) requests a verification statement from the user's old account. Cryptographic verification would check a move notification against a previously-established cryptographic identify of the user.

Network-based verification:

Cryptographic verification:

Ultimately this document defines a network-based verification method, but leaves an obvious path to extend the protocol with alternative verification methods (either in an update to this document, or defined by other documents).

10. XML Schema

TODO.

11. Acknowledgements

Many thanks to Kim Alvefur, Maxime Buquet and Jonas Schäfer for their input and feedback on this specification.


Appendices

Appendix A: Document Information

Series
XEP
Number
xxxx
Publisher
XMPP Standards Foundation
Status
ProtoXEP
Type
Standards Track
Version
0.0.1
Last Updated
2021-06-05
Approving Body
XMPP Council
Dependencies
XMPP Core, XMPP IM, XEP-0163
Supersedes
None
Superseded By
None
Short Name
NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information

Matthew Wild
Email
mwild1@gmail.com
JabberID
me@matthewwild.co.uk

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2021-06-05)

    First draft.

    mw

Appendix I: Bib(La)TeX Entry

@report{wild2021xepxxxx,
  title = {Moved 2.0},
  author = {Wild, Matthew},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2021-06-05/2021-06-05},
}

END