Stream elements

[Brett Zamir]

I was just looking at the rest of the stream elements, in order to see
if any other elements might be available to the event listeners (for the
sake of documentation and/or code additions).

The only stream level element I don't see any built-in support for
handling, is receiving any TLS failures with <failure
xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>.

And I see that we might detect the children of SASL's <failure/> element
in a distinguishable way, but according to its children: [aborted,
incorrect-encoding, invalid-authzid, invalid-mechanism,
mechanism-too-weak, not-authorized, temporary-auth-failure].

On the client side of things, I see only two things at the stream level
left that can still be added (besides potentially adding other
<mechanism> children of <mechanisms>), both in the SASL namespace
urn:ietf:params:xml:ns:xmpp-sasl :
1) a <response/> element sent back to the server during SASL negotiation.
2) the ability to send <abort/> (to avoid disconnecting upon a wrong
password)

One other question on the topic of streams--would there be any reason to
verify the existence of the <session/> child of <stream:features> (as
you already check for all of the other possible children of it)?

best wishes,
Brett

[Massimiliano Mirra]

On Sat, Sep 13, 2008 at 5:55 AM, Brett Zamir <bre...@gmail.com> wrote:
>
> I was just looking at the rest of the stream elements, in order to see
> if any other elements might be available to the event listeners (for the
> sake of documentation and/or code additions).
>
> The only stream level element I don't see any built-in support for
> handling, is receiving any TLS failures with <failure
> xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>.
>
> And I see that we might detect the children of SASL's <failure/> element
> in a distinguishable way, but according to its children: [aborted,
> incorrect-encoding, invalid-authzid, invalid-mechanism,
> mechanism-too-weak, not-authorized, temporary-auth-failure].

Ehm, exactly what is the proposal here? :) Do you want to add other
cases where {event:'connector', state:'error'} is thrown?

> On the client side of things, I see only two things at the stream level
> left that can still be added (besides potentially adding other
> <mechanism> children of <mechanisms>), both in the SASL namespace
> urn:ietf:params:xml:ns:xmpp-sasl :
> 1) a <response/> element sent back to the server during SASL negotiation.

Doesn't that only make sense in the context of a challenge/response mechanism?

> 2) the ability to send <abort/> (to avoid disconnecting upon a wrong
> password)

Have you come across a scenario where you need that? As usual, I'm
only inclined to add complexity if it's actually used. The opposite
is bitrot, not completeness.

> One other question on the topic of streams--would there be any reason to
> verify the existence of the <session/> child of <stream:features> (as
> you already check for all of the other possible children of it)?

See above, if you came across cases where you need that, I'd see a reason to.