Subject: Re: [xmpp] <payment-required/>

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Dec 2010 13:46:41 -0700

On 11/30/10 5:03 PM, Justin Karneges wrote:
> On Tuesday 30 November 2010 15:24:33 Peter Saint-Andre wrote:
>> Would anyone object if we got rid of the <payment-required/> stanza
>> error condition?
> 
> But think of the profit potential!

Seeing no serious objections, I'll remove this from version -20, which
I'll post as soon as all the IESG and Gen-ART issues have been resolved
(probably next week).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 02 Dec 2010 14:36:34 -0700

> I'll post as soon as all the IESG and Gen-ART issues have been resolved

(as individual)
We can always standardize an extension for this later.  That extension would
have to specify what you *do* when you receive this error, which is a good
reason to remove it from the core spec now.

-- 
Joe Hildebrand

---

From: Matthew Wild <[email-masked]>
Date: Thu, 2 Dec 2010 21:55:31 +0000

> I'll post as soon as all the IESG and Gen-ART issues have been resolved

Just a note that XEP-0060 and XEP-0086 reference this error. However
in neither case do I see a reason we need to hold onto it.
<payment-required/> is just a special case of <forbidden/>, and the
additional information about requiring payment could easily be
conveyed in application-specific errors and/or <text>.

Regards,
Matthew

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Dec 2010 12:15:15 +0000

>reason to remove it from the core spec now.
Good point.

On a somewhat related note: are clients expected to cope with any 
unrecognized stanza and stream errors? XML schema doesn't seem to allow 
for extensions and I don't see any clear statement on whether new errors 
are allowed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 04 Dec 2010 06:56:43 -0700

> for extensions and I don't see any clear statement on whether new errors

New stream/stanza error conditions are defined by modifying the core
spec. New application-specific conditions are allowed by defining any
extension spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Dec 2010 16:35:43 +0000

Peter Saint-Andre wrote:

>spec.
So what would happen when a client that complies with an older spec sees 
an error code from a later spec? For example if <payment-required/> is 
reintroduced in the future?

I think the document needs to state whether new error codes are allowed 
and how clients should handle unexpected ones.

>New application-specific conditions are allowed by defining any
>extension spec.
>  
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Dec 2010 16:39:50 +0000

Alexey Melnikov wrote:

> So what would happen when a client that complies with an older spec 
> sees an error code from a later spec? For example if 
> <payment-required/> is reintroduced in the future?

And if there is no mechanism to introduce new error codes without 
revising this spec, then this brings the question of whether XMPP 
version number is incremented every time a new error code is added to XMPP.

> I think the document needs to state whether new error codes are 
> allowed and how clients should handle unexpected ones.
>

---

From: Joe Hildebrand <[email-masked]>
Date: Sat, 04 Dec 2010 15:16:35 -0700

> reintroduced in the future?

The error-type from 8.3.2 gives such a client the information it needs.

> and how clients should handle unexpected ones.

Do we need more that what's in 8.3.2?

-- 
Joe Hildebrand
(as individual)

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 04 Dec 2010 17:01:59 -0700

On 12/4/10 9:39 AM, Alexey Melnikov wrote:
>> sees an error code 

Error condition. We haven't used numeric error codes in a long time.

>> from a later spec? 

For stanza errors, treat it as you would treat <undefined-condition/>,
which is a catch-all condition (although it too is unused at present).

For stream errors, it's unrecoverable anyway.

>> For example if

There's no reason to do that.

> version number is incremented every time a new error code is added to XMPP.

Seems a bit excessive, no?

In any case, one solution is to never revise the spec again. We've got
good consensus about the current list of error conditions, and given
that the stanza error conditions especially have been stable for ~10
years (other than removing <payment-required/>, which has never been
used), why worry about something that is extremely unlikely?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Dec 2010 17:21:45 +0000

