On 15.03.2015 22:25, Christian Schudt wrote: > 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 ?
Yes, because you can't use carbons without forward. > 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)!? No, because you can use file-transfer without ibb. > 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. Depends if the feature is required or not. If it is required it is enabled(/supported) by the entity, and therefore should be announced via means of xep30. - Florian
signature.asc
Description: OpenPGP digital signature
