On Mon, 2011-09-12 at 20:31 +0200, Alexander Holler wrote: > Hello, > > I wonder why that 'feature-not-implemented' is used instead of the > standard response 'service-unavailable' for unknown iq requests. > > E.g. how can a service return an error 'feature-not-implemented' if he > doesn't know about that feature?
Because, typically, the receiving service does recognise the enclosing <pubsub/> element in the http://jabber.org/protocol/pubsub or http://jabber.org/protocol/pubsub#owner namespaces. See also section 8.3.3.3 of XMPP Core [1]. Additionally, there might be separation between protocol parsing, and the business logic that is behind it. E.g. Wokkel implements many parts of the protocol defined in XEP-0060, but doesn't provide any business logic. Implementations of a publish subscribe service, like Idavoll, can pick and choose which parts of the protocol they actually provide logic for. In that case, even though the protocol is understood, the feature might not actually be implemented. Wokkel might even reply with a 'bad-request' condition even though there is no supporting business logic for a particular feature, if the request was not correct. Practically, though, I wonder if the other party would actually care whether it got a 'service-unavailable' or 'feature-not-implemented' condition. In both cases, the client is doing something wrong, as it should have first discovered (or have intrinsic knowledge about) support for the namespace and associated features, before using them. [1] http://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-feature-not-implemented -- ralphm
