Hi all, there are several features/extension protocols, which are dependent on others, e.g.
urn:xmpp:carbons:2 ==> urn:xmpp:forward:0 http://jabber.org/protocol/si/profile/file-transfer ==> http://jabber.org/protocol/si http://jabber.org/protocol/caps ==> http://jabber.org/protocol/disco#info http://jabber.org/protocol/xdata-layout ==> jabber:x:data ... Now, imagine a client, which allows the user to „(un)check“ certain features and the user decides to enable „XEP-0280 Message Carbons“ and checks the according checkbox, which eventually adds "urn:xmpp:carbons:2“ as a feature for Service Discovery. Should the disco#info features list include only "urn:xmpp:carbons:2“ or should it also (implicitly) include "urn:xmpp:forward:0“, because XEP-0280 depends on XEP-0297 ? From a user experience perspective: should checking the „XEP-0280“ checkbox implicitly check the „XEP-0297“ checkbox as well? And should unchecking the „XEP-0297“ implicitly uncheck the „XEP-0280“ checkbox? (checked features would be directly reflected to disco#info) There are even more complex dependency trees, like: urn:xmpp:jingle:apps:file-transfer:4 ==> urn:xmpp:hashes:1 ==> urn:xmpp:jingle:1 ==> urn:xmpp:jingle:transports:s5b:1 ==> http://jabber.org/protocol/bytestreams ==> urn:xmpp:jingle:transports:ibb:1 ==> http://jabber.org/protocol/ibb Which I’d interpret as: if 'http://jabber.org/protocol/ibb' is disabled, it implicitly disables all dependent features („parents“) as well (urn:xmpp:jingle:transports:ibb:1, urn:xmpp:jingle:apps:file-transfer:4)!? I hope you get my point. The general question is, can/may a feature which depends on another feature „standalone“ in a Service Discovery info result or must they always be coupled. Couldn’t find any guideline on this. Thanks for your thoughts! — Christian
