[Standards] Proposed XMPP Extension: Disco Feature Attachment

Stephen Paul Weber singpolyma at singpolyma.net
Mon Aug 9 00:08:06 UTC 2021


My main observation about this proposal is that it attaches meaning to
otherwise-opaque var strings, and in general reads more like a hack than a
solution.  I am sympathetic to the need here, but I think we can solve it
without resorting to this, and even still without needing to update caps.  Disco
and Caps already define a solid extensability mechanism as data forms to be
included with the info.  This proposal could perhaps look something like this:

<iq from='example.com'
    id='disco1'
    to='example.org'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    …
    <feature var='http://jabber.org/protocol/rsm'/>
    <x xmlns="jabber:x:data">
        <field type="hidden" var="FORM_TYPE">
            <value>urn:xmpp:feature-attachments</value>
        </field>
        <field var="http://jabber.org/protocol/rsm">
          <value>http://jabber.org/protoco/pubsub</value>
          <value>urn:xmpp:mam:2</value>
          <value>http://jabber.org/protocol/disco#items</value>
        </field>
    </x>
    …
  </query>
</iq>

Thus anyone not implementing the XEP sees exactly what the do currently, caps
will work unmodified, but anyone implementing the XEP can easily (and dare I say
*more* easily) get the list of attached features to any given other feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20210808/9d2f6984/attachment.sig>


More information about the Standards mailing list