XEP-0483: HTTP Online Meetings

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.
Authors
  • Dele Olajide
  • Guus der Kinderen
Copyright
© 2023 – 2023 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
Type
Standards Track
Version
0.2.0 (2023-12-12)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

XMPP protocol extensions already defines a method for initiating peer-to-peer media sessions such as Jingle (XEP-0166) [1] 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..

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.

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:

  1. An IQ-based protocol to request a meeting link from a server.
  2. An element that can be added to a message stanza for sending the received meeting link to another party

The second feature is achieved by using Call Invites (XEP-0482) [2], 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.

Call Invites (XEP-0482) [2] 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.

2. Requirements

3. Discovering Support

3.1 Meeting Initiation

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 Service Discovery (XEP-0030) [3] or section 6.3 of Entity Capabilities (XEP-0115) [4].

A user’s server SHOULD include itself as a services provider for this protocol in its service discovery items.

Example 1. Client sends service discovery request to server
<iq from='romeo@montague.tld/garden'
    to='montague.tld'
    id='disco_01'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
Example 2. Server replies to service discovery request and reports capability to initiate online meetings for Jitsi and Galene
<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>

3.2 Invitation

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 Service Discovery (XEP-0030) [3] or section 6.3 of Entity Capabilities (XEP-0115) [4]. Support for specific meeting services can be specified by including the corresponding "urn:xmpp:http:online-meetings#xxxxxx" namespaces.

Example 3. Client sends service discovery request to invitee
<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 4. Client replies to service discovery request and reports capability to accept invitations for online meeting for Jitsi.
<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>

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 Entity Capabilities (XEP-0115) [4]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

4. Requesting a Meeting

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.

This 'query' MUST include the type attribute specifying the Meeting Service type, which SHOULD be registered as described in the Meeting Service Type Registry section of this document.

Example 5. Client requests the server to initiate a new online meeting.
<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>

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.

Example 6. Client requests a URL for a meeting with a specific ID from the server
<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>

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.

Example 7. Client uses the optional 'desc' when requesting a meeting to be initiated.
<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>
  </query>	
</iq>

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 Call Invites (XEP-0482) [2] to invite others into the meeting.

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 (RFC 5246 [5]). The HTTPS URL MUST adhere to RFC 3986 [6]. Non ASCII characters MUST be percent-encoded.

Example 8. The server responds with an out of band URI specifying a registered jitsi web-based protocol handler
<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:OpenStandardsMuchGreatness</url>
      <desc>Meeting room for Open Standards discussion</desc>
    </initiate>
    <invite xmlns='urn:xmpp:call-invites:0'>
	  <external uri='web+jitsi:OpenStandardsMuchGreatness' />
	  <meeting xmlns='urn:xmpp:http:online-meetings:0' 
               type='jitsi' 
               desc='Meeting room for Open Standards discussion' />
    </invite>  	
  </query>
</iq>
Example 9. The server responds with an out of band URI using standard HTTPS
<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 xmlns='urn:xmpp:call-invites:0'>
	  <external uri='https://meet.jit.si/OpenStandardsMuchGreatness' />
	  <meeting xmlns='urn:xmpp:http:online-meetings:0' 
               type='jitsi' 
               desc='Meeting room for Open Standards discussion' />
    </invite>  
  </query>
</iq>

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.

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.

5. Error conditions

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.

Example 10. Alternative response by the server if the meeting initiation request includes unsupported type
<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 11. Alternative response by the server if the meeting initiation request fails due to meeting ID collision
<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>

For any other type of error the service SHOULD respond with appropriate error types to indicate temporary or permanent errors.

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 XMPP Date and Time Profiles (XEP-0082) [7] and MUST be expressed in UTC.

Example 12. Alternative response by the server to indicate a temporary error after the client exceeded a quota
<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 13. Alternative response by the server to indicate an auth error to a client that is not allowed to initiate an online meeting
<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>

6. Meeting Invitation

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

To allow users of clients that do not support Call Invites (XEP-0482) [2] to receive the invitation, a Out-of-Band Data (XEP-0066) [8] element and/or a 'body' element containing the meeting details MAY be included.

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.

6.1 Proposing a meeting

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".

The <invite> element contains sub-elements <external> and <meeting> to provide the meeting URL and the identity of the meeting service provider.

