On Fri, 7 May 2021 at 14:34, Edwin Mons <e...@ik.nu> wrote: > On 07/05/2021 14:33, Kevin Smith wrote: > > The text in question mentions wanting the connection terminated, which > suggests stream error is right (which also seems logically sound to me). > > > > "If a server receives a second <enable/> element it SHOULD respond with > a stream error, thus terminating the client connection.” > > This was indeed how I interpreted the text and am inclined to implement. >
Yes, I think that you want to emit a stream error here. Rationale: A client sending a second <enable/> is unambiguously broken. There's three possible outcomes here: * The server responds <failed/>, and the client accepts its second <enable/> has failed but its first is still in effect. * The server responds <failed/>, and the client turns off stream management entirely. * The server responds with a stream error, and the client goes away. The server cannot know which of the first two a client might do if it sends <failed/>, and moreover, even if we tried to specify that, the client is unambiguously demonstrating it's broken anyway, so we still wouldn't know. Therefore the only safe thing is to issue a stream error explaining the situation and disconnect. Any opinions on what stream error to send? I think we may be in to <undefined-condition/> territory; nothing else seems to fit. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
