mirror of https://github.com/moparisthebest/xeps
Merge branch 'protoxeps-marvin' into premerge
This commit is contained in:
Jonas Schäfer
commit
3fd3d27117
|
|
@ -0,0 +1,199 @@
|
|||
<?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>
|
||||
<header>
|
||||
<title>Call Invites</title>
|
||||
<abstract>
|
||||
This document defines how to invite someone to a call and how to respond to the invite.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies/>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>call-invites</shortname>
|
||||
<author>
|
||||
<firstname>Natalie</firstname>
|
||||
<surname>Wirth</surname>
|
||||
<email>nataliew@laposte.net</email>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Marvin</firstname>
|
||||
<surname>Wissfeld</surname>
|
||||
<email>xsf@larma.de</email>
|
||||
<jid>jabber@larma.de</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2022-01-01</date>
|
||||
<initials>nw/mw</initials>
|
||||
<remark>
|
||||
<p>First draft.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
A call can take place between two or more parties and can be initiated and conducted via various protocols. This
|
||||
specification defines a way to invite someone to a call providing one or more ways in which to join.
|
||||
</p>
|
||||
<p>
|
||||
&xep0353; provides partially overlapping functionality. It allows to initiate any kind of Jingle session, for
|
||||
example calls but also file transfers. However, it is not suitable for inviting someone to any kind of call, since
|
||||
a call can also be established through other means than a simple Jingle session-initiate.
|
||||
</p>
|
||||
<p>
|
||||
This specification defines a way to invite someone to a call. The call can for example be initiated via &xep0167;
|
||||
or via an external URI. It also allows to define multiple ways to join the same call. Furthermore, it defines how
|
||||
to retract, accept and reject the call invite and how to indicate that a client left the call.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
|
||||
<section2 topic='Proposing a call'>
|
||||
<p>
|
||||
To invite someone to a call, a message containing an <invite> element in the urn:xmpp:call-invites:0
|
||||
namespace is sent. The element has an optional 'video' attribute that indicates if the call is intended to be
|
||||
joined with participants sending video ("true") or not ("false", default). An 'audio' attribute is defined
|
||||
analogously, defaulting to "true". The <invite> element contains one sub-element for each way to join the
|
||||
call.
|
||||
</p>
|
||||
<p>
|
||||
In order to invite someone to a &xep0167; call, a <jingle> element is placed in the <invite>
|
||||
element. The <jingle> element has a 'sid' attribute specifying the ID of the Jingle session. It can
|
||||
optionally also contain a 'jid' element, to indicate the JID the Jingle session will be initiated from. If no
|
||||
'jid' element is provided, the default is the sender of the message stanza.
|
||||
</p>
|
||||
<example caption="Invite to a Jingle video call"><![CDATA[
|
||||
<message to='mara@example.com' id='id1' type='chat'>
|
||||
<invite video='true' xmlns='urn:xmpp:call-invites:0'>
|
||||
<jingle sid='sid1'/>
|
||||
</invite>
|
||||
</message>]]></example>
|
||||
|
||||
<p>
|
||||
External ways to join the call can be specified via an <external> element placed in the <invite>
|
||||
element with an 'uri' attribute that contains a URI. The URI can for example contain a URL to a browser
|
||||
webclient or a dial-in telephone number.
|
||||
</p>
|
||||
|
||||
<example caption="Invite to a mixer groupcall with webclient and dial-in fallback"><![CDATA[
|
||||
<message to='mara@example.com' id='id2' type='chat'>
|
||||
<invite xmlns='urn:xmpp:call-invites:0'>
|
||||
<jingle sid='sid2' jid='mixer@example.com/uuid' />
|
||||
<external uri='https://example.com/uuid' />
|
||||
<external uri='tel:+12345678' />
|
||||
</invite>
|
||||
</message>]]></example>
|
||||
|
||||
<p>
|
||||
Specifications that describe further ways to join a call define their own sub-elements to the <invite>
|
||||
element containing all necessary information for joining.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Retracting a call'>
|
||||
<p>
|
||||
A call invite 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.
|
||||
</p>
|
||||
<example caption="Retracting a call"><![CDATA[
|
||||
<message to='mara@example.com' type='chat'>
|
||||
<retract id='id1' xmlns='urn:xmpp:call-invites:0' />
|
||||
</message>]]></example>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Accepting a call'>
|
||||
<p>
|
||||
A call invite 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.
|
||||
</p>
|
||||
<p>
|
||||
The element describing the connection method used by the accepting client (e.g. <jingle> or <external>)
|
||||
including all of its attributes and children is placed in the <accept> element.
|
||||
</p>
|
||||
<example caption="Accepting a call"><![CDATA[
|
||||
<message to='mara@example.com' type='chat'>
|
||||
<accept id='id1' xmlns='urn:xmpp:call-invites:0'>
|
||||
<jingle sid='sid1' jid='mixer@example.com/uuid' />
|
||||
</accept>
|
||||
</message>]]></example>
|
||||
<p>
|
||||
After the <accept> was sent, the initiating or accepting client continues to establish the call depending
|
||||
on the selected connection method: If an <external> method was selected, the accepting client handles the
|
||||
URI. The exact behaviour of opening the URI is implementation specific. If a <jingle> method was selected,
|
||||
the initiating client triggers a Jingle session-initiate from the JID and with the session ID specified in the
|
||||
'jid' and 'sid' attributes of the <jingle> element, respectively.
|
||||
</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Rejecting a call'>
|
||||
<p>
|
||||
A call invite 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>
|
||||
<example caption="Rejecting a call"><![CDATA[
|
||||
<message to='mara@example.com' type='chat'>
|
||||
<reject id='id1' xmlns='urn:xmpp:call-invites:0' />
|
||||
</message>]]></example>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Leaving a call'>
|
||||
<p>
|
||||
When a client leaves a call, 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.
|
||||
</p>
|
||||
<example caption="Leaving a call"><![CDATA[
|
||||
<message to='mara@example.com' type='chat'>
|
||||
<left id='id1' xmlns='urn:xmpp:call-invites:0' />
|
||||
</message>]]></example>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>
|
||||
Clients must ensure that they will receive the accept or reject responses of other resources by the same user (if
|
||||
any) when implementing this specification. This can be achieved by implementing &xep0280;.
|
||||
</p>
|
||||
<section2 topic='Using the correct ID' anchor='business-id'>
|
||||
<p>
|
||||
For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be used for call retracts, accepts,
|
||||
rejects or lefts. Instead, in group chat situations, the ID assigned to the stanza by the group chat itself must
|
||||
be used. This is discovered in a <stanza-id> element with a 'by' attribute that matches the bare JID of
|
||||
the group chat, as defined in &xep0359;.
|
||||
</p>
|
||||
<p>
|
||||
This implies that invite messages should only be sent in group chats that attach a &xep0359; stanza-id.
|
||||
</p>
|
||||
<p>
|
||||
For other message types the sender should use the 'id' from a &xep0359;
|
||||
<origin-id> if present, or the value of the 'id' attribute on the
|
||||
<message> otherwise.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Security Considerations" anchor="security">
|
||||
<p>
|
||||
None.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>This document requires no interaction with ®ISTRAR;.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
<?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>
|
||||
<header>
|
||||
<title>Compatibility Fallbacks</title>
|
||||
<abstract>
|
||||
This document defines a way to indicate that a specific part of the body only serves as fallback and which
|
||||
specification the fallback is for.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies/>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>compat</shortname>
|
||||
<author>
|
||||
<firstname>Natalie</firstname>
|
||||
<surname>Wirth</surname>
|
||||
<email>nataliew@laposte.net</email>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Marvin</firstname>
|
||||
<surname>Wissfeld</surname>
|
||||
<email>xsf@larma.de</email>
|
||||
<jid>jabber@larma.de</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2022-01-01</date>
|
||||
<initials>nw/mw</initials>
|
||||
<remark>
|
||||
<p>First draft.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
New specifications can use the message body to convey intended meaning to users of non-supporting clients. This
|
||||
XEP provides a way to indicate which part of the body serves as fallback and which specification it provides a
|
||||
fallback for.
|
||||
</p>
|
||||
<p>
|
||||
This specification serves a different purpose than the similarly named &xep0428;. Fallback indication tells
|
||||
servers that the body is only a fallback and that clients implementing all the specifications used by the message
|
||||
will not make use of the message body. This specification tells clients that parts of the body are only included
|
||||
to aid clients not supporting a certain specification.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<p>
|
||||
To mark a specific text section in the body as a fallback, a <fallback> element in the urn:xmpp:compat:0
|
||||
namespace is placed in the message stanza. The <fallback> element has a 'for' attribute with an identifier
|
||||
of the specification the fallback is for. The <fallback> element contains one <body> element for each
|
||||
continuous character sequence in the body that is part of the fallback text. Each body element contains a 'start'
|
||||
and 'end' attribute which point to the start and end of a fallback character sequence as defined in &xep0426;,
|
||||
respectively.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For example, Juliet might be part of a group that shares news. Breaking news are indicated by a specific element
|
||||
and supporting clients can highlight them accordingly. To also inform users of non-supporting clients about the
|
||||
importance of a piece of news, the information is prefixed by "BREAKING NEWS: " in the body. A supporting client
|
||||
sees the <fallback> element and removes the respective character sequence before highlighting the message to
|
||||
the user.
|
||||
</p>
|
||||
|
||||
<example><![CDATA[
|
||||
<message to='news@muc.example.com/juliet' id='message-id2' type='chat'>
|
||||
<body>BREAKING NEWS: Romeo is dead.</body>
|
||||
<breaking xmlns='urn:example:breaking-news:0' />
|
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:example:breaking-news:0'>
|
||||
<body start='0' end='15' />
|
||||
</fallback>
|
||||
</message>]]></example>
|
||||
|
||||
<p>
|
||||
Another example are message replies, where a <reply> element specifies the referenced message. A simple
|
||||
fallback is to include a &xep0393; quote of the referenced message in the body text. To provide a better fallback,
|
||||
the sender can also include markup information for the quote.
|
||||
</p>
|
||||
|
||||
<example><![CDATA[
|
||||
<message to='anna@example.com' id='message-id2' type='groupchat'>
|
||||
<body>
|
||||
> Anna wrote:
|
||||
> Hi, how are you?
|
||||
Great
|
||||
</body>
|
||||
<reply to='anna@example.com' id='message-id1' xmlns='urn:xmpp:reply:0' />
|
||||
<markup xmlns="urn:example:markup:0">
|
||||
<quote start='0' end='33' />
|
||||
</markup>
|
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:example:markup:0'>
|
||||
<body start='0' end='1' />
|
||||
<body start='14' end='15' />
|
||||
</fallback>
|
||||
<fallback xmlns='urn:xmpp:compat:0' for='urn:xmpp:reply:0'>
|
||||
<body start='0' end='33' />
|
||||
</fallback>
|
||||
</message>]]></example>
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>The exact behavior for a compatibility fallback should be defined in the respective specification. Not displaying
|
||||
the fallback in supporting clients would be an example for a behavior.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Security Considerations" anchor="security">
|
||||
<p>
|
||||
An attacker might include a compatibility fallback with a meaning that is different from what would be displayed
|
||||
by a supporting client. While this could also be achieved using other parts of the XMPP specifications (e.g.
|
||||
xml:lang), some environments might want to prevent it. Specifications could standardize some parts of the
|
||||
compatibility text such that the equivalence can be verified by supporting clients.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>This document requires no interaction with ®ISTRAR;.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
@ -0,0 +1,125 @@
|
|||
<?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>
|
||||
<header>
|
||||
<title>Message Replies</title>
|
||||
<abstract>
|
||||
This document defines a way to indicate that a message is a reply to a previous message.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies/>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>reply</shortname>
|
||||
<author>
|
||||
<firstname>Natalie</firstname>
|
||||
<surname>Wirth</surname>
|
||||
<email>nataliew@laposte.net</email>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Marvin</firstname>
|
||||
<surname>Wissfeld</surname>
|
||||
<email>xsf@larma.de</email>
|
||||
<jid>jabber@larma.de</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2022-01-01</date>
|
||||
<initials>nw/mw</initials>
|
||||
<remark>
|
||||
<p>First draft.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
When commenting on a previous message, it is sometimes desired to clarify which message the comment refers to.
|
||||
Currently, &xep0393; quotes are commonly used for that purpose. However, this format does not allow receiving
|
||||
clients to properly identify the referenced message or to adjust the user interface accordingly.
|
||||
</p>
|
||||
<p>
|
||||
This specification defines a way to indicate that a message is a reply to a previous message. It does not intend
|
||||
to provide means to create sub-threads for a message.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<p>
|
||||
To indicate that a message is a reply, a <reply> element in the urn:xmpp:reply:0 namespace is placed in the
|
||||
message stanza. The <reply> element has a 'to' attribute containing the full jid of the author of the
|
||||
referenced message and an 'id' attribute containing the id of the referenced message.
|
||||
</p>
|
||||
<example caption="Max replies to Anna's message"><![CDATA[
|
||||
<message to='max@example.com' from='anna@example.com/tablet' id='message-id1' type='chat'>
|
||||
<body>We should bake a cake</body>
|
||||
</message>
|
||||
|
||||
<message to='anna@example.com' id='message-id2' type='chat'>
|
||||
<body>Great idea!</body>
|
||||
<reply to='anna@example.com/tablet' id='message-id1' xmlns='urn:xmpp:reply:0' />
|
||||
</message>]]></example>
|
||||
|
||||
<section2 topic='Compatibility Fallback' anchor='compat'>
|
||||
<p>
|
||||
To provide a fallback for non-supporting clients, the sending client MAY include fallback text in the body and
|
||||
indicate it via Compatibility Fallback.
|
||||
</p>
|
||||
<example caption="Anna replies to a message and includes a fallback"><![CDATA[
|
||||
<message to='anna@example.com' id='message-id3' type='chat'>
|
||||
<body>
|
||||
> Anna wrote:
|
||||
> We should bake a cake
|
||||
Great idea!
|
||||
</body>
|
||||
<reply to='anna@example.com/laptop' id='message-id1' xmlns='urn:xmpp:reply:0' />
|
||||
<fallback xmlns='urn:xmpp:feature-fallback:0' for='urn:xmpp:reply:0'>
|
||||
<body start="0" end="36" />
|
||||
</fallback>
|
||||
</message>]]></example>
|
||||
|
||||
<p>
|
||||
The receiving client SHOULD NOT display the compatibility fallback if it renders the referenced message
|
||||
alongside the reply in some way. However, if the receiving client does not display the referenced message, for
|
||||
example because it doesn't know the referenced id, it MAY display the compatibility fallback instead.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<p>Answers MUST NOT be be assumed to relate to any other messages than the referenced one.</p>
|
||||
<section2 topic='Using the correct ID' anchor='business-id'>
|
||||
<p>
|
||||
For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be used for replies. Instead, in group
|
||||
chat situations, the ID assigned to the stanza by the group chat itself must be used. This is discovered in a
|
||||
<stanza-id> element with a 'by' attribute that matches the bare JID of the group chat, as defined
|
||||
in &xep0359;.
|
||||
</p>
|
||||
<p>
|
||||
This implies that group chat messages without a &xep0359; stanza-id cannot be replied to.
|
||||
</p>
|
||||
<p>
|
||||
For other message types the sender should use the 'id' from a &xep0359;
|
||||
<origin-id> if present, or the value of the 'id' attribute on the
|
||||
<message> otherwise.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>This document requires no interaction with ®ISTRAR;.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
Loading…
Reference in New Issue