<abstract>This specification defines a protocol extension to request URLs from an external HTTP entity usable to initiate and invite participants to an online meeting.</abstract>
<p>XMPP protocol extensions already defines a method for initiating peer-to-peer media sessions such as &xep0166; however due to its very nature of being peer-to-peer it presents a few challenges in scenarios with online meetings that depend on a central Selective Forwarding Unit (SFU) or a Multipoint Control Unit (MCU) to host the meeting..</p>
<p>Using a web browser to manually request a meeting URL from an HTTP server and sharing the link has been a workaround for this for a long time now. While users have a variety of services to choose from, the downside of this manual approach is that an XMPP client can not automate this process on behalf of the user since these services don’t share a common API.</p>
<p>This XEP defines an approach to request initiation of an online meeting via an HTTP server and receive a URL can be used to join and invite others to the meeting. It has two main features:</p>
<ol>
<li>An IQ-based protocol to request a meeting link from a server.</li>
<li>An element that can be added to a message stanza for sending the received meeting link to another party</li>
</ol>
<p>
The second feature is achieved by using &xep0482;, which describes
call invites using Jingle and external URIs. The XEP mentions how a web URLs can be used as external URI to join a call. For completeness, an example is repeated here to explicitly show how meeting invitations should be sent to invitees.
</p>
<p>
&xep0482; has other call mangement features, like announcing call join and
leave on the XMPP side. These are relevant for online meetings when the website behind the URL is opened
in a frame or similar inside the XMPP client. The meeting host xmpp client can track meeting participants and know when users leave the meeting without having to depend on APIs provided by the meeting service provider which may present cross-domain challenges.
For completeness, examples are also repeated in this XEP to explicity show their application for online meeting invitations.
<p>An entity advertises support for meeting initiation, as specified by this protocol, by including the "urn:xmpp:http:online-meetings:initiate:0" namespace, as well as "urn:xmpp:http:online-meetings#xxxxxx" (where xxxxx is the name of the supported meeting service) namespaces in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;.</p>
<p>A user’s server SHOULD include itself as a services provider for this protocol in its service discovery items.</p>
<examplecaption="Client sends service discovery request to server"><![CDATA[
<p>If an entity supports receiving meeting invitations as specified by this protocol, it advertises support by including the "urn:xmpp:http:online-meetings:invite:0" in its service discovery information features as specified in &xep0030; or section 6.3 of &xep0115;. Support for specific meeting services can be specified by including the corresponding "urn:xmpp:http:online-meetings#xxxxxx" namespaces.</p>
<examplecaption="Client sends service discovery request to invitee"><![CDATA[
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section2>
</section1>
<section1topic="Requesting a Meeting"anchor="request">
<p>A client requests an online new meeting to be initiated by sending an IQ-get to the server containing a <query> child element qualified by the 'urn:xmpp:http:online-meetings:invite:0' namespace.</p>
<p>This 'query' MUST include the type attribute specifying the Meeting Service type, which SHOULD be registered as described in the <linkurl="#registrar-type">Meeting Service Type Registry</link> section of this document.</p>
<examplecaption="Client requests the server to initiate a new online meeting."><![CDATA[
<iqfrom='romeo@montague.tld/garden'
to='montague.tld'
id='initiate_01'
type='get'>
<queryxmlns='urn:xmpp:http:online-meetings:0'
type='jitsi'/>
</iq>]]></example>
<p>If the requesting entity desires to (re)initiate a meeting with a specific identifier, the optional 'id' attribute can be used to specify the identity of the online meeting requested. When the provided value cannot be used, for example when it does not match the format used by a meeting provider, or a meeting with that particular value is already in use, the server SHOULD return an error.</p>
<examplecaption="Client requests a URL for a meeting with a specific ID from the server"><![CDATA[
<iqfrom='romeo@montague.tld/garden'
to='montague.tld'
id='initiate_02'
type='get'>
<queryxmlns='urn:xmpp:http:online-meetings:0'
type='jitsi'
id='my_meeting'/>
</iq>]]></example>
<p>An optional 'desc' child element can be used to assign a human-readable description to the meeting. The server MAY use this value when configuring the online meeting with the service provider, and SHOULD use this value in its response, but otherwise treat this as an opaque value.</p>
<examplecaption="Client uses the optional 'desc' when requesting a meeting to be initiated."><![CDATA[
<iqfrom='romeo@montague.tld/garden'
to='montague.tld'
id='initiate_03'
type='get'>
<queryxmlns='urn:xmpp:http:online-meetings:0'
type='jitsi'>
<desc>Meeting room for Open Standards discussion</desc>
<p>The XMPP server responds with one or two child elements: a 'initiate' element that contains a URL to be used to create and configure the meeting, and an 'invite' element as specified by &xep0482; to invite others into the meeting.</p>
<p>In the URLs that it returns, the server MAY specify a web-based protocol handler if available and registered by the user. Otherwise, standard HTTPS protocol will be specified. In any case, the fully resolved URL provided by the host MUST provide Transport Layer Security (&rfc5246;). The HTTPS URL MUST adhere to &rfc3986;. Non ASCII characters MUST be percent-encoded.</p>
<p>The XMPP server MAY be tightly integrated with the Meeting Provider and facilitate registration, configuration and association of a web-based protocol handler, but the protocol to implement such integration is out of scope of this document.</p>
<p>If the XMPP server is tightly integrated with the Meeting Provider, and no other data is needed for a meeting to be initiated, the XMPP server MAY initiate a meeting on behalf of the requester and leave out the 'initiate' element from the response. Note that a server SHOULD include a 'initiate' URL in its response if it cannot initiate a meeting on behalf of the requesting entity, even if it knows that no additional data is needed for a meeting to be automatically initiated upon joining the meeting URL. Inclusion of the 'initiate' element signals that the requesting entity may need join the meeting as the first participant, in order to be assigned 'creator' or 'moderator' privileges.</p>
</section1>
<section1topic="Error conditions"anchor="errors">
<p>Instead of providing the client with a URL the server MAY respond with an error if the request fails. In addition, the HTTP entity MAY inform the requester about the reason for the failure.</p>
<examplecaption="Alternative response by the server if the meeting initiation request includes unsupported type"><![CDATA[
<textxmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Meeting is in use</text>
</error>
</iq>]]></example>
<p>For any other type of error the service SHOULD respond with appropriate error types to indicate temporary or permanent errors.</p>
<p>For temporary errors such as exceeding a personal quota the service MAY include a <retry/> element qualified by the 'urn:xmpp:http:online-meetings:0' namespace as a child of the <error/> element. The retry element MUST include an attribute 'stamp' which indicates the time at which the requesting entity may try again. The format of the timestamp MUST adhere to the date-time format specified in &xep0082; and MUST be expressed in UTC.</p>
<examplecaption="Alternative response by the server to indicate a temporary error after the client exceeded a quota"><![CDATA[
<p>After the requesting entity has successfully initiated a meeting, it MAY invite other entities to join the meeting using the 'invite' element it received to propose the meeting</p>
<p>To allow users of clients that do not support &xep0482; to receive the invitation, a &xep0066; element and/or a 'body' element containing the meeting details MAY be included.</p>
<p>There is no further XMPP communication required between the server and the requesting entity for participants to join the meeting. The actual online meeting engagement with the provided URL is out of scope of this document.</p>
<section2topic="Proposing a meeting"anchor="meeting-proposal">
<p>
Invitees are sent a message containing an <invite> element in the urn:xmpp:call-invites:0
namespace. For online meetings, the audio video attributes should default to "true".
</p><p>
The <invite> element contains sub-elements <external> and <meeting> to provide the meeting URL and the identity of the meeting service provider.
<meetingtype='jitsi'desc='Meeting room for Open Standards discussion'/>
</accept>
</message>]]></example>
<p>
After the <accept> was sent, the accepting client handles the URI. The exact behaviour of opening the URI is implementation specific and can be determined from the type attribute of the <meeting> element.
</p>
</section2>
<section2topic="Rejection a meeting invitation"anchor="meeting-rejection">
<p>
A meeting invitation can be rejected by sending a message containing a <reject> element with an 'id' attribute
containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace.
</p>
<examplecaption="Rejecting a meeting invitation"><