[Standards] SASL2 Update incoming

Dave Cridland dave at cridland.net
Fri Aug 25 14:22:20 UTC 2017


On 25 August 2017 at 15:03, Sam Whited <sam at samwhited.com> wrote:
> On Fri, Aug 25, 2017, at 06:33, Dave Cridland wrote:
>> Comments are most welcome!
>
> The only thing I think needs to be changed right now, though it sounds
> minor, is that the response to select the SASL stream feature does not
> match the feature advertised. The server offers "<mechanisms/>" and the
> client responds with "<authenticate/>. While I know there's no
> requirement in 6120 that these match, it's an assumption that would be
> nice to be able to make in some future stream negotiation protocol (and,
> in my experience, simplifies writing stream feature APIs). Doing it now
> could help ensure future compatibility. The current SASL profile is, I
> think, the only widely used stream feature where the response does not
> match the advertised feature, so it would also be nice for consistencies
> sake if nothing else.
>

So the problem with that is that the schemas for the feature and the
(same-named) top-level element wouldn't match.

On the one hand, I don't care, but on the other, it makes it hard to document.

On a similar note, however, you cannot design every stream feature
such that the negotiation method is to send the feature element as a
top-level element.

I think it's reasonable to try to ensure that every stream feature's
namespace is the same as any top-level elements it uses; but that rule
has already been broken with dialback.

So anyway, if we're to have exceptions to the general rule, it's nice
if one of them is (hopefully) the first one clients will be using.

> Thanks for all your work on this! I'll hopefully update my
> implementation with your changes soon.

I can spin up a server with this running if you like.

Dave.


More information about the Standards mailing list