[Standards] SASL2 Update incoming

Sam Whited sam at samwhited.com
Fri Aug 25 14:36:41 UTC 2017


On Fri, Aug 25, 2017, at 09:22, Dave Cridland wrote:
> So the problem with that is that the schemas for the feature and the
> (same-named) top-level element wouldn't match.

That seems fine to me, but I also don't understand XML schema so I might
just not understand why that's a problem. How do other features handle
this since they mostly use the same names?

> 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.

Actual serious question: Why not?

> 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.

I had forgotten about dialback; I'm not suggesting we change all old
features though (nice as that would be), just that new ones try to stick
to this rule.

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

That would actually be really nice; I've only tested against a server
using the same implementation, so chances are mistakes wouldn't be
noticeable.

On Fri, Aug 25, 2017, at 09:27, Jonas Wielicki wrote:
> it also may complicate implementations which map XML elements to 
> objects; they would then need context about where the element occurs to
> pick  the object to map it to.

That's actually my use case, this is context you always have though. If
I'm a server and I read from the connection expecting a stream feature
to be selected, I know if I need to unmarshal into a request or response
struct.

—Sam


More information about the Standards mailing list