Re: [Standards] Service Discovery + dependent features
On 16.03.2015 23:06, Christian Schudt wrote: Thanks Florian, generally I agree, but please read my answers below. I was mostly having a modular XMPP client library in mind. Here, if you advertise support for 'carbons', the library code for forward will be loaded. And in Smack's case, it's the full 'forward' code, not only the part required for 'carbons'. But of course, one could split the 'forward' module further, i.e. smack-extension-forward-whatIsRequiredForCarbons and smack-extension-forward-everythingElse, but I don't see a appealing reason to put some effort into that. And if you feel like not advertising 'forward' but 'carbons', then I see no problem with that either. I guess there are no implementations that actually specify and build a dependency graph for XMPP extensions. So nothing should break. Same is true for the jingle file-transfer case. If you feel like treating a missing 'ibb' announcement as 'jingle filetransfer is disabled', then there is nothing preventing you from doing so. :) But IMHO that's not a good idea. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Service Discovery + dependent features
Ok, makes sense as well. I conclude from this discussion, that there are no extension protocols which MUST be coupled with another one in service discovery (i.e. if A then B), although for some they SHOULD (e.g. if urn:xmpp:jingle:transports:ibb:1 then urn:xmpp:jingle:1). Thanks. -Christian Am 17.03.2015 um 17:19 schrieb Dave Cridland d...@cridland.net: On 16 March 2015 at 23:11, Lance Stout lancest...@gmail.com wrote: 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. MTI != MTD Mandatory To Implement does not mean Mandatory To Deploy - so if Y requires X as a fallback (or a server MUST implement SCRAM, or whatever) this doesn't imply that it must be deployed and activated at all times. Dave.
Re: [Standards] Service Discovery + dependent features
On 16 March 2015 at 23:11, Lance Stout lancest...@gmail.com wrote: 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. MTI != MTD Mandatory To Implement does not mean Mandatory To Deploy - so if Y requires X as a fallback (or a server MUST implement SCRAM, or whatever) this doesn't imply that it must be deployed and activated at all times. Dave.
Re: [Standards] Service Discovery + dependent features
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
Re: [Standards] Service Discovery + dependent features
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
Re: [Standards] Service Discovery + dependent features
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
[Standards] Service Discovery + dependent features
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