Example 14. User sends meeting invitation
<message
    id='invite_01'
    from='romeo@montague.tld/garden'
    to='juliet@capulet.example/balcony'>
  <invite xmlns='urn:xmpp:call-invites:0'>
    <external uri='https://meet.jit.si/OpenStandardsMuchGreatness' />
    <meeting xmlns='urn:xmpp:http:online-meetings:0' 
             type='jitsi' 
             desc='Meeting room for Open Standards discussion' />
  </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>

6.2 Retracting a meeting invitation

A meeting invitation can be retracted by sending a message containing a <retract> element with an 'id' attribute containing the id of the invite message qualified by the urn:xmpp:call-invites:0 namespace.

Example 15. Retracting a meeting
<message to='juliet@capulet.example/balcony'>
  <retract id='invite_01' xmlns='urn:xmpp:call-invites:0' />
</message>

6.3 Accepting a meeting invitation

A meeting invitation can be accepted by sending a message containing an <accept> element with an 'id' attribute containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. The <external> and <meeting> elements from the invitation are placed in the <accept> element as specified in Call Invites (XEP-0482) [2].

Example 16. Accepting a meeting invitation
<message to='romeo@montague.tld/garden'>
  <accept id='invite_01' xmlns='urn:xmpp:call-invites:0'>
    <external uri='https://meet.jit.si/OpenStandardsMuchGreatness' />
    <meeting type='jitsi' desc='Meeting room for Open Standards discussion' />
  </accept>
</message>

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.

6.4 Rejection a meeting invitation

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.

Example 17. Rejecting a meeting invitation
<message to='romeo@montague.tld/garden'>
  <reject id='invite_01' xmlns='urn:xmpp:call-invites:0' />
</message>

6.5 Leaving a meeting

When a meeting participant leaves a meeting, it sends a message containing a <left> element with an 'id' attribute containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace.

Example 18. Leaving a meeting
<message to='romeo@montague.tld/garden'>
  <left id='invite_01' xmlns='urn:xmpp:call-invites:0' />
</message>

7. Implementation Notes

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.

8. Security Considerations

8.1 General

9. IANA Considerations

This document requires no interaction with the the Internet Assigned Numbers Authority (IANA) [9]

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

This specification defines the following XML namespaces:

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [10] shall add the foregoing namespace to the registry located at <https://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function (XEP-0053) [11].

10.2 Meeting Serviced Type Registry

The XMPP Registrar maintains a registry of Meeting provider types at TBD.

11. XML Schema

<xml version="1.0" encoding="utf8">
<!-- TBD -->

Appendices

Appendix A: Document Information

Series
XEP
Number
0483
Publisher
XMPP Standards Foundation
Status
Experimental
Type
Standards Track
Version
0.2.0
Last Updated
2023-12-12
Approving Body
XMPP Council
Dependencies
None
Supersedes
None
Superseded By
None
Short Name
http_online-meetings
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Dele Olajide
Email
dele@olajide.net
JabberID
dele.olajide@igniterealtime.org
Guus der Kinderen
Email
guus.der.kinderen@gmail.com
JabberID
guus.der.kinderen@igniterealtime.org

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0166: Jingle <https://xmpp.org/extensions/xep-0166.html>.

2. XEP-0482: Call Invites <https://xmpp.org/extensions/xep-0482.html>.

3. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

4. XEP-0115: Entity Capabilities <https://xmpp.org/extensions/xep-0115.html>.

5. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <http://tools.ietf.org/html/rfc5246>.

6. RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax <http://tools.ietf.org/html/rfc3986>.

7. XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>.

8. XEP-0066: Out of Band Data <https://xmpp.org/extensions/xep-0066.html>.

9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

11. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.2.0 (2023-12-12)
    do
  2. Version 0.1.0 (2023-12-11)
    XEP Editor: kis
  3. Version 0.0.3 (2023-09-12)
    gdk
  4. Version 0.0.2 (2023-08-22)
    do
  5. Version 0.0.1 (2023-08-21)
    do

Appendix I: Bib(La)TeX Entry

@report{olajide2023http_online-meetings,
  title = {HTTP Online Meetings},
  author = {Olajide, Dele and der Kinderen, Guus},
  type = {XEP},
  number = {0483},
  version = {0.2.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0483.html},
  date = {2023-08-21/2023-12-12},
}

END