Am 13.09.2011 09:48, schrieb Ralph Meijer:
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].
Yes, but e.g. XEP-0248 defines some additional circumstances with errors
an XEP-0060-only service can't send (without knowing XEP-0248).
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
Practically a client has to handle both cases and I think too that a
client wouldn't make a difference.
So if someone wants to streamline XEP-0060, XEP-0248 and maybe RFC 6120,
he would have my vote to get rid of that feature-not-implemented. ;)
And if someone really wants to offer such as error, I would move that
(in case of PUBSUB) to the pubsub-namespace, e.g.:
------------
<iq type='error'
from='pubsub.shakespeare.lit'
to='[email protected]/barracks'
id='subscriptions1'>
<error type='cancel'>
<servive-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<feature-not-implemented
xmlns='http://jabber.org/protocol/pubsub#errors'
feature='retrieve-subscriptions'/>
</error>
</iq>
------------
With that feature-not-implemented as an optional description. Or maybe
feature-unsupported or unsupported in the pubsub-namespace, but optional.
Regards,
Alexander
