moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Merge branch 'protoxeps-marvin' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2022-01-04 18:44:53 +01:00
commit 3fd3d27117
3 changed files with 458 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

199
inbox/call-invites.xml Normal file
View File

@ -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 &lt;invite&gt; 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 &lt;invite&gt; element contains one sub-element for each way to join the
call.
</p>
<p>
In order to invite someone to a &xep0167; call, a &lt;jingle&gt; element is placed in the &lt;invite&gt;
element. The &lt;jingle&gt; 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 &lt;external&gt; element placed in the &lt;invite&gt;
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 &lt;invite&gt;
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 &lt;retract&gt; 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 &lt;accept&gt; 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. &lt;jingle&gt; or &lt;external&gt;)
including all of its attributes and children is placed in the &lt;accept&gt; 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 &lt;accept&gt; was sent, the initiating or accepting client continues to establish the call depending
on the selected connection method: If an &lt;external&gt; method was selected, the accepting client handles the
URI. The exact behaviour of opening the URI is implementation specific. If a &lt;jingle&gt; 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 &lt;jingle&gt; element, respectively.
</p>
</section2>
<section2 topic='Rejecting a call'>
<p>
A call invite can be rejected by sending a message containing a &lt;reject&gt; 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 &lt;left&gt; 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 &lt;stanza-id&gt; 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;
&lt;origin-id&gt; if present, or the value of the 'id' attribute on the
&lt;message&gt; 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 &REGISTRAR;.</p>
</section1>
</xep>

134
inbox/compatibility-fallback.xml Normal file
View File

@ -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 &lt;fallback&gt; element in the urn:xmpp:compat:0
namespace is placed in the message stanza. The &lt;fallback&gt; element has a 'for' attribute with an identifier
of the specification the fallback is for. The &lt;fallback&gt; element contains one &lt;body&gt; 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 &lt;fallback&gt; 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 &lt;reply&gt; 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 &REGISTRAR;.</p>
</section1>
</xep>

125
inbox/replies.xml Normal file
View File

@ -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 &lt;reply&gt; element in the urn:xmpp:reply:0 namespace is placed in the
message stanza. The &lt;reply&gt; 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
&lt;stanza-id&gt; 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;
&lt;origin-id&gt; if present, or the value of the 'id' attribute on the
&lt;message&gt; 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 &REGISTRAR;.</p>
</section1>
</xep>