XEP-0376: Pubsub Account Management

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

1. Introduction
2. User Stories
    2.1. Device Agility
    2.2. New Devices
    2.3. Offline Capability
    2.4. PEP
3. Protocol
    3.1. Advertising Support
    3.2. Subscribing
    3.3. Unsubscribing
    3.4. Listing Subscriptions
    3.5. Auto Subscriptions
    3.6. Filtering
    3.7. Interaction with MAM
4. Security Considerations
5. XMPP Registrar Considerations
6. IANA Considerations

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

The XMPP way is to have "disposable", or at least easily substituted, clients, maintaining long-term state on the server, and allowing it to be synchronized between clients. In particular, this can be seen on how the roster and presence fan-out operate - clients defer the operation of such things to the server, which manages the shared state and allows servers to access and manipulate it.

Historically, however, we have not done this for some more recently services, including Multi User Chat and PubSub. In both cases, different clients may be unaware of what chatrooms (etc) are joined (etc) by which other clients. This causes practical difficulty in seamlessly switching between devices and/or clients.

2. User Stories

2.1 Device Agility

When a user subscribes to a publish-subscribe node (presumably via some higher-level abstraction), other online devices are aware of the new subscription immediately, and can choose to reflect the new subscription in their UI.
Not all devices may be capable of handling the particular payload and/or service, and therefore should signal which payload and/or service types they support.
The same capability as point 1 should be possible for unsubscribing.

2.2 New Devices

When a user brings a new device online, it should be able to quickly learn all the user's current subscriptions and present them to the user in its UI.

2.3 Offline Capability

When the device is offline for an extended period (beyond XEP-0198 resumption capability), it needs to be able to obtain all the events it missed, including when the events occured.
It should be able to tell which of these the user is unlikely to have seen on other devices.
Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.

2.4 PEP

A one-way subscription to a user should still allow PEP.
PEP should work the same way as now - users see filtered notifications about the things they care about.

3. Protocol

3.1 Advertising Support

Clients need to include a capability in Disco. Probably.

Servers need to advertise capability against account.

3.2 Subscribing

Clients use a modified XEP-0060 Subscribe with a newly added "jid" attribute? Presumably this may need to be in a distinct namespace.

It is tempted to suggest that all pubsub operations might be contained within a new namespace with the additional jid attribute, as they can be forwarded verbatim as required.

Servers use traditional XEP-0060 subscribes, but sent from the bare jid of the account.

Servers MUST send a Thing to indicate the new subscription to all clients capable of this protocol.

3.3 Unsubscribing

As above.

3.4 Listing Subscriptions

XEP-0237 FTW. Needs a new construct, since the subscriptions element in XEP-0060§5.6 will only list the user's local subscriptions (ie, to their PEP nodes). Maybe just the new namespace defaults to everything instead? But we'd still need the XEP-0237 model.

3.5 Auto Subscriptions

Servers need to subscribe to remote PEP services explicitly those nodes which are of interest. Interest needs to be detirmined by the client issuing a request; but this implies that servers would gradually acrue any node type which the user has had a capable client at any time.

Perhaps timing out node types which have not been requested for over a certain period?

Clients can use +notify to handle auto-subscriptions between clients and their server.

Servers receiving +notify from accounts known to support this protocol ignore them.

3.6 Filtering

Clients filter subscriptions using a specific stanza (iq, probably), containing a list of node names. This can be used instead of the odler +notify (which is broadcast).

3.7 Interaction with MAM

We probably want to say that events are now archived by MAM, but this may imply that clients need to filter out such events (or explicitly include them). Maybe the mask above affects MAM queries?

4. Security Considerations

I have literally no idea. I don't think anything new is introduced that couldn't be discovered by traffic monitoring, although it collects and collates information that previously would not have been so readily available.

5. XMPP Registrar Considerations

On publication of this specification, the XMPP Registrar will dance a little jig to the tune of the traditional hornpipe with a tea-cosy upon his or her head.

6. IANA Considerations

Appendices

Appendix A: Document Information

Series: XEP
Number: 0376
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1.0
Last Updated: 2016-05-20
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0060
Supersedes: None
Superseded By: None
Short Name: pam
Source Control: HTML
This document in other formats: XML PDF

Appendix B: Author Information

Dave Cridland

Email: dave.cridland@surevine.com
JabberID: dave.cridland@surevine.com

Appendix C: Legal Notices

Copyright

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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

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.

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".

Abstract:	This specification describes a new model for handling remote pubsub services and a protocol for doing so.
Author:	Dave Cridland
Copyright:	© 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:	Experimental
Type:	Standards Track
Version:	0.1.0
Last Updated:	2016-05-20