%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; xxxx ProtoXEP Standards Track Standards XMPP Core XEP-0030 XEP-0234 jinglepub &fippo; &lance; &stpeter; 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 Jingle 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(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/> 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 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.

 ]]>