>The error-type from 8.3.2 gives such a client the information it needs.
So basically section 8.3.2 doesn't require the client to handle 
gracefully an unrecognized error condition.
I think the spec should be clear on this one way or another.

>Do we need more that what's in 8.3.2?
I think we do. I can suggest some text.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Dec 2010 18:54:05 +0000

>Error condition. We haven't used numeric error codes in a long time.
Yes, I meant error conditions.

>which is a catch-all condition (although it too is unused at present).
I can't find where the document says that. This is pretty much what I 
wanted to suggest anyway.

And I think a similar statement about SASL errors (<not-authorized/>?)

>Seems a bit excessive, no?
Perhaps. I wasn't really suggesting this for real. But if client 
developers are not told that they should be able to handle any error 
condition they don't recognize, then some of them wouldn't.

>used), why worry about something that is extremely unlikely?
Well, experience with HTTP and SMTP tells otherwise. I don't think XMPP 
is really different in this respect.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 06 Dec 2010 09:22:27 +0000

As Peter loves to see Isode folk argue...

1) §8.3.2 does indeed mandate that:

   The "defined-condition" MUST correspond to one of the stanza error
   conditions defined under Section 8.3.3.

2) However, I would argue that extensibility here is NOT required,  
and would lead to worse interoperability.

Consider that we re-invent <payment-required/>. All clients built to  
not understand it will either choke (with the current §8.3.2 text  
above) or else treat it as an undefined-condition. Neither seems as  
good as if we re-invent it as an application-specific condition  
element. And I don't consider it likely that a new error condition  
could be invented that we couldn't treat this way, not least because  
we have the defined-condition of undefined-condition - yay irony -  
and this essentially provides our extensibility point.

If text needs to be added to clarify this position, let's do that.

As possible editorial changes, here, I noticed that "by='jid'" wasn't  
quite as clear as other areas. Maybe by='error-generator', with  
suitable key above?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Dec 2010 09:35:03 +0000

> If text needs to be added to clarify this position, let's do that.

I am actually fine with your proposal. I only wanted clarity on how 
error condition extensibility can be achieved.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 Dec 2010 11:28:04 -0700

On 12/6/10 2:22 AM, Dave Cridland wrote:
> 2) However, I would argue that extensibility here is NOT required, and
> would lead to worse interoperability.
> 
> Consider that we re-invent <payment-required/>. All clients built to not
> understand it will either choke (with the current §8.3.2 text above) or
> else treat it as an undefined-condition. Neither seems as good as if we
> re-invent it as an application-specific condition element. And I don't
> consider it likely that a new error condition could be invented that we
> couldn't treat this way, not least because we have the defined-condition
> of undefined-condition - yay irony - and this essentially provides our
> extensibility point.
> 

I suggest that we modify the following paragraph in Section 8.3.2:

   The "defined-condition" MUST correspond to one of the stanza error
   conditions defined under Section 8.3.3.  If the designers of an XMPP
   protocol extension or the developers of an XMPP implementation need
   error conditions that are not defined in this specification, they can
   do so by defining an application-specific error condition element
   qualified by an application-specific namespace.

I suggest that we modify the similar paragraph for stream errors in
Section 4.9.2.

That leaves SASL errors, for which we do not have a placeholder in the
schema for application-specific error conditions. My sense is that we
haven't seen the need for extensibility there, because XMPP it itself an
application of SASL and we haven't thought that anyone would be defining
XMPP applications on top of SASL that would require any kind of
application-specific error conditions.

> quite as clear as other areas. Maybe by='error-generator', with suitable
> key above?

Done:

###

8.3.2.  Syntax

   The syntax for stanza-related errors is as follows, where XML data
   shown within the square brackets '[' and ']' is OPTIONAL, 'intended-
   recipient' is the JID of the entity to which the original stanza was
   addressed, 'sender' is the JID of the originating entity, and 'error-
   generator' is the entity that detects the fact that an error has
   occurred and thus returns an error stanza.

   <stanza-kind from='intended-recipient' to='sender' type='error'>
     [OPTIONAL to include sender XML here]
     <error [by='error-generator']
            type='error-type'>

