Subject: Re: [xmpp] 3920bis: stream features

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Dec 2009 12:21:05 -0700

On 11/17/09 3:35 PM, Peter Saint-Andre wrote:
> At the WG meeting in Hiroshima, I mentioned two open issues regarding
> stream features:
> 
> 1. Should we allow the receiving entity to resend stream features at any
> time during the life of the stream?
> 
> 2. Should we allow the initiating entity to send stream features?

I see no demand for either of those features, so I shall consider these
two issues closed.

> The motivation here is that we might have long-lived streams (especially
> for server-to-server federation) and it's possible that a server admin
> might enable a feature while such a stream is live. Instead of forcing
> the parties to close the stream and start a new stream negotiation, it
> might be good to allow them to advertise and then negotiate only the
> newly-enabled feature. However, the desire to have this method needs to
> be balanced against complexity (perhaps it's really not a big deal to
> close the old stream and start a new one).

In chatting about this with Jehan Pagès just now, we came to the
conclusion that we'll need a new stream error condition to signal that
the receiving entity is closing the stream because it has new features
to offer or just needs to reset the stream context (this could also be
used if certificates have expired or have been revoked during the life
of the stream). Therefore I suggest that we add a new stream error
<stream-reset/>, which means "Sorry, there really isn't a problem, but I
need to reset the stream, please reconnect if you want to continue
communicating with me."

I shall adjust some related text in the next version of the spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/