Thanks Florian, generally I agree, but please read my answers below.
>> 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. True from a pure protocol point of view, but less true from a client's "UI features" point of view. http://xmpp.org/extensions/xep-0297.html#support says: "Clients that implement this specification to display simple forwarded messages (i.e. those not part of another extension)“ which reads like „A client could be able to display XEP-0280 messages, but might not be able to interpret/display XEP-0297 messages (’simple forwarded messages’)“. => client would advertise support for XEP-0280, but not for 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)!? > > No, because you can use file-transfer without ibb. > In this case I disagree. Both, XEP-0234 and XEP-0096 *require* IBB: http://xmpp.org/extensions/xep-0096.html#protocol-tech http://xmpp.org/extensions/xep-0234.html#impl-mti Which for me means, if the user chooses to disable IBB for whatever reasons, he implicitly disables file transfer as a whole, at least from a XEP-0030 point of view. -Christian
