> 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 !?!?!?!?
That is the interpretation I've always used. Disco features come in two flavors: purely descriptive and advertised allowed behaviour. Purely descriptive and informative features would be ones like hashes, supported pubsub options, etc. Features that control allowed behaviour are concerned about top-level traffic. For example, nearly everything ends up requiring the use of XEP-0004. But including 'jabber:x:data' in your feature list doesn't mean that you are able to work with data forms in the context of all the various XEPs, it means that you are able to handle and will allow receiving messages with bare top-level data forms. Removing 'jabber:x:data' from your feature list does not and should not imply that you've turned off nearly every XEP as a consequence. So yes, a client can certainly advertise that it supports 'urn:xmpp:carbons:2' (which implies only supporting enough of forwarding to implement carbons), but does not advertise 'urn:xmpp:forward:0' because it either does not support displaying forwarded messages or simply does not want to receive them. As a user, I would not expect turning off support to display forwarded messages from my friends to suddenly mean I can no longer see chats I sent from my other IM clients. Element re-use does not mean user-meaningful feature dependency. >> >>> 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. Yeah, I'm torn on this one. If I disabled IBB, then I would not be surprised that Jingle file transfers wouldn't work with IBB anymore. So removing both 'http://jabber.org/protocol/ibb', and 'urn:xmpp:jingle:transports:ibb:1' at the same time at least makes sense. While it could be argued that including the Jingle feature and not the plain IBB feature means that you would only accept IBB requests that had first been negotiated via Jingle, I don't think I'd ever use or recommend doing it that way. On the other hand, I *would* be surprised that disabling IBB meant that I couldn't transfer files at all anymore, especially when I had other transports enabled. That is behaviour I would only expect from knowingly toggling file transfer as a whole on or off. This one may need to go to Peter for a philosophy question: what is to be done when an implementation of feature Y MUST support X as a fallback, but the user chooses to disable X. - Lance
smime.p7s
Description: S/MIME cryptographic signature
