XEP-0360: Nonzas (are not Stanzas)

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

The usage of non-Stanza top-level XMPP stream elements is steadily increasing in the last years. Starting with Stream Management (XEP-0198) [1], one of the earliest XEPs which specified and used additional non-Stanza elements, the XMPP community sees an increasing usage of those elements in submitted specifications. Unlike Stanzas which are specified in RFC 6120 [2] § 4.1 "Stream Fundamentals" and § 8. "XML Stanzas", there is no term and definition provided for them.

This leads to the unfortunate situation where some submitted XEPs erroneous refer to non-Stanza top level stream elements as 'Stanzas'. Thus causing confusion, and opening the door to possible interoperability breakage and security vulnerabilities.

This XEP tries to fix this by providing a term, a definition and declaring some rules for those XMPP stream elements.

2. Nonza Definition

Nonza: A Nonza is every XML element found at the XMPP stream's top level which is not a Stanza. The top level of an XMPP stream is the child XML level beneath the last <stream> opening tag as defined in RFC 6120 § 4.2. "Opening a Stream", i.e. at depth=1 of the stream.

Informal definition: A XMPP stream element is a Nonza, if its element name is not 'message', 'iq' or 'presence'.

The term 'Nonza' originates from the beginning and ending letters of its definition and thus makes it easy to recall that definition: Not a Stanza.

3. Nonza Examples

<compress xmlns='http://jabber.org/protocol/compress'>
  <method>zlib</method>
</compress>

<enable xmlns='urn:xmpp:sm:3'/>

<active xmlns='urn:xmpp:csi:0'/>

4. Use Cases

Nonzas are commonly used when it is not necessary to route the exchanged information behind the endpoints of an XMPP stream. For example, one use case is to control the XMPP stream like it is done in XEP-0198: Stream Management.

Nonzas sent before resource binding, as defined in RFC 6120 § 7., usually follow a request-response pattern. But after the client successfully bound a resource, they are used in a more "asynchronous" fashion, where a 'request' Nonza does not, or at least not immediately, trigger a 'result' Nonza sent back.

5. Business Rules

1. Nonzas MUST NOT be routed, i.e. they are only exchanged between the two endpoints of an XMPP stream.
2. Nonzas SHOULD NOT have a 'from' or 'to' attribute.

6. Security Considerations

As noted, Nonzas MUST NOT get routed, because this could introduce the ability for third parties to spoof them.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

8. XMPP Registrar Considerations

This document requires no interaction with XMPP Registrar [5].

Appendices

Appendix A: Document Information

Series: XEP
Number: 0360
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2015-07-14
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards 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 document 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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END