xeps/inbox/xep-http_online_meetings.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
  %ents;
  ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep xmlns="">
<header>
  <title>HTTP Online Meetings</title>
  <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>
  &LEGALNOTICE;
  <number>XXXX</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies/>
  <supersedes/>
  <supersededby/>
  <shortname>http_online-meetings</shortname>
  <author>
    <firstname>Dele</firstname>
    <surname>Olajide</surname>
    <email>dele@olajide.net</email>
    <jid>dele.olajide@igniterealtime.org</jid>
  </author>
  <author>
    <firstname>Guus</firstname>
    <surname>der Kinderen</surname>
    <email>guus.der.kinderen@gmail.com</email>
    <jid>guus.der.kinderen@igniterealtime.org</jid>
  </author>
  <revision>
    <version>0.0.3</version>
    <date>2023-09-12</date>
    <initials>gdk</initials>
    <remark>
      <ul>
        <li>Modified wording of abstract.</li>
        <li>Specified distribution of URL / add meeting invitation</li>
        <li>Differentiate between Meeting service providers that are integrated with XMPP server, and those that are not.</li>
        <li>Differentiate between URL to create and join meeting</li>
        <li>Replaced textual references with XML entities</li>
        <li>Introduced distinct namespaces for create and invite, retaining type-specific namespaces for feature discovery</li>
        <li>Introduced Meeting Service type registry</li>
        <li>Removed CORS-related implementation note</li>
        <li>Meeting ID in request now optional</li>
        <li>Add optional 'desc' in the meeting request.</li>
        <li>Moved IQ child elements into a wrapper, renamed 'create' element to 'initiate'</li>
        <li>Add fall-back body element to invite message stanza.</li>
        <li>Removed dependency on XEP-0066.</li>
      </ul>
    </remark>
  </revision>
  <revision>
    <version>0.0.2</version>
    <date>2023-08-22</date>
    <initials>do</initials>
    <remark>
      <ul>
        <li>Remove base URL attribute.</li>
        <li>Add support for a web-based protocol handler in OOB data result.</li>
      </ul>
    </remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2023-08-21</date>
    <initials>do</initials>
    <remark>
      <ul>
        <li>Initial version.</li>
      </ul>
    </remark>
  </revision>
</header>
<section1 topic="Introduction" anchor="intro">
  <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 does not work very well in scenarios with online meetings. It also does not work alongside offline storage, MUC history and &xep0313;.</p>
  <p>Using a web browser to manually request a 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.</p>
</section1>
<section1 topic="Requirements" anchor="reqs">
  <ul>
    <li>Be as easy to implement as possible. This is grounded on the idea that most programming languages already have HTTP libraries available.</li>
    <li>Usable with Meeting service providers that have no XMPP integration.</li>
    <li>Anyone who knows the URL SHOULD be able to access it.</li>
  </ul>
