[Standards-JIG] Closing idle streams

Carlo v. Loesch CvL at mail.symlynX.com
Thu Jun 1 10:29:06 CDT 2006 

In the meantime, since the new stream closing technique needs
to be formalized, I worked out a little 'Best Practice' and
would like to hear any comments before submission. In particular
should I add a "How Not to Close an Idle Stream" or is it
sufficiently redundant?


               JEP-xxxx: Best Practice for Closing Idle Streams

   This document specifies best practice for closing an idle XMPP stream.
     _________________________________________________________________

   WARNING: This document has not yet been accepted for consideration or
   approved in any official manner by the Jabber Software Foundation, and
   this document must not be referred to as a Jabber Enhancement Proposal
   (JEP). If this document is accepted as a JEP by the Jabber Council, it
   will be published at <[1]http://www.jabber.org/jeps/> and announced on
   the <standards-jig at jabber.org> mailing list.
     _________________________________________________________________

JEP Information

   Status: ProtoJEP
   Type: Informational
   Number: xxxx
   Version: 0.0.1
   Last Updated: 2006-05-31
   JIG: Standards JIG
   Approving Body: Jabber Council
   Dependencies: XMPP Core
   Supersedes: None
   Superseded By: None
   Short Name: N/A

Author Information

Carlo von Loesch

   Email: [2]lynX at jabber.getting.psyced.org
   JID: [3]lynX at ve.symlynX.com

Legal Notice

   This Jabber Enhancement Proposal is copyright 1999 - 2006 by the
   [4]Jabber Software Foundation (JSF) and is in full conformance with
   the JSF's Intellectual Property Rights Policy
   <[5]http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be
   distributed only subject to the terms and conditions set forth in the
   Creative Commons Attribution License
   (<[6]http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

   The preferred venue for discussion of this document is the
   Standards-JIG discussion list:
   <[7]http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

   The Extensible Messaging and Presence Protocol (XMPP) is defined in
   the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications
   contributed by the Jabber Software Foundation to the Internet
   Standards Process, which is managed by the Internet Engineering Task
   Force in accordance with RFC 2026. Any protocol defined in this JEP
   has been developed outside the Internet Standards Process and is to be
   understood as an extension to XMPP rather than as an evolution,
   development, or modification of XMPP itself.

Conformance Terms

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119.
     _________________________________________________________________

Table of Contents

   1. [8]Introduction
   2. [9]How to Close an Idle Stream

        2.1. [10]Handshake Stream Shutdown

   3. [11]Conclusion
   4. [12]Security Considerations
   5. [13]IANA Considerations
   6. [14]Jabber Registrar Considerations
   [15]Notes
   [16]Revision History
     _________________________________________________________________

1. Introduction

   RFC 3920 [[17]1] offers several ways on how to terminate an XMPP
   stream, but doesn't always make a clear statement which one to take.
   This can lead to faulty implementations. In particular, closing a
   stream that hasn't been in use for a while is very often achieved
   using a connection-timeout error, then closing the socket. This can
   lead to loss of data. Therefore this document proposes a practice that
   will avoid such data loss.

2. How to Close an Idle Stream

2.1 Handshake Stream Shutdown

   As shown in the basic "session" example in the Simplified Stream
   Examples (4.8 of RFC 3920), it is a valid transaction to close the
   outgoing stream by sending

 </stream:stream>

   then wait for the other entity to close its stream, like this:

 </stream:stream>

   and shut down the TCP connection.

   This will ensure that, should the other entity have transmitted any
   data, it will arrive and be processed before the TCP connection is
   terminated.

   Special care MUST be taken that under no circumstance further packets
   may be written to the socket after the stream was closed, until the
   other side shuts down the socket.

   On the outgoing TCP connection you MAY do a read-only shutdown of the
   socket, as long as the other side will safely be able to send its
   stream termination token.

3. Conclusion

   Please update your implementations to use the 'Handshake Stream
   Shutdown' strategy when shutting down streams you no longer need.

   Even not to shut down idle streams at all is a better strategy than to
   shut them down by creating an error condition, so if your application
   has no necessity for shutting down idle connections, just don't do it.

4. Security Considerations

   This proposal introduces no new security aspects.

5. IANA Considerations

   This proposal requires no interaction with the Internet Assigned
   Numbers Authority (IANA) [[18]2].

6. Jabber Registrar Considerations

   This proposal requires no interaction with the Jabber Registrar
   [[19]3].
     _________________________________________________________________

Notes

   1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core
   <[20]http://www.ietf.org/rfc/rfc3920.txt>.

   2. The Internet Assigned Numbers Authority (IANA) is the central
   coordinator for the assignment of unique parameter values for Internet
   protocols, such as port numbers and URI schemes. For further
   information, see <[21]http://www.iana.org/>.

   3. The Jabber Registrar maintains a list of reserved Jabber protocol
   namespaces as well as registries of parameters used in the context of
   protocols approved by the Jabber Software Foundation. For further
   information, see <[22]http://www.jabber.org/registrar/>.
     _________________________________________________________________

Revision History

Version 0.0.1 (2006-05-31)

   First draft. (cvl)
     _________________________________________________________________

   END

References

   1. http://www.jabber.org/jeps/
   2. mailto:lynX at jabber.getting.psyced.org
   3. xmpp:lynX at ve.symlynX.com
   4. http://www.jabber.org/jsf/
   5. http://www.jabber.org/jsf/ipr-policy.shtml
   6. http://creativecommons.org/licenses/by/2.5/
   7. http://mail.jabber.org/mailman/listinfo/standards-jig
   8. http://idle.psyced.org/jep-idle-streams.html#intro
   9. http://idle.psyced.org/jep-idle-streams.html#do
  10. http://idle.psyced.org/jep-idle-streams.html#sect-id2250792
  11. http://idle.psyced.org/jep-idle-streams.html#conclusion
  12. http://idle.psyced.org/jep-idle-streams.html#security
  13. http://idle.psyced.org/jep-idle-streams.html#iana
  14. http://idle.psyced.org/jep-idle-streams.html#registrar
  15. http://idle.psyced.org/jep-idle-streams.html#notes
  16. http://idle.psyced.org/jep-idle-streams.html#revs
  17. http://idle.psyced.org/jep-idle-streams.html#nt-id2250779
  18. http://idle.psyced.org/jep-idle-streams.html#nt-id2251705
  19. http://idle.psyced.org/jep-idle-streams.html#nt-id2251886
  20. http://www.ietf.org/rfc/rfc3920.txt
  21. http://www.iana.org/
  22. http://www.jabber.org/registrar/

More information about the Standards-JIG mailing list