A session owner uses the <jinglepub/> element to announce that it can initiate a specific Jingle session request. This element can be sent to a publish-subscribe node (see &xep0060; and &xep0163;), or sent directly to potential recipients within a &MESSAGE; stanza.

The format of the <jinglepub/> element is as follows:

The 'from' attribute MUST be present and MUST be the valid JID for the session owner.

The 'id' attribute is an opaque identifier, called the "jinglepub identifier". This attribute MUST be present, and MUST be a valid non-empty string. It uniquely identifies the published request at the session owner's JID.

The <jinglepub/> element MUST contain a <description/> element qualified by the namespace of the relevant Jingle application format (e.g., <description xmlns='urn:xmpp:jingle:apps:file-transfer:4'/> for file transfer).

The <jinglepub/> element MAY contain one or more <meta/> elements qualified by the jingle-pub namespace; if more than one element is included, each element MUST have a different value for the 'xml:lang' attribute.

The <jinglepub/> element MAY contain a <uri/> element which contains a URI for an alternative way to access the content, or other information about the content. The resource provided by the URI SHOULD be meaningful for clients that do not directly support the included Jingle content definitions, and accessing the URI MAY result in a different experience than initiating the published Jingle session. For example, the URI could be to a content landing page of an image hosting service from which an image could be viewed instead of directly downloading the image file.

The <jinglepub/> information is typically provided via pubsub.

The following example shows a possible payload for streaming of recorded audio/video sessions, here pushed out via PEP.

The <jinglepub/> element MAY also be included directly within a &MESSAGE; stanza sent to another entity (or multiple entities, e.g., in &xep0045;). This can be especially useful for informing an offline entity about an available stream.

In general, the process to trigger a stream initiation request is as follows:

A potential receiver requests initiation of the session by sending an IQ-get to the sender, using the <start xmlns='urn:xmpp:jinglepub:1'/> element. This element contains the 'id' attribute to specify which published stream to retrieve:

If the sender accepts the request, it responds with an IQ-result containing a <starting/> element. This element indicates the session identifier to be used:

Then the sender initiates the Jingle session:

If the requested identifier is not valid, the sender SHOULD respond with a ¬acceptable; error:

If the receiver does not have permission to request the data stream, the sender SHOULD respond with a &forbidden; error:

This document defines the 'jingle' XMPP URI/IRI querytype, which MUST posses an 'id' key/value pair, whose value is the "jinglepub identifier".

The information found in such an URI, an XMPP address and a "jinglepub identifier", can be used to trigger an an Jingle session initation request as specified in § 2.2. This Jingle session can be used to transfer files (&xep0234;), audio and video streams (&xep0167;) and other Jingle application formats.

The ®ISTRAR; will be requested to include 'urn:xmpp:jinglepub:1' in its registry of protocol namespaces.

As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).The following submission registers the 'jingle' querytype.