%ents; ]>
Publishing Available Jingle Sessions This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Jingle session request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the Jingle File Transfer protocol defined in XEP-0234. &LEGALNOTICE; 0358 Experimental Standards Track Standards XMPP Core XEP-0030 XEP-0234 jinglepub &fippo; &lance; &stpeter; 0.3 2016-05-24 fs

Add Jingle query type and XMPP registrar submission.

0.2 2015-08-11 ls

Add <uri/> element.

0.1 2015-06-29 XEP Editor (psa)

Initial published version approved by the XMPP Council.

0.0.2 2014-08-12 ls/psa/ph
  • Changed payload to use one or more Jingle <description/> elements (this provides support for content with multiple media types, such as audio+video).
  • Removed 'app' attribute, since we include the application-format description as a child element.
  • Removed 'mime-type' attribute, since it can be signalled in the application-format description if needed.
  • Added <meta/> element to provide human-friendly information about the session.
  • Incremented the protocol version number from 0 to 1.
0.0.1 2014-07-30 ph/ls/psa First draft.

This document defines a way for an entity that can initiate a &xep0166; session (often for the purpose of file transfer as specified in &xep0234;) to advertise that session, thus enabling a receiver to then request initiation of the session by the sender. In essence, this document defines the Jingle equivalent of &xep0137; (previously defined for &xep0095;).

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:

[ element for an alternate or informational URI of the content] [ element(s) for human-friendly information] [ element(s) for application format(s)] ]]>

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

The 'id' attribute is an opaque 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.

]]>

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:

128 ]]>

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

9559976B-3FBF-4E7E-B457-2DAA225972BB ]]>

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

9559976B-3FBF-4E7E-B457-2DAA225972BB ]]>

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

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.

This document introduces no security concerns beyond those specified in XEP-0060 and the relevant Jingle application format in use.

This document requires no interaction with &IANA;.

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.

jingle urn:xmpp:jinglepub:1 enables retrieving Jingle sessions (file transfer, etc.) XEP-0358 id The 'jinglepub' identifier ]]>
]]>