Subject: [xmpp] #16: limit the applicability of stream resets for new features

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 17:58:48 -0000

#16: limit the applicability of stream resets for new features
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Regarding Section 4.2.5 (Completion of Stream Negotiation), Waqas Hussain
 commented:

 > (if the receiving entity has new features to offer, it can simply
 > close the stream using a  stream error and then advertise the
 > new features when the initiating entity reconnects, preferably
 > closing existing streams in a staggered way so that not all of
 > the initiating entities reconnect at once)

 This is fairly costly (all session state is lost, which as a user would
 annoy me quite a bit, and state wouldn't necessarily be fully
 recoverable). This should be limited to new features which are MTN. And
 even for MTN features, possibly only if the admin requests or policy
 requires that existing connections be kicked.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/16>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 20:42:46 -0600

On 6/14/10 11:58 AM, xmpp issue tracker wrote:
>  recoverable). 

Well, I think this situation will be quite rare.

(Question: does the Prosody team plan to allow stream resets when the
admin updates the server configuration?)

>  This should be limited to new features which are MTN. 

That seems reasonable. In my working copy I have changed this sentence to:

   After doing so, the receiving entity MAY send an
   empty <features/> element (e.g., after negotiation of such voluntary
   features) but MUST NOT send additional stream features to the
   initiating entity (if the receiving entity has new features to offer,
   preferably limited to mandatory-to-negotiate or security-critical
   features, it can simply close the stream using a <reset/> stream
   error and then advertise the new features when the initiating entity
   reconnects, preferably closing existing streams in a staggered way so
   that not all of the initiating entities reconnect at once).

>  And

IMHO that's an implementation detail.

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 02:44:12 -0000

#16: limit the applicability of stream resets for new features
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Provisionally resolved with the second clause in this parenthetical
 remark:

    (if the receiving entity has new features to offer,
    preferably limited to mandatory-to-negotiate or security-critical
    features, it can simply close the stream using a <reset/> stream
    error and then advertise the new features when the initiating entity
    reconnects, preferably closing existing streams in a staggered way so
    that not all of the initiating entities reconnect at once)

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/16#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 25 Jun 2010 16:07:46 +0500

On Fri, Jun 25, 2010 at 7:42 AM, Peter Saint-Andre <[email-masked]> wrote:
>>  > (if the receiving entity has new features to offer, it can simply
>>  > close the stream using a  stream error and then advertise the
>>  > new features when the initiating entity reconnects, preferably
>>  > closing existing streams in a staggered way so that not all of
>>  > the initiating entities reconnect at once)
>>

Yes, as an option/command available to admins. We don't like server restarts.

--
Waqas Hussain