mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
Merge branches 'feature/protoxep-udt' and 'feature/protoxep-mfc'
This commit is contained in:
Jonas Schäfer
commit
1d3bcba3b4
203
inbox/mamfc.xml
Normal file
203
inbox/mamfc.xml
Normal file
@ -0,0 +1,203 @@
|
|||||||
|
<?xml version='1.0' encoding='UTF-8'?>
|
||||||
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||||
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||||
|
%ents;
|
||||||
|
<!ENTITY ns "urn:xmpp:mamfc:0">
|
||||||
|
<!ENTITY nsx "urn:example:">
|
||||||
|
]>
|
||||||
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
|
<xep>
|
||||||
|
<header>
|
||||||
|
<title>MAM Fastening Collation</title>
|
||||||
|
<abstract>This specification proposes a mechanism by which MAM results containing fastenings can be collated effectively.</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>XXXX</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Standards Track</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<dependencies>
|
||||||
|
<spec>XMPP Core</spec>
|
||||||
|
<spec>XEP-0422</spec>
|
||||||
|
<spec>XEP-0313</spec>
|
||||||
|
</dependencies>
|
||||||
|
<supersedes/>
|
||||||
|
<supersededby/>
|
||||||
|
<shortname>mamfc</shortname>
|
||||||
|
&dcridland;
|
||||||
|
&ksmithisode;
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2019-12-19</date>
|
||||||
|
<initials>dwd</initials>
|
||||||
|
<remark>
|
||||||
|
<ul>
|
||||||
|
<li>Initial Revision</li>
|
||||||
|
</ul>
|
||||||
|
</remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
|
||||||
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
|
<p>In XMPP, all messages are not equal. Some are semantically actual human messages; these are referred to in this
|
||||||
|
document as "instant messages". Others are ancillary messages - reactions, receipts, and so on - that are useful
|
||||||
|
and important, but do not conform to the concept of an instant message in the sense that a user might reasonably
|
||||||
|
expect.</p>
|
||||||
|
<p>Fastenings, &xep0422;, provides a generic mechanism for a sending entity to indicate that a particular message is
|
||||||
|
associated closely to an instant message. But in doing so, this presents the problem that if many messages are not in fact
|
||||||
|
actual human messages, an archive query might end up downloading dozens or even hundreds of messages in order to
|
||||||
|
present just a handful of actual instant messages to the user. Much of the information downloaded is not required.</p>
|
||||||
|
<p>For example, to display a message, a client may need to download all the "likes" for it - whereas a simply number of
|
||||||
|
likes might be sufficient for most users' needs.</p>
|
||||||
|
<p>This specification tackles the problem by allowing these to be filtered, collated, or presented in full depending
|
||||||
|
on the needs of the client. The client now downloads just the instant messages from the archive, and any likes,
|
||||||
|
reactions, or receipts are simply summarized.</p>
|
||||||
|
<section2 topic="Terminology">
|
||||||
|
<p>Because this document defines mechanisms for dealing generically with potential types of fastenings, it does not
|
||||||
|
offer any real examples of actual fastenings that might be used.</p>
|
||||||
|
<p>Instead, example fastenings are used within an XML namespace prefixed by <tt>&nsx;</tt></p>
|
||||||
|
<p>Pseudo-fastenings are messages that are semantically equivalent to fastenings, but use a different syntax,
|
||||||
|
see <link url="#pseudo">Pseudo Fastenings</link>.</p>
|
||||||
|
<p>Nomenclature used for instant messages versus ancillary messages will need to be adjusted to make it consistent
|
||||||
|
with &xep0422; et al.</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Overview' anchor="overview">
|
||||||
|
<section2 topic="Discovering Support" anchor="feature">
|
||||||
|
<p>Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature
|
||||||
|
of <tt>&ns;</tt>.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Summarizing">
|
||||||
|
<p>This specification provides for four types of summary listing.</p>
|
||||||
|
<p>The first form, "<tt>simplified</tt>", is the default, and essentially represents the status quo. MAM queries
|
||||||
|
behave as if the archive contains only traditional IM traffic. No summary is provided.</p>
|
||||||
|
<p>The second form, "<tt>full</tt>", presents every message stanza in the results, including all fastenings,
|
||||||
|
errors, and so on.</p>
|
||||||
|
<p>The third form, "<tt>collate</tt>", presents each traditional IM message, as "<tt>simplified</tt>", but within
|
||||||
|
the result includes summary information about the fastenings (and pseudo-fastenings) encountered.</p>
|
||||||
|
<p>Finally a fourth form, "<tt>fastenings</tt>", returns only the fastenings for a particular message.</p>
|
||||||
|
<p>The "collate" form is the bulk of the specification presented herein.</p>
|
||||||
|
<section3 topic="Summary Information">
|
||||||
|
<p>The <apply-to/> element of &xep0422; contains a number of fastening elements. These in turn consist of a
|
||||||
|
qualified element, with a number of attributes, and potentially some content within the element.</p>
|
||||||
|
<p>This specification refers to the qualified name (the tuple of XML namespace and local-name) as the "fastening
|
||||||
|
type" (represented as an XML element herein), and the top-level element (including attributes and their
|
||||||
|
values), as the "fastening summary".</p>
|
||||||
|
<p>For example, a hypothetical edit fastening type might be <tt><edit xmlns="&nsx;edit:0"/></tt>, and that would
|
||||||
|
be the fastening summary as well. The full fastening would include any children (text or further XML elements)
|
||||||
|
of the top-level element. But a hypothetical reaction fastening type might be
|
||||||
|
<tt><reaction xmlns="&nsx;reaction:0"/></tt>, but the fastening summary could be
|
||||||
|
<tt><reaction xmlns="&nsx;reaction:0" emoji="Ὁ"/></tt></p>
|
||||||
|
<p>The summary information against each parent message consists of, for each fastening summary:</p>
|
||||||
|
<ul>
|
||||||
|
<li>The fastening summary itself.</li>
|
||||||
|
<li>A count of the number of fastenings with this summary fastened to the parent message.</li>
|
||||||
|
<li>The full fastening for the last fastening received for the parent message.</li>
|
||||||
|
</ul>
|
||||||
|
</section3>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="Protocol Elements">
|
||||||
|
<section2 topic="Querying">
|
||||||
|
<p>This specification adds an additional field to the form defined in &xep0313; with the field name
|
||||||
|
"<tt>{&ns;}summary</tt>". This may have only the following values (unless of course further values are advertised
|
||||||
|
by a future specification):</p>
|
||||||
|
<ul>
|
||||||
|
<li>simplified</li>
|
||||||
|
<li>full</li>
|
||||||
|
<li>collate</li>
|
||||||
|
<li>fastenings</li>
|
||||||
|
</ul>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Results">
|
||||||
|
<p>The <tt><result/></tt> element defined in &xep0313; is extended by adding zero or more additional elements with
|
||||||
|
a local name of "<tt>applied</tt>", qualified by the "<tt>&ns;</tt>" namespace.</p>
|
||||||
|
<p>Each <tt><applied/></tt> element is associated with precisely one fastening summary.</p>
|
||||||
|
<p>This element contains, as its first child element, the full fastening for the last fastening received by the
|
||||||
|
server for the parent message. This is not included for "<tt>shell</tt>" fastenings, which are untyped.</p>
|
||||||
|
<p>There is a "<tt>count</tt>" attribute, consisting of an integral count of the fastenings with the same summary
|
||||||
|
as the first child element (or the count of shell fastenings when this is not included). This count, if absent,
|
||||||
|
defaults to 1. For "<tt>shell</tt>" fastenings, the attribute "<tt>shell</tt>" is set to true (or another value
|
||||||
|
with the same semantics for an XML boolean).</p>
|
||||||
|
<p>The <tt><applied/></tt> elements are only included in the <tt><result/></tt> element when the requested
|
||||||
|
summary type is "<tt>collate</tt>".</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Latest Archive ID">
|
||||||
|
<p>The latest archive id can usually be deduced either from the last message stanza received (and its stanza-id,
|
||||||
|
see &xep0359;) or by the id attribute of the last <tt><result/></tt> element from a query extending to the
|
||||||
|
latest message.</p>
|
||||||
|
<p>Since this specification can cause the latest message to be only in a summarized form when presented in the
|
||||||
|
archive, it also adds an additional element to the <tt><fin/></tt> element which terminates the query, to
|
||||||
|
indicate the latest id held in the archive (which may be that of a fastening).</p>
|
||||||
|
<p>This element, qualified by the "<tt>&ns;</tt>", has the local name of "<tt>latest</tt>" and a single attribute,
|
||||||
|
"<tt>id</tt>", containing the latest archive id.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Incremental queries">
|
||||||
|
<p>A MAM query where the MAM summary type is "<tt>collate</tt>", and where "<tt>start</tt>" and "<tt>end</tt>" (or
|
||||||
|
the RSM <tt><after/></tt> element) would exclude the parent message but include the fastening, then the MAM
|
||||||
|
result is sent with the <tt><forwarded/></tt> element omitted but the summary present (including all
|
||||||
|
fastenings, not just those that have changed).</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="Pseudo-Fastenings" anchor="pseudo">
|
||||||
|
<p>A number of previous specifications exist that - if they were rewritten today - might use fastenings.</p>
|
||||||
|
<p>For the purposes of this specification, it is convenient to treat these as pseudo-fastenings, behaving as if they
|
||||||
|
were a fastening for the purposes of the "collate" and "fastenings" summary types.</p>
|
||||||
|
<p>This specification defines two such types. Both MUST be supported by servers:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Message Delivery Receipts: &xep0184; "ack messages" - those containing a <tt><received/></tt> element - are
|
||||||
|
considered to be equivalent to a fastening containing just the <received/> element, applying to the message
|
||||||
|
given by the "<tt>id</tt>" attribute.</li>
|
||||||
|
<li>Chat Markers: &xep0333; A Chat Marker is similarly equivalent to a fastening containing the Chat Marker, but
|
||||||
|
applying to all previous messages (since previous messages can be assumed to have been read and or displayed,
|
||||||
|
etc).</li>
|
||||||
|
</ul>
|
||||||
|
<p>In both cases, the fastening summary SHOULD omit the <tt>id</tt> attribute.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="Examples">
|
||||||
|
<p>A firm TODO; contributions are welcome - and a good test of whether I've written the rest right!</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="Schema">
|
||||||
|
<code>
|
||||||
|
<![CDATA[
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="]]>&ns;<![CDATA[" xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
||||||
|
<xs:element name="applied" type="mamfc:appliedType" xmlns:mamfc="]]>&ns;<![CDATA["/>
|
||||||
|
<xs:complexType name="appliedType">
|
||||||
|
<xs:sequence>
|
||||||
|
<xs:any minOccurs="0" maxOccurs="1"/>
|
||||||
|
<!-- Fastening summary, absent when shell is true -->
|
||||||
|
</xs:sequence>
|
||||||
|
<xs:attribute type="xs:positiveInteger" name="count" default="1"/>
|
||||||
|
<xs:attribute type="xs:boolean" name="shell" default="false"/>
|
||||||
|
</xs:complexType>
|
||||||
|
<xs:element name="latest" type="mamfc:latestType" xmlns:mamfc="]]>&ns;<![CDATA["/>
|
||||||
|
<xs:complexType name="latestType">
|
||||||
|
<xs:attribute type="xs:string"/>
|
||||||
|
</xs:complexType>
|
||||||
|
</xs:schema>
|
||||||
|
]]>
|
||||||
|
</code>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Security Considerations' anchor='security'>
|
||||||
|
<p>This specification imposes substantial workload for servers.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||||||
|
<p>This XEP requires no interaction with &IANA;. </p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||||
|
<p>None.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Acknowledgements' anchor='ack'>
|
||||||
|
<p>The authors wish to share any credit with many members of the community, including Marvin Wissfield.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
</xep>
|
||||||
197
inbox/udt.xml
Normal file
197
inbox/udt.xml
Normal file
@ -0,0 +1,197 @@
|
|||||||
|
<?xml version='1.0' encoding='UTF-8'?>
|
||||||
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||||
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||||
|
%ents;
|
||||||
|
<!ENTITY ns "urn:xmpp:udt:0">
|
||||||
|
<!ENTITY nsx "urn:example:">
|
||||||
|
]>
|
||||||
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
|
<xep>
|
||||||
|
<header>
|
||||||
|
<title>User-defined Data Transfer</title>
|
||||||
|
<abstract>This specification proposes a simple mechanism by which applications can transfer data safely, without
|
||||||
|
needing additional protocol design work. It is intended to provide a protocol that is trivial to implement and can
|
||||||
|
be driven with a simple API.</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>XXXX</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Standards Track</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<dependencies>
|
||||||
|
<spec>XMPP Core</spec>
|
||||||
|
</dependencies>
|
||||||
|
<supersedes/>
|
||||||
|
<supersededby/>
|
||||||
|
<shortname>udt</shortname>
|
||||||
|
&dcridland;
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2019-12-30</date>
|
||||||
|
<initials>dwd</initials>
|
||||||
|
<remark>
|
||||||
|
<ul>
|
||||||
|
<li>Initial Revision</li>
|
||||||
|
</ul>
|
||||||
|
</remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
|
||||||
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
|
<p>Applications written on top of XMPP often need to exchange data that has no existing standard. Such applications are
|
||||||
|
often written by developers unfamiliar with best practise in designing new extensions for XMPP, making it hard to achieve
|
||||||
|
this simple design goal without causing longer term problems.</p>
|
||||||
|
<p>This leads to "solutions" such as stuffing JSON directly in the <body/> element, for example, and recognising
|
||||||
|
this at the receiver either by heuristics or by a special <subject/>. While this works, it's difficult to then
|
||||||
|
migrate to something else, and enforces that custom clients are always used.</p>
|
||||||
|
<p>Therefore this document proposes a very simple (and simplistic) framework for sending such data which - while
|
||||||
|
very light on features - nevertheless conforms to best practice. Unusually, this specification SHOULD NOT be used
|
||||||
|
as a base upon which to build other standards, and suggests an API for library developers to implement.</p>
|
||||||
|
<section2 topic="Terminology">
|
||||||
|
<p>Data transferred using this specification is encoded using JSON. The type of the data is given by a URI under
|
||||||
|
the same rules as an XML namespace, and this specification refers to this as the datatype.</p>
|
||||||
|
<p>Because this document defines mechanisms for sending essentially arbitrary data, no real-world examples are
|
||||||
|
given.</p>
|
||||||
|
<p>Instead, example namespaces are used within an XML namespace prefixed by <tt>&nsx;</tt></p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Overview' anchor="overview">
|
||||||
|
<section2 topic="Discovering Support" anchor="feature">
|
||||||
|
<p>Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature
|
||||||
|
of <tt>&ns;</tt>.</p>
|
||||||
|
<p>Support for a particular datatype is given by concatenating the <tt>&ns;</tt> feature with a hash character
|
||||||
|
('<tt>#</tt>') and the datatype, for example <tt>&ns;#&nsx;foo</tt>.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Data Transfers">
|
||||||
|
<p>This specification provides for two types of user-defined data transfers. Each uses a similar payload syntax,
|
||||||
|
the UDT data payload.</p>
|
||||||
|
<p>Requests are carried within <iq/> stanzas, either of type "get" or "set", and result in a "result" optionally
|
||||||
|
containing a second UDT data payload.</p>
|
||||||
|
<p>UDT payloads may also be placed within a <message/> stanza. <message/> stanzas MAY contain multiple UDT
|
||||||
|
payloads, but typical usage is expected to be that there will be only one. The UDT payload may be ancillary data
|
||||||
|
to another message, or a standalone message in its own right.</p>
|
||||||
|
<section3 topic="Protocol Syntax">
|
||||||
|
<p>A UDT payload consists of a single element, <tt><payload/></tt>, qualified by the XML namespace
|
||||||
|
<tt>&ns;</tt>. It has a single, mandatory attribute of <tt>datatype</tt>, which MUST contain a string conformant
|
||||||
|
to the requirements for XML namespaces (typically a URI under the control of the application developer).</p>
|
||||||
|
<p>As with XML namespaces, this URI is never expected to be resolved, and is used solely as an indentifier.
|
||||||
|
Different strings are considered entirely different datatypes, and common prefixes etc MUST be considered
|
||||||
|
irrelevant for the purposes of interpreting the data. There are no common or standard datatypes.</p>
|
||||||
|
<p>The <tt><payload</tt> element contains exactly one mandatory child element, the <tt><json/></tt> element
|
||||||
|
defined in &xep0335;. This in turns contains the JSON data.</p>
|
||||||
|
<example><![CDATA[
|
||||||
|
<message from="gamer@game-company.example"
|
||||||
|
to="match-maker.game-company.example"
|
||||||
|
id="12345">
|
||||||
|
<payload xmlns="]]>&ns;<![CDATA[" datatype="]]>&nsx;foo<![CDATA[">
|
||||||
|
<json xmlns="urn:xmpp:json:0">
|
||||||
|
{
|
||||||
|
"annoying-teenager-level": 11
|
||||||
|
}
|
||||||
|
</json>
|
||||||
|
</payload>
|
||||||
|
</message>
|
||||||
|
]]></example>
|
||||||
|
<p>Note that the suggested custom &IQ; query payload of &xep0335; is not used as this would generally require
|
||||||
|
custom handlers within client libraries:</p>
|
||||||
|
<example><![CDATA[
|
||||||
|
<iq from="gamer@game-company.example"
|
||||||
|
to="match-maker.game-company.example"
|
||||||
|
id="12345"
|
||||||
|
type="set">
|
||||||
|
<payload xmlns="]]>&ns;<![CDATA[" datatype="]]>&nsx;foo<![CDATA[">
|
||||||
|
<json xmlns="urn:xmpp:json:0">
|
||||||
|
{
|
||||||
|
"annoying-teenager-percentage": 101
|
||||||
|
}
|
||||||
|
</json>
|
||||||
|
</payload>
|
||||||
|
</iq>
|
||||||
|
]]></example>
|
||||||
|
</section3>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="API Requirements">
|
||||||
|
<p>In order to satisfy the goals of this protocol, it is necessary to define an API that can be consistently
|
||||||
|
implemented across APIs. This allows application developers to use the protocol easily, and encourages this
|
||||||
|
over using the ad-hoc techniques described in the introduction.</p>
|
||||||
|
<p>Therefore, while not imposing hard and fast API definitions, this specification proposes naming conventions
|
||||||
|
for APIs that will hopefully guide application developers toward consistent usage.</p>
|
||||||
|
<p>While names are specified in "snake_case", API developers are free to use their own naming. This specification
|
||||||
|
also defines APIs as taking session arguments which will often be implied by method calls, and omits types.</p>
|
||||||
|
<p>Library developers SHOULD make these calls as simple to use as possible. If these are significantly harder to use
|
||||||
|
for inexperienced developers than ad-hoc techniques, then ad-hoc techniques will be used instead.</p>
|
||||||
|
<section2 topic="Arguments and Types">
|
||||||
|
<ul>
|
||||||
|
<li><tt>session</tt> - The session, connection or stream object or handle for the library. In cases where the
|
||||||
|
library uses a single global connection this is omitted. An OO library is likely to elide this and have the call
|
||||||
|
be a method call on the object instead.</li>
|
||||||
|
<li><tt>message</tt> - The message object or handle for the library. An OO library is likely to elide this and have the call
|
||||||
|
be a method call on the object instead.</li>
|
||||||
|
<li><tt>datatype</tt> - Typically a string containing an XML-style namespace.</li>
|
||||||
|
<li><tt>jid</tt> - A string or JID object. Any form of legal jid might be used here.</li>
|
||||||
|
<li><tt>data</tt> - Either a JSON-encoded string, or an object or data structure which can be converted by the
|
||||||
|
library.</li>
|
||||||
|
<li><tt>get_or_set</tt> - A flag for indicating whether this is a "get" or "set" request.</li>
|
||||||
|
<li><tt>callback</tt> - Some callable object or similar as meets the idiom of the language.</li>
|
||||||
|
</ul>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Advertising Support">
|
||||||
|
<p>Support is advertised on a session by calling <tt>udt_advertise(session, datatype)</tt>. Calling this MUST
|
||||||
|
explicitly advertise both the <tt>&ns;</tt> feature and that of the datatype support.</p>
|
||||||
|
<p>APIs are free to (and encouraged to) implicitly advertise support when other calls are made.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Requests">
|
||||||
|
<p>Requests are sent to a particular jid by calling <tt>udt_request(session, jid, get_or_set, datatype, data)</tt>.
|
||||||
|
This might return a UDT payload, or have an additional <tt>callback</tt> argument to call with the response.</p>
|
||||||
|
<p>Applications may register to handle such requests by calling <tt>udt_request_callback(session, get_or_set,
|
||||||
|
datatype, callback)</tt>. The callback should be called as <tt>callback(session, jid, get_or_set, datatype,
|
||||||
|
data)</tt>, and returning a payload should send a <tt>result</tt> containing it. Applications registering this
|
||||||
|
way SHOULD implicitly advertise support for the datatype.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic="Messages">
|
||||||
|
<p>Messages are sent to a particular jid by calling <tt>udt_message(session, jid, get_or_set, datatype, data)</tt>.</p>
|
||||||
|
<p>Applications may register to handle such requests by calling <tt>udt_message_callback(session, get_or_set,
|
||||||
|
datatype, callback)</tt>. The callback should be called as <tt>callback(session, jid, get_or_set, datatype,
|
||||||
|
data)</tt>. Applications registering this way SHOULD implicitly advertise support for the datatype.</p>
|
||||||
|
<p>Applications may check to see if any message stanza contains a UDT payload by calling <tt>udt_payload(message,
|
||||||
|
datatype)</tt>, which returns the payload if it exists.</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic="Schema">
|
||||||
|
<code>
|
||||||
|
<![CDATA[
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="]]>&ns;<![CDATA[" xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
||||||
|
<xs:element name="payload" type="udt:payloadType" xmlns:udt="]]>&ns;<![CDATA["/>
|
||||||
|
<xs:complexType name="payloadType">
|
||||||
|
<xs:sequence>
|
||||||
|
<xs:any minOccurs="1" maxOccurs="1"/>
|
||||||
|
<!-- Always a XEP-0335 json element, but I can't figure that out. -->
|
||||||
|
</xs:sequence>
|
||||||
|
<xs:attribute type="xs:string" name="datatype"/>
|
||||||
|
</xs:complexType>
|
||||||
|
</xs:schema>
|
||||||
|
]]>
|
||||||
|
</code>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Security Considerations' anchor='security'>
|
||||||
|
<p>All security implications herein are those of the payload.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||||||
|
<p>This XEP requires no interaction with &IANA;. </p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||||
|
<p>None.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Acknowledgements' anchor='ack'>
|
||||||
|
<p>The authors wish to share any credit with many members of the community, including Florian Schmaus.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
</xep>
|
||||||
Loading…
Reference in New Issue
Block a user