xeps/pubsub-account.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Account-Mediated Pubsub</title>
  <abstract>This specification describes a new model for handling remote pubsub services and a protocol for doing so.</abstract>
  &LEGALNOTICE;
  <number>xxxx</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0060</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  <author>
    <firstname>Dave</firstname>
    <surname>Cridland</surname>
    <email>dave.cridland@surevine.com</email>
    <jid>dave.cridland@surevine.com</jid>
  </author>
  <revision>
    <version>0.0.1</version>
    <date>2015-10-15</date>
    <initials>dwd</initials>
    <remark><p>initial version</p></remark>
  </revision>
</header>
<section1 topic='Introduction'>
  <p>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.</p>
  <p>Historically, however, we hav enot 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.</p>
</section1>
<section1 topic='User Stories' anchor='stories'>
  <section2 topic='Device Agility'>
    <p><ul>
      <li>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.</li>
      <li>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.</li>
      <li>The same capability as point 1 should be possible for unsubscribing.</li>
    </ul></p>
  </section2>
  <section2 topic='New Devices'>
    <p><ul>
      <li>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.</li>
    </ul></p>
  </section2>
  <section2 topic='Offline Capability'>
    <p><ul>
      <li>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.</li>
      <li>It should be able to tell which of these the user is unlikely to have seen on other devices.</li>
      <li>Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.</li>
    </ul></p>
  </section2>
</section1>
<section1 topic='Protocol' anchor='protocol'>
  <section2 topic='Advertising Support' anchor='disco'>
    <p>Clients need to include a capability in Disco. Probably.</p>
    <p>Servers need to advertise capability against account.</p>
  </section2>
  <section2 topic='Subscribing' anchor='subs'>
    <p>Clients use a modified XEP-0060 Subscribe with a newly added "jid" attribute? Presumably this may need to be in a distinct namespace.</p>
    <p>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.</p>
    <p>Servers use traditional XEP-0060 subscribes, but sent from the bare jid of the account.</p>
    <p>Servers MUST send a Thing to indicate the new subscription to all clients capable of this protocol.</p>
  </section2>
  <section2 topic='Unsubscribing' anchor='unsub'>
    <p>As above.</p>
  </section2>
  <section2 topic='Listing Subscriptions' anchor='sublist'>
    <p>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.</p>
  </section2>
  <section2 topic='Auto Subscriptions' anchor='autosub'>
    <p>Servers need to subscribe to remote PEP services with a "mask" containing 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.</p>
    <p>Perhaps timing out node types which have not been requested for over a certain period?</p>
    <p>For legacy remote PEP services, the server needs to inject +notify caps into the presence.</p>
    <p>The server also needs to remove +notify caps from legacy clients and spoof traffic?</p>
  </section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>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.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
</xep>