Extended Content - XML Stanzas - It represents the consensus of the IETF community

8. XML Stanzas

8.4. Extended Content

Although the message, presence, and IQ stanzas provide basic semantics for messaging, availability, and request-response

interactions, XMPP uses XML namespaces (see [XML-NAMES]) to extend the basic stanza syntax for the purpose of providing additional functionality.

A message or presence stanza MAY contain one or more optional child elements specifying content that extends the meaning of the message (e.g., an XHTML-formatted version of the message body as described in [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one such child element. Such a child element MAY have any name and MUST possess a namespace declaration (other than "jabber:client", "jabber:

server", or "http://etherx.jabber.org/streams") that defines the data contained within the child element. Such a child element is called an "extension element". An extension element can be included either at the direct child level of the stanza or in any mix of levels.

Similarly, "extension attributes" are allowed. That is: a stanza itself (i.e., an <iq/>, <message/>, or <presence/> element qualified by the "jabber:client" or "jabber:server" content namespace) or any child element of such a stanza (whether an extension element or a child element qualified by the content namespace) MAY also include one or more attributes qualified by XML namespaces other than the content namespace or the reserved

"http://www.w3.org/XML/1998/namespace" namespace (including the called "empty namespace" if the attribute is not prefixed as

described under [XML-NAMES]).

Interoperability Note: For the sake of backward compatibility and maximum interoperability, an entity that generates a stanza SHOULD NOT include such attributes in the stanza itself or in child

elements of the stanza that are qualified by the content

namespaces "jabber:client" or "jabber:server" (e.g., the <body/>

child of the <message/> stanza).

An extension element or extension attribute is said to be "extended content" and the qualifying namespace for such an element or

attribute is said to be an "extended namespace".

Informational Note: Although extended namespaces for XMPP are commonly defined by the XMPP Standards Foundation (XSF) and by the IETF, no specification or IETF standards action is necessary to define extended namespaces, and any individual or organization is free to define XMPP extensions.

To illustrate these concepts, several examples follow.

The following stanza contains one direct child element whose extended namespace is ’jabber:iq:roster’:

<iq from=’juliet@capulet.com/balcony’

id=’h83vxa4c’

type=’get’>

</iq>

The following stanza contains two direct child elements with two different extended namespaces.

<c xmlns=’http://jabber.org/protocol/caps’

hash=’sha-1’

node=’http://code.google.com/p/exodus’

ver=’QgayPKawpkPSDYmwT/WM94uAlu0=’/>

<photo>sha1-hash-of-image</photo>

</x>

</presence>

The following stanza contains two child elements, one of which is qualified by the "jabber:client" or "jabber:server" content namespace and one of which is qualified by an extended namespace; the extension element in turn contains a child element that is qualified by a

different extended namespace.

<body>Hello?</body>

<p style=’font-weight:bold’>Hello?</p>

</body>

</html>

</message>

It is conventional in the XMPP community for implementations to not generate namespace prefixes for elements that are qualified by extended namespaces (in the XML community, this convention is sometimes called "prefix-free canonicalization"). However, if an implementation generates such namespace prefixes then it MUST include the namespace declaration in the stanza itself or a child element of the stanza, not in the stream header (see Section 4.8.4).

Routing entities (typically servers) SHOULD try to maintain prefixes when serializing XML stanzas for processing, but receiving entities MUST NOT depend on the prefix strings to have any particular value (the allowance for the ’stream’ prefix, described under

Section 4.8.5, is an exception to this rule, albeit for streams rather than stanzas).

Support for any given extended namespace is OPTIONAL on the part of any implementation. If an entity does not understand such a

namespace, the entity’s expected behavior depends on whether the entity is (1) the recipient or (2) a server that is routing or delivering the stanza to the recipient.

If a recipient receives a stanza that contains an element or

attribute it does not understand, it MUST NOT attempt to process that XML data and instead MUST proceed as follows.

o If an intended recipient receives a message stanza whose only child element is qualified by a namespace it does not understand, then depending on the XMPP application it MUST either ignore the entire stanza or return a stanza error, which SHOULD be unavailable/> (Section 8.3.3.19).

o If an intended recipient receives a presence stanza whose only child element is qualified by a namespace it does not understand, then it MUST ignore the child element by treating the presence stanza as if it contained no child element.

o If an intended recipient receives a message or presence stanza that contains XML data qualified by a namespace it does not understand, then it MUST ignore the portion of the stanza qualified by the unknown namespace.

o If an intended recipient receives an IQ stanza of type "get" or "set" containing a child element qualified by a namespace it does not understand, then the entity MUST return an IQ stanza of type "error" with an error condition of <service-unavailable/>.

If a server handles a stanza that is intended for delivery to another entity and that contains a child element it does not understand, it MUST route the stanza unmodified to a remote server or deliver the stanza unmodified to a connected client associated with a local account.

Dans le document It represents the consensus of the IETF community (Page 125-128)