On Mon, 2008-03-03 at 16:24 -0700, Peter Saint-Andre wrote: > > Indeed, it's not 100% clear that we need *any* stream re-openings, and > that's something we might want to put into rfc3920bis for improved > efficiency during stream negotiation. Or at least discuss.
I agree that reopening the stream is just syntactic sugar since it really enforces nothing, but maybe a better option would be that the new list of features is sent after each one is negotiated? That would allow my example to work (regarding some future feature) and would probably be backward compatible since clients don't typically crash when they receive something they are not expecting. But going forward 'bis' clients could expect the new set of features after, for example, binding the resource. -travis
