[Standards] Resource unbinding issue - RFC 3920bis

[Ralph Meijer]

On Thu, 2007-10-04 at 17:27 -0600, Peter Saint-Andre wrote:
> Ralph Meijer wrote:
> > On Fri, 2007-09-21 at 00:22 +0200, Tomasz Sterna wrote:
> >> rfc3920bis-03 says:
> >>
> >> 8.5.3.2.1.  Unbind Not Supported
> >> If the server does not understand the <unbind/> element, it MUST return
> >> a stanza error, which SHOULD be <bad-request/>.
> >>
> >> This is not backwards compatible.
> >> Pre-bis servers would reply with <feature-not-implemented/> error rater
> >> than <bad-request/>. This <unbind/> <iq/> is not a bad request for them,
> >> but just another unimplemented feature.
> > 
> > Agreed. The request is not missing required attributes or the like, so I
> > don't think that <bad-request/> is appropriate here. It is just a
> > request in a known namespace with an unknown element name, and
> > <feature-not-implemented/> seems appropriate here.
> 
> I gave this some thought before choosing <bad-request/>.
> 
> Basically there is a kind of philosophical issue here -- how does the
> existing implementation know that <unbind/> is a feature at all? IMHO
> <feature-not-implemented/> is appropriate when you have something like
> pubsub (XEP-0060), where the features are well-defined and you know if
> you don't support a given feature. But here the implementation doesn't
> know that <unbind/> means anything, so as far as it is concerned this is
> just a bad element that doesn't match the schema.

I don't agree.

I would say that <feature-not-implemented/> /is/ appropriate as a
response to an unknown element in a known namespace as a direct child of
iq, for forward compatibility.

For pubsub, we have one common element and then a number of 'verbs'.
There too could we add new ones in a future enhancement and I think it
is appropriate to have a <feature-not-implemented/> response for
unknowns there, too. The pubsub protocol simply has a certain semantics
carried with it for direct childs of <pubsub/>. Oh, and also even for
using type='set' on a verb that is currently only defined for 'get'.

On the other hand, <bad-request/> is for something that starts out as
something known (for example a known element) that has known-to-be-wrong
properties like bad/missing attributes, child elements.

Note also that the error type here is 'modified', unlike 'cancel' for
<feature-not-implemented/>. You cannot modify a request that is using
'future' protocol features (from the receiving party's POV) to make it
work.

-- 
Groetjes,

ralphm