[...]

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 06 Dec 2010 22:12:57 +0000

Hi Peter,

>I suggest that we modify the similar paragraph for stream errors in
This works for me.

>application-specific error conditions.
Maybe we don't need application specific conditions, but the list of 
SASL error conditions is likely to change over time as SASL evolves.
For example, I might want to add a new error condition for channel 
binding mismatch.

Also, let's check what RFC 3920 defined:

  <aborted/>
  <incorrect-encoding/>
  <invalid-authzid/>
  <invalid-mechanism/>
  <mechanism-too-weak/>
  <not-authorized/>
  <temporary-auth-failure/>

and this revision adds:

  <account-disabled/>
  <credentials-expired/>
  <encryption-required/>
  <malformed-request/>

Best Regards,
Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 Dec 2010 15:52:25 -0700

>  <temporary-auth-failure/>

Yes, because we either didn't understand some topics in RFC 2222 or
needed to track changes between RFC 2222 and RFC 4422.

One possible way to handle this problem would be to establish a registry
of SASL error condition elements (for use by XMPP) or of SASL error
conditions in general (for use by all application protocols that re-use
SASL). But the latter would be a job for rfc4422bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Dec 2010 23:04:55 +0300

Peter Saint-Andre wrote:

>of SASL error condition elements (for use by XMPP)
>
That seems like a good idea.

>or of SASL error conditions in general (for use by all application protocols that re-use
The problem with this is that the registry would have to have both 
numeric codes and textual strings (which might be different for 
different application protocols). Chris Newman had a draft on this once 
and even covering SMTP, POP3 and IMAP4 was difficult.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Dec 2010 14:31:07 -0700

> That seems like a good idea.

Maybe. :)

First, I think there's more here than just a registry. We need to think
about what needs to go in the registry, more clearly define how a SASL
error condition element gets slotted into the protocol, how the error is
handled in any specific context, etc. Just saying "put it in a registry"
is not enough. FOR EXAMPLE, we might think about adding something like
the error types that we use for stanza errors so that clients know what
kind of processing to fall back to if they encounter a specific error
condition that they're not familiar with. But that kind of work would
require some protocol design, and I think that adding it to 3920bis
without due consideration this late in the process is not advisable
(however, it might be appropriate for 3920ter).

Second, it seems like in the XMPP community we would update our list of
SASL-related errors only if RFC 4422 is revised. But then any changes
would apply to all SASL consumers, not just XMPP. So I think that, at
the least, this is something that the SASL community needs to work on,
although perhaps in consultation with various SASL consumers.

Third, we've done the work of updating our SASL error conditions with
respect to RFC 4422. If and when RFC 4422 is updated, we could work on
3920ter. Furthermore, I think we'll work on 3920ter way before the
KITTEN WG starts on 4422bis, because we'll need to fold in the results
of work on the address format. When that happens, we can think more
about the SASL error handling issues (although I think we need to do
that in consultation or collaboriation with the KITTEN WG and various
SASL consumers).

> and even covering SMTP, POP3 and IMAP4 was difficult.

And I think this shows why this is something that the SASL community
needs to think about and work on. We don't have the full context to make
those decisions in the XMPP WG because we are a downstream customer of SASL.

Therefore I suggest that we *not* work on this now -- there are just too
many variables, too many sources of uncertainty, and too many chances
that we'll screw it up by trying to design more protocol this late in
the process. However, it's something that we need to think about in the
next few years and almost certainly take up with the KITTEN WG.

Or so it seems to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 14:33:45 +0000

>without due consideration this late in the process is not advisable
Rushing this would certainly not be advisable.

>(however, it might be appropriate for 3920ter).
Don't tell me that you are ready to start working on 3920ter ;-).

>SASL-related errors only if RFC 4422 is revised.
>
I disagree. RFC 4422 never listed all possible error conditions for all 
SASL mechanisms. I don't think it should.
I think a separate document would be required for that.

>But then any changes
>>>or of SASL error conditions in general (for use by all application
>>>protocols that re-use SASL). But the latter would be a job for rfc4422bis.      
>>>
>needs to think about and work on.
>
I am not convinced that the task of representing error conditions is 
something that the SASL community needs to work on. This seems like a 
task for specialists in the specific protocol.

>We don't have the full context to make
I appreciate your desire to be done with 3920bis. But I think that at 
minimum the document needs a small change now to clarify that new error 
conditions can be introduced in the future, so that clients can expect 
them. A specific suggestion:

In Section 6.5:

OLD:

   The "defined-condition" MUST be one of the SASL-related error
   conditions defined in the following sections.

NEW:

   The "defined-condition" is be one of the SASL-related error
   conditions defined in the following sections. Note that additional
   error conditions might be defined in the future and initiating
   entities MUST be able to handle unrecognized errors as a generic
   SASL authentication failure.

I would also like to recommend to treat all unrecognized errors as 
<not-authorized/>, but I am not entirely sure that it is the correct 
thing here, because the semantics doesn't match closely.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 08:08:18 -0700

>   SASL authentication failure.

That text seems reasonable to me.

> thing here, because the semantics doesn't match closely.

Right. For stream errors we have <undefined-condition/>, and for stanza
errors we have <service-unavailable>/> -- both of which function as a
kind of "generic error condition". Is <not-authorized/> generic for
SASL? The end result of a SASL error is that the entity has not been
authenticated, but I don't think that quite maps to <not-authorized/> as
we've defined it (which basically means "either you specified an unknown
username or you provided incorrect credentials"). One option would be to
define a SASL condition that explicitly generic, as we've done for
stream errors and stanza errors. However, I know that some folks don't
like these generic conditions because they don't provide useful
information about what happened...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 16:44:32 +0000

>That text seems reasonable to me.
Good, then we are almost done :-)

>SASL?
Not as currently defined in 3920bis.

>The end result of a SASL error is that the entity has not been
>authenticated,
>
Right.

>but I don't think that quite maps to <not-authorized/> as
>stream errors and stanza errors.
>
Yes, either this, or tweak the current description of <not-authorized/> 
to be the generic SASL failure.

>However, I know that some folks don't
The situation for authentication is different, because some 
implementations (or some implementations is certain configurations) 
would not want to disclose any specific information. So for SASL 
authentication it is quite Ok to return a generic error which means 
"something is wrong, but I am not telling you what.".

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 11:14:44 -0700

> "something is wrong, but I am not telling you what.".

Agreed.

If we go down that road, we would end up with something like the
following text...

###

6.5.  SASL Errors

   The "defined-condition" MUST be one of the SASL-related error
   conditions defined in the following sections.  However, because
   additional error conditions might be defined in the future, if an
   entity receives a SASL error condition that it does not understand
   then it MUST treat the unknown condition as a generic authentication
   failure, i.e., as equivalent to <not-authorized/> (Section 6.5.10).

[...]

6.5.10.  not-authorized

   The authentication failed because the initiating entity did not
   provide proper credentials, or because some generic authentication
   failure has occurred but the receiving entity does not wish to
   disclose specific information about the cause of the failure; sent in
   reply to a <response/> element or an <auth/> element with initial
   response data.

[...]

###

I think it's OK to say "MUST be one of the defined conditions (i.e., if
you comply with *this* spec then these are the only conditions that are
allowed) but things might change in the future..."

/psa

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 19:21:32 +0000

>   failure, i.e., as equivalent to <not-authorized/> (Section 6.5.10).
I think your text is Ok, the first MUST affects generators and the 
second MUST affects consumers.

>   reply to a <response/> element or an <auth/> element with initial
Works for me.

>allowed) but things might change in the future..."
Ok, as per the above.