Expected behavior when receiving an STS upgrade policy via CAP NEW

[Ascrod]

There seems to be a bit of confusion over what the client should do if it receives an STS upgrade policy over an insecure connection via CAP NEW. It's not currently defined by the spec, so I suppose in theory clients can do what they like in this case. But should there be any kind of clarification or recommendation made for this scenario?

I think a good recommendation would be something along the lines of having the client notify the user of the change and offer an option to reconnect at their discretion. I do not think forcing a reconnect is a good idea, as that would be disruptive and very annoying. But I think it's also important that the user switch to the secure port ASAP, and they should at least be made aware of the new policy.

Thoughts?

[jwheare]

My feeling is that this is implementation dependent.

A regular, user facing client would probably not want to interrupt people by automatically reconnecting a connection. They might want to show a notification to the user that a secure connection is available, or they might choose not to bother them and just wait for an inevitable reconnect in future.

A bot, however, might want to reconnect immediately (or might not).

We could possibly add some text mentioning these considerations in the non-normative section of the spec, but it kind of comes down to: "clients should make a decision based on what they think their users would like" which is effectively redundant waffle. Maybe just a note to say "think about this, but err on the side of caution"?

I'm a bit meh on specs being excessively pedantic and assuming people don't have brains, but maybe this is worth some clarity.

[DanielOaks]

Feels like some clarity here would be good, even if it's just along the lines of think about it, but err on the side of caution. Just clear up that we leave how to handle this case up to the implementer, so they don't think it's just a mistake in the spec that the case isn't mentioned.