</section1>
<section1 topic="Discovering Support" anchor="disco">
  <section2 topic="Meeting Initiation" anchor="disco-initiation">
    <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>
    <example caption="Client sends service discovery request to server"><![CDATA[
<iq from='romeo@montague.tld/garden'
    to='montague.tld'
    id='disco_01'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
    <example caption="Server replies to service discovery request and reports capability to initiate online meetings for Jitsi and Galene"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='disco_01'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='server'
        type='im'
        name='Openfire Server'/>
    <feature var='urn:xmpp:http:online-meetings:initiate:0'/>
    <feature var='urn:xmpp:http:online-meetings#jitsi'/>
    <feature var='urn:xmpp:http:online-meetings#galene'/>
  </query>
</iq>]]></example>
  </section2>
  <section2 topic="Invitation" anchor="disco-server">
    <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>
    <example caption="Client sends service discovery request to invitee"><![CDATA[
<iq from='romeo@montague.tld/garden'
    to='juliet@capulet.example/balcony'
    id='disco_02'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
    <example caption="Client replies to service discovery request and reports capability to accept invitations for online meeting for Jitsi."><![CDATA[
<iq from='juliet@capulet.example/balcony'
    to='romeo@montague.tld/garden'
    id='disco_02'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='client'
        type='im'
        name='Spark'/>
    <feature var='urn:xmpp:http:online-meetings:invite:0'/>
    <feature var='urn:xmpp:http:online-meetings#jitsi'/>
  </query>
</iq>]]></example>
    <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>
<section1 topic="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 &lt;query&gt; 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 <link url="#registrar-type">Meeting Service Type Registry</link> section of this document.</p>
  <example caption="Client requests the server to initiate a new online meeting."><![CDATA[
<iq from='romeo@montague.tld/garden'
    to='montague.tld'
    id='initiate_01'
    type='get'>
  <query xmlns='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>
  <example caption="Client requests a URL for a meeting with a specific ID from the server"><![CDATA[
<iq from='romeo@montague.tld/garden'
    to='montague.tld'
    id='initiate_02'
    type='get'>
  <query xmlns='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>
  <example caption="Client uses the optional 'desc' when requesting a meeting to be initiated."><![CDATA[
<iq from='romeo@montague.tld/garden'
    to='montague.tld'
    id='initiate_03'
    type='get'>
  <query xmlns='urn:xmpp:http:online-meetings:0'
         type='jitsi'>
    <desc>Meeting room for Open Standards discussion</desc>
</iq>]]></example>
  <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 that contains a URL suitable 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>
  <example caption="The server responds with an out of band URI specifying the jitsi web-based protocol handler"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_03'
    type='result'>
  <query xmlns='urn:xmpp:http:online-meetings:0'>
    <initiate type='jitsi'>
      <url>web+jitsi:https://meet.jit.si/OpenStandardsMuchGreatness</url>
      <desc>Meeting room for Open Standards discussion</desc>
    </initiate>
    <invite type='jitsi'>
      <url>web+jitsi:https://meet.jit.si/OpenStandardsMuchGreatness</url>
      <desc>Meeting room for Open Standards discussion</desc>
    </invite>
  </query>
</iq>]]></example>
  <example caption="The server responds with an out of band URI using standard HTTPS"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_03'
    type='result'>
  <query xmlns='urn:xmpp:http:online-meetings:0'>
    <initiate type='jitsi'>
      <url>https://meet.jit.si/OpenStandardsMuchGreatness</url>
      <desc>Meeting room for Open Standards discussion</desc>
    </initiate>
    <invite type='jitsi'>
      <url>https://meet.jit.si/OpenStandardsMuchGreatness</url>
      <desc>Meeting room for Open Standards discussion</desc>
    </invite>
  </query>
</iq>]]></example>
  <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>
<section1 topic="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>
  <example caption="Alternative response by the server if the meeting initiation request includes unsupported type"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_01'
    type='error'>
  <query xmlns='urn:xmpp:http:online-meetings:0'
         type='jitsi'/>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>The 'jitsi' meeting service provider type is not supported.</text>
  </error>
</iq>]]></example>
  <example caption="Alternative response by the server if the meeting initiation request fails due to meeting ID collision"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_02'
    type='error'>
  <query xmlns='urn:xmpp:http:online-meetings:0'
         type='jitsi'
         id='my-meeting'/>
  <error type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='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 &lt;retry/&gt; element qualified by the 'urn:xmpp:http:online-meetings:0' namespace as a child of the &lt;error/&gt; 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>
  <example caption="Alternative response by the server to indicate a temporary error after the client exceeded a quota"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_01'
    type='error'>
  <query xmlns='urn:xmpp:http:online-meetings:0'
         type='jitsi'/>
  <error type='wait'>
    <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Quota reached. You can only request 5 meetings a day</text>
    <retry xmlns='urn:xmpp:http:online-meetings:0' stamp='2017-12-03T23:42:05Z'/>
  </error>
