RE: draft-ietf-impp-im-03.txt

[Randy Bush <randy@psg.com>]

>> why are the semantically different failures all given the same
>> response syntax "faulure?"  it would seem useful to let the
>> sender know the reason for the failure, as they are clearly
>> differentiated.
> 
> Just speaking from my own perception on this, having some sort of 'failure
> code' that differentiates various failure causes went beyond the 'minimal
> interoperability' scope of the gateway model. No question cause codes would
> be useful, and IM/presence protocols generally support them. But in order to
> be compliant with the CPIM model, I don't know if a protocol should be
> compelled support some way of expressing the reason for a failure.

i went down that path in my mind.  but i kept looking at the doc,
which did indeed specifically delineate causes.  e.g.,

   1.  If the source or destination does not refer to a syntactically
       valid INSTANT INBOX, a response operation having status "failure"
       is invoked.

   2.  If the destination of the operation cannot be resolved by the
       recipient, and the recipient is not the final recipient, a
       response operation with the status "failure" is invoked.

   3.  If access control does not permit the application to request this
       operation, a response operation having status "failure" is
       invoked.

would seem yearning to produce things such as
  "failure-bad-src-or-dest-syntax"
  "failure-cant-resolve-dest"
  "failure-acl-blocked"

but no big deal.  i get the bends above layer four anyway.  it just
seemed strange to me.

> As an aside, Dave Crocker argued at some length

no!  really?  i am deeply shocked.

randy