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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