</iq>]]></example>
  <example caption="Alternative response by the server to indicate an auth error to a client that is not allowed to initiate an online meeting"><![CDATA[
<iq from='montague.tld'
    to='romeo@montague.tld/garden'
    id='initiate_01'
    type='error'>
  <query xmlns='urn:xmpp:http:online-meetings:0'
         type='jitsi'/>
  <error type='auth'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Only premium members are allowed to initiate meetings</text>
  </error>
</iq>]]></example>
</section1>
<section1 topic="Meeting Invitation" anchor="meeting-invitation">
  <p>After the requesting entity has successfully initiated a meeting, it MAY invite other entities to join the meeting. It does so by sending invitees a message stanza containing an 'invite' child element, qualified by the online-meetings namespace, as was sent by the server in response to the initiation request.</p>
  <p>To allow users of clients that do not support this XEP to receive the invitation, a &xep0066; element and/or a 'body' element containing the meeting details MAY be included.</p>
  <example caption="User sends meeting invitation"><![CDATA[
<message
    from='romeo@montague.tld/garden'
    to='juliet@capulet.example/balcony'>
  <invite xmlns='urn:xmpp:http:online-meetings:0'
          type='jitsi'>
    <url>https://meet.jit.si/OpenStandardsMuchGreatness</url>
    <desc>Meeting room for Open Standards discussion</desc>
  </invite>
  <x xmlns='jabber:x:oob'>
    <url>https://meet.jit.si/OpenStandardsMuchGreatness</url>
    <desc>Meeting room for Open Standards discussion</desc>
  </x>
  <body>You are invited to join 'Meeting room for Open Standards discussion' at https://meet.jit.si/OpenStandardsMuchGreatness</body>
</message>]]></example>
  <p>There is no further XMPP communication required between the server and the client for the client to join the meeting. The actual online meeting engagement with the provided URL is out of scope of this document.</p>
</section1>
<section1 topic="Implementation Notes" anchor="impl">
  <p>The server SHOULD choose an appropriate timeout for the validity of the URL. Since there is no reason for a client to wait between requesting the URL and joining the meeting via the URL before dispatching invitations, relatively low timeout values of around 300s are RECOMMENDED.</p>
</section1>
<section1 topic="Security Considerations" anchor="security">
  <section2 topic="General" anchor="general">
    <ul>
      <li>Service implementors SHOULD use long randomized parts in their URLs making it impossible to guess the location of arbitrary meeting url.</li>
      <li>Implementors should keep in mind, that without additional end-to-end-encryption, online meetings may not be secure. Client implementors are advised to either use this only for semi public meetings (for example meetings hosted on a public MUC) or implement appropriate end-to-end encryption.</li>
      <li>Joining an HTTP Online Meeting will leak the client’s IP address to the HTTP service. The HTTP service might not be the same service as the XMPP service the client is currently connected to.</li>
  </ul>
  </section2>
</section1>
<section1 topic="IANA Considerations" anchor="iana">
  <p>This document requires no interaction with the &IANA;</p>
</section1>
<section1 topic="XMPP Registrar Considerations" anchor="registrar">
  <section2 topic="Protocol Namespaces" anchor="registrar-ns">
    <p>This specification defines the following XML namespaces:</p>
    <ul>
      <li>urn:xmpp:http:online-meetings:0</li>
      <li>urn:xmpp:http:online-meetings:initiate:0</li>
      <li>urn:xmpp:http:online-meetings:invite:0</li>
      <li>urn:xmpp:http:online-meetings#jitsi</li>
      <li>urn:xmpp:http:online-meetings#galene</li>
    </ul>
    <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
  </section2>
  <section2 topic="Meeting Serviced Type Registry" anchor="registrar-type">
    <p>The XMPP Registrar maintains a registry of Meeting provider types at TBD.</p>
  </section2>
</section1>
<section1 topic="XML Schema" anchor="schema">
  <code><![CDATA[
<xml version="1.0" encoding="utf8">
<!-- TBD -->
]]></code>
</section1>
</xep>