First draft.
++ 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. +
++ &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. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
+ ++ Specifications that describe further ways to join a call define their own sub-elements to the <invite> + element containing all necessary information for joining. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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;. +
++ 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;. +
++ This implies that invite messages should only be sent in group chats that attach a &xep0359; stanza-id. +
++ 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. +
++ None. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with ®ISTRAR;.
+First draft.
++ 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. +
++ 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. +
++ 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. +
+ ++ 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. +
+ ++ 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. +
+ ++
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. +
++ 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. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with ®ISTRAR;.
+First draft.
++ 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. +
++ 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. +
++ 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. +
++ To provide a fallback for non-supporting clients, the sending client MAY include fallback text in the body and + indicate it via Compatibility Fallback. +
++ 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. +
+Answers MUST NOT be be assumed to relate to any other messages than the referenced one.
++ 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;. +
++ This implies that group chat messages without a &xep0359; stanza-id cannot be replied to. +
++ 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. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with ®ISTRAR;.
+