[Standards] Resource unbinding issue - RFC 3920bis

[Peter Saint-Andre]

On Mon, Oct 08, 2007 at 11:10:02AM +0200, Ralph Meijer wrote:
> 
> 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.

I see what you're saying. If you support the namespace but don't support
the element name, it's <feature-not-implemented/>. If you support the
namespace and you support the element name but the element is not
properly structured (attributes, child elements) then it is
<bad-request/>. That seems fine to me, and is a good clarification for
rfc3920bis.

/psa