moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2025-01-30 23:10:10 -05:00
Code Issues Releases Wiki Activity

Merge branch 'master' of athena.jabber.org:xmpp

Browse Source
This commit is contained in:
Peter Saint-Andre 2014-01-05 16:39:56 -07:00
commit 3c8cbe97c4
38 changed files with 3142 additions and 328 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
all.shtml
View File

@ -5,7 +5,7 @@
<!--#include virtual="/includes/head.txt" -->
<h2>XMPP Extensions</h2>
<p><a class='standardsButton' href='atom.xml'>ATOM</a>&nbsp;&nbsp;<a class='standardsButton' href='rss.xml'>RSS</a></p>
<p><a class='standardsButton' href='atom.xml'>ATOM</a>&#160;&#160;<a class='standardsButton' href='rss.xml'>RSS</a></p>
<p>This page lists all <a href='/extensions/'>XMPP Extension Protocols</a> published by the XMPP Standards Foundation, including specifications that have been retracted, rejected, deprecated, and obsoleted.</p>

668
inbox/colibri.xml Normal file
View File

@ -0,0 +1,668 @@
<?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>COnferences with LIghtweight BRIdging (COLIBRI)</title>
<abstract>This specification defines an XMPP extension that allows
real-time communications clients to discover and interact with
conference bridges that provide conference mixing or relaying
capabilities.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0167</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>colibri</shortname>
<author>
<firstname>Emil</firstname>
<surname>Ivov</surname>
<email>emcho@jitsi.org</email>
<jid>emcho@sip-communicator.org</jid>
<org>jitsi.org</org>
</author>
<author>
<firstname>Lyubomir</firstname>
<surname>Marinov</surname>
<email>lubo@jitsi.org</email>
<jid>lubo@sip-communicator.org</jid>
<org>jitsi.org</org>
</author>
&fippo;
<discuss>jingle</discuss>
<revision>
<version>0.0.2</version>
<date>2013-12-04</date>
<initials>ei/ph</initials>
<remark>
<p>Added usecases.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-05-30</date>
<initials>ei/lm</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
&xep0298; defines a way for XMPP agents to establish and
participate in tightly coupled conference calls. Such conference
calls would typically involve a number of regular participants
that establish direct one-to-one sessions with a single entity,
often referred to as a focus agent. Focus agents are generally
responsible for making sure that media sent from one call
participant would be distributed to all others so that everyone
would effectively hear or see everyone else. In other words they
often act as media mixers.
</p>
<p>
Depending on the mixing technology used by media mixers, they may
require significant bandwidth, processing resources or both. It is
hence common for mixers to be hosted on dedicated servers that can
provide such resources. They are then made reachable as
rendez-vous points and conference call participants are required
to call in, in order to join a conference call. This requires a
certain amount of pre-call configuration to be completed by the
service maintainers in order to create conference rooms and grant
proper access to the expected participants. The authorization
credentials are then often relayed to the participants in
preparation of the call by other means, such as IM or mail.
</p>
<p>
In certain situations, such pre-call preparations are
inconvenient and it is important for users to be able to establish
ad-hoc conference calls. One way to achieve this is for user
agents themselves to act as focus agents and media mixers.
Everyone else just calls the user at the focus agent, who then can
decide whether to accept or reject the calls as they arrive. This
works particularly well for audio only calls as the amount of
bandwidth and processing resources that they require is generally
within reach for end-user devices.
</p>
<p>
The situation is quite different for video calls. Media decoding
and especially encoding require considerably more resources with
video than they do with audio. Today, encoding a single video flow
with an acceptable quality is often the maximum that can be
expected from an end-user device. The advantages that come with
Moore's law will likely be insufficient to improve this, given the
massive shift toward mobile devices and the ever-increasing user
expectations toward video quality.
</p>
<p>
Therefore, this specification (COLIBRI) aims to provide a means
for user agents to interact with conference mixers. Such
interaction allows user agents to allocate mixing channels,
indicate what conferences they should be attached to, what
integers the various payload types map to, etc. Using COLIBRI
would hence allow any user agent to organize conference calls and
act as a signalling focus by outsourcing the actual media mixing
to a dedicated mixer.
</p>
</section1>
<section1 topic='Terminology' anchor='terms'>
<dl>
<di>
<dt>
Focus or Focus Agent
</dt>
<dd>
The terms apply to XMPP agents that, in terms of signalling,
stand at the center of a tightly-coupled conference call. In
other words, all conference participants establish a &xep0166;
session with and only with that agent. Focus Agents are not
necessarily performing media mixing themselves. In fact, the
very purpose of this specification is to provide them with a
means of handling this elsewhere.
</dd>
</di>
<di>
<dt>
Mixer or Bridge
</dt>
<dd>
Throughout this document the term is used to depict an
entity that is responsible for mixing and delivering to
conference participants all media exchanged in a conference
call. Mixers or bridges can provide their service by either
performing Content Mixing, or RTP translation or both.
</dd>
</di>
<di>
<dt>
Content Mixing
</dt>
<dd>
The term refers to a kind of media processing where the
content of multiple input RTP streams is "mixed" into a single
output stream. In conference calls audio mixing
implementations generally simply add and adjust all source
audio streams to produce their single output stream. Video
content mixing, on the other hand, is often implemented by
creating composite images containing individual frames from
the input streams. Another common implementation consists in
producing an output that is identical to one of the input
streams, often the one belonging to a currently active
speaker.
</dd>
</di>
<di>
<dt>
RTP Translation
</dt>
<dd>
<cite>RFC 3550</cite> defines a translator as "an intermediate
system that forwards RTP packets with their synchronization
source identifier intact." This specification respects that
definition but it also uses "RTP Translation" in opposition
with "Content Mixing". Conference bridges that perform RTP
translation simply redirect each incoming RTP packet to all
participants, often excluding the one where it came from.
Contrary to content mixing, rtp translation generally requires
less processing resources since it does not involve media
manipulation. Bandwidth requirements on the other hand, could
be significantly higher with RTP translation than with content
mixing.
</dd>
</di>
</dl>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>
The extension defined herein is designed to meet the following
requirements:
</p>
<ol>
<li>
Provide a means for conference focus agents to interact with
conference mixers in order to configure payload type mappings
and allocate ports or other resources that they could then
advertise in Jingle sessions so that all media would traverse
the bridge.
</li>
<li>Impose no COLIBRI specific requirements on non-focus
participants so that any Jingle supporting client would be able
to participate.
</li>
<li>[TODO] Anything else?</li>
</ol>
</section1>
<section1 topic='How It Works' anchor='howitworks'>
<p>
This section provides a friendly introduction to COLIBRI.
</p>
<p>
In essence, the goal of COLIBRI is to provide focus agents with a
way of using remote mixers as if as they were available locally.
The most important part of that is the possibility to allocate
ports on the mixer interfaces and then use these ports when
establishing Jingle sessions with the various participants.
</p>
<p>
Every participant in the conference call is assigned one port for
RTP data and one for RTCP. An RTP/RTCP port couple is called a
channel. Each participant would use one channel per media type.
That is, a client participating with audio only would get one
channel, while another one that joins with both audio and video
would get two: one for audio and one for video.
</p>
<p>
Channels are used for streams from the bridge to participants and
from participants to the bridge. Typically a channel would contain
one stream from a participant to a bridge, for example their
webcam or desktop, and one or more streams in the opposite
direction (e.g. webcam or desktop streams from other participants
to the one using this channel). This is not a requirement though
and a channel can certainly be used for transportation of multiple
streams in both directions in cases where one bridge is connected
to another.
</p>
<p>
Typically channels would be created by the entity controlling a
conference call. This could either be a conferencing server or a
smart client capable of handling conferences. We would refer to
both of these as the "focus". In either case, the important part
is that the focus terminates all signalling. It is a signalling
endpoint and it is responsible for all aspects of call signalling
including offer/answer.
</p>
<p>
In other words, when setting up a conference, a focus would first
allocate the necessary channels, then directly initiate sessions
(invite) other participants into the call. Only, when sending the
invitations to these participants, the focus would use the
transport information (addresses and ports) that it would have
received from the COLIBRI bridge, rather than its own.
</p>
<!--
discovery
creating a conference call
modifying a conference call
defining payload types
supports transcoding
get supported formats
Mixing vs. RTP translation
RTP/RTCP channels
RAW UDP
ICE UDP
ZRTP
composited / switched
-->
</section1>
<section1 topic='Use cases' anchor='usecases'>
<section2 topic='Creating a conference' anchor='usecases-create'>
<p>
The most important thing about setting up a conference is the
creation of channels for every participant. Conference setup is
not the only chance an organiser gets to declare all
participants but typically when a conference call is setup it
is because there are at least some number of known participants
and there would be no point in delaying channel creation for
them.
</p>
<p>
The following example shows how Romeo creates an audio/video
conference at a bridge, requesting that three participant
channels be created.
</p>
<example caption='Creating a conference'><![CDATA[
SEND: <iq from='romeo@montague.lit/orchard'
id='zid615d9'
to='garden.montague.lit'
type='set'>
<conference xmlns='http://jitsi.org/protocol/colibri'>
<content name='audio'>
<channel initiator='true'>
[optional payload and transport description]
</channel>
<channel initiator='true'/>
...
<channel initiator='true'/>
</content>
<content name='video'>
<channel initiator='true'/>
...
<channel initiator='true'/>
</content>
</conference>
</iq>
]]></example>
<p>
Notice how the 'initiator' channel above is set to true. The
setting determines ICE and DTLS/SRTP behaviour for the bridge.
In this specific case, 'initiator' being set to 'true' Romeo is
requesting that the bridge behave as the initiator of the
session which means that it would try to be the controlling ICE
agent and also assume the 'dtls-actpass' role for DTLS/SRTP
negotiation. A value of 'false' would have meant that the bridge
would behave as the controlled ICE agent and assume the
'dtls-active' role.
</p>
<p>
When sending its result back, the bridge confirms creation of
the requested channels and it also delivers transport
information that would be necessary for participants to
transport media to the bridge. These would most often include
ICE candidates, ufrag and pwd parameters, and DTLS fingerprints.
</p>
<p>
Note that ICE is not mandatory for use and COLIBRI bridges can
just as well perform Hosted NAT Traversal using latching and a
RAW-UDP transport.
</p>
<example caption='Result'><![CDATA[
RECV: <iq type='result' to='romeo@montague.lit/orchard'
from='garden.montague.lit'
id='zid615d9'>
<conference xmlns='http://jitsi.org/protocol/colibri'
id='cafb6f2c8197818e'>
<content name='audio'>
<channel rtp-level-relay-type='mixer' direction='recvonly'
initiator='true' id='c6a142b7cf728fd0' expire='60'>
<source xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' ssrc='3716204482'/>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='5d0mj' ufrag='amiq'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
99:...:F6
</fingerprint>
<candidate type='host' protocol='udp' id='ca' ip='10.0.1.1'
component='1' port='5144' foundation='3' generation='0'
priority='2113932031' network='0'/>
<candidate type='host' protocol='udp' id='ga' ip='10.0.1.1'
component='2' port='5145' foundation='3' generation='0'
priority='2113932030' network='0'/>
</transport>
</channel>
...
</content>
<content name='video'>
<channel rtp-level-relay-type='mixer' direction='recvonly'
initiator='true' id='c9726594ccb4ede7' expire='60'>
...
</channel>
...
</content>
</conference>
</iq>
]]></example>
<p>
The above "result" also contains the following elements of
interest for every channel:
</p>
<p>
- an ID that is necessary for any further modification from that
the focus wants to set on a channel. [FIXME: clients should be
able to specify these id-s so as not to rely on ordering to
identify channels and get complexes thinking they are SDP
parsers]
</p>
<p>
- an rtp-level-relay-type attribute with possible values of
'mixer' and 'translator' indicating how the bridge is going to
deliver data on a specific channel [FIXME: this would definitely
need to be specifiable from the client].
</p>
<p>
- mixer channels would also include ssrc-s for that channels in
question. This is particularly necessary when SSRC-s need to be
announced to participants (because people never learned how RTP
works and are afraid from anything that wasn't explicitly
announced with an Offer/Answer exchange). Generally such
announcements would be possible by simply propagating SSRCs that
other participants announce. In a mixed flow however the SSRC
would belong to the mixer (or COLIBRI bridge) so it would need
to be known in advance.
attribute
</p>
<p>
- the initiator value is echoed
</p>
<p>
- expire describes how many seconds the bridge will keep the
channel open without media activity
</p>
</section2>
<section2 topic='Updating payload information for a channel' anchor='usecases-update-payload'>
<p>
Channel updates can happen for various reasons. The following
examples illustrate two of them:
</p>
<p>
- specifying payload types. While payload types in RTP are
sometimes static (e.g. for older codecs such as G.711), this is
not always the case for more recent types, which need to be
assigned dynamically during session establishment. The tricky
part here is that dynamic means dynamic so every participant in
a conference call may end up expecting different payload types.
As a result, a COLIBRI bridge SHOULD know about everyone's
expectations, which is why channels are updated with payload
types. Note that if a bridge does see unknown payload types it
MUST still relay them to other participants as they might have
used some other mechanism to make sure they know what they
mean.
</p>
<p>
- DTLS/SRTP fingerprints.
</p>
<example caption='Focus updates payload information for a channel'>
<![CDATA[
SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard'
type='set' id='74s'>
<conference xmlns='http://jitsi.org/protocol/colibri'
id='cafb6f2c8197818e'>
<content name='audio'>
<channel id='c6a142b7cf728fd0' initiator='true'>
<payload-type id='111' name='opus' clockrate='48000' channels='2'/>
<payload-type id='0' name='PCMU' clockrate='8000' channels='1'/>
<payload-type id='8' name='PCMA' clockrate='8000' channels='1'/>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
ufrag='WP+qAQZGnDhhM+87' pwd='0Uxdzy9gTryxAkmAx2LD1TYR'>
<fingerprint hash='sha-256' xmlns='urn:xmpp:jingle:apps:dtls:0'
setup='active'>
08:...:C7
</fingerprint>
</transport>
</channel>
</content>
<content name='video'>
<channel id='c9726594ccb4ede7' initiator='true'>
<payload-type id='100' name='VP8' clockrate='90000' channels='1'/>
<payload-type id='116' name='red' clockrate='90000' channels='1'/>
<payload-type id='117' name='ulpfec' clockrate='90000' channels='1'/>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
ufrag='hpx55NAN46sNYwF+' pwd='hkg/YRpjXZx4qDG3KbzB3qr1'>
<fingerprint hash='sha-256' xmlns='urn:xmpp:jingle:apps:dtls:0'
setup='active'>
08:...:C7
</fingerprint>
</transport>
</channel>
</content>
</conference>
</iq>
]]></example>
<p>
Note that while the result in this case is essentially an
acknowledgement, it still carries a full representation of the
bridge.
</p>
<example caption='Result'><![CDATA[
RECV: <iq to='romeo@montague.lit/orchard' from='garden.montague.lit'
type='result' id='74s'>
<conference xmlns='http://jitsi.org/protocol/colibri'
id='cafb6f2c8197818e'>
<content name='audio'>
<channel rtp-level-relay-type='mixer' direction='recvonly'
initiator='true' id='c6a142b7cf728fd0' expire='60'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='5d0mj' ufrag='amiq'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
99:...:F6
</fingerprint>
<candidate type='host' protocol='udp' id='ca' ip='10.0.1.1' component='1'
port='5144' foundation='3' generation='0' priority='2113932031'
network='0'/>
<candidate type='host' protocol='udp' id='ga' ip='10.0.1.1' component='2'
port='5145' foundation='3' generation='0' priority='2113932030'
network='0'/>
</transport>
</channel>
...
</content>
<content name='video'>
<channel rtp-level-relay-type='translator' initiator='true'
id='c9726594ccb4ede7' expire='60'>
...
</channel>
...
</content>
</conference>
</iq>
]]></example>
</section2>
<section2 topic='Updating transport information for a channel' anchor='usecases-update-transport'>
<example caption='Result'><![CDATA[
SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard'
type='set' id='1581'>
<conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
<content name='audio'>
<channel id='c6a142b7cf728fd0' initiator='true'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'>
<candidate foundation='2241210590' component='1' protocol='udp'
priority='2113937151' ip='192.168.2.101' port='61141' type='host'
generation='0' network='1' id='1234'/>
</transport>
</channel>
</content>
</conference>
</iq>
]]></example>
<!--
<p>FIXME: Describe trickle ice?</p>
<p>FIXME: ufrag/pwd missing? required?</p>
-->
<example caption='Result'><![CDATA[
RECV: <iq type='result' to='romeo@montague.lit/orchard' from='garden.montague.lit' id='1581'>
<conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
<content name='audio'>
<channel rtp-level-relay-type='translator' initiator='true'
id='c6a142b7cf728fd0' expire='60'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='5d0mja27fgl83r9tsl1b9gkk4f' ufrag='amiqp'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
99:..:F6
</fingerprint>
<candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
port='5144' foundation='3' generation='0' priority='2113932031' network='0'/>
<candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
port='5145' foundation='3' generation='0' priority='2113932030' network='0'/>
</transport>
</channel>
</content>
</conference>
</iq>
]]></example>
<p>Essentially that information is the transport description from
the bridge. <!-- Do we need that? FIXME -->
</p>
</section2>
<section2 topic='Adding a new channel' anchor='usecases-addchannel'>
<p>
ICE candidates are another reason why a focus might want to
update a channel. Earlier examples indicated how conference
setup could be completed without providing any transport
information whatsoever. Whenever that is the case, such
information would need to be provided through channel
modification.
</p>
<example caption='Adding a new channel'><![CDATA[
SEND: <iq to='garden.montague.lit' from='romeo@montague.lit/orchard' type='get' id='247'>
<conference xmlns='http://jitsi.org/protocol/colibri' id='cafb6f2c8197818e'>
<content creator='initiator' name='audio'>
<channel initiator='true'/>
</content>
<content creator='initiator' name='video'>
<channel initiator='true'/>
</content>
</conference>
</iq>
]]></example>
<example caption='Result'><![CDATA[
RECV: <iq type='result' to='romeo@montague.lit/orchard' from='garden.montague.lit' id='247'>
<conference xmlns='http://jitsi.org/protocol/colibri' id='49a91b4f6694bc6a'>
<content name='audio'>
<channel rtp-level-relay-type='mixer' direction='recvonly' initiator='true'
id='e97d7f794fbed74b' expire='60'>
<source xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' ssrc='2579640556'/>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='75e88spurhqbih628ord5a3l9b' ufrag='6c7a6'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
A9:...:2F
</fingerprint>
<candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
port='5168' foundation='3' generation='0' priority='2113932031'
network='0'/>
<candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
port='5169' foundation='3' generation='0' priority='2113932030'
network='0'/>
</transport>
</channel>
</content>
<content name='video'>
<channel rtp-level-relay-type='translator' initiator='true'
id='b4557f274216f99a' expire='60'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='1oriuuhjfq6884ln9d3g1rjq13' ufrag='3gh3o'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-1'>
D7:...:C2
</fingerprint>
<candidate type='host' protocol='udp' id='1' ip='10.0.1.1' component='1'
port='5170' foundation='3' generation='0' priority='2113932031'
network='0'/>
<candidate type='host' protocol='udp' id='2' ip='10.0.1.1' component='2'
port='5171' foundation='3' generation='0' priority='2113932030'
network='0'/>
</transport>
</channel>
</content>
</conference>
</iq>
]]></example>
</section2>
</section1>
<!--
<section1 topic='Use with Jingle' anchor='use-with-jingle'>
<p>TODO: a non-normative section showing the flow of jingle sessions and bridge interaction</p>
</section1>
-->
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports COLIBRI, it SHOULD advertise that fact by
returning
a feature of "http://jitsi.org/protocol/colibri" in response to
a &xep0030;
information request.
</p>
<example caption="Service Discovery Information Request"><![CDATA[
<iq from='kingclaudius@shakespeare.lit/castle'
id='ku6e51v3'
to='belfry.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery Information Response"><![CDATA[
<iq from='belfry.shakespeare.lit'
id='ku6e51v3'
to='kingclaudius@shakespeare.lit/castle'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jitsi.org/protocol/colibri'/>
</query>
</iq>
]]></example>
<p>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 &xep0115;. However, if an
application has
not received entity capabilities information from an entity, it
SHOULD use
explicit service discovery instead.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>PENDING</p>
</section1>
<section1 topic='Open Issues' anchor='issues'>
<p>PENDING</p>
</section1>
<section1 topic='XML Schemas' anchor='schema'>
<p>PENDING</p>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
<p>Jitsi's participation in this specification is funded by the
NLnet
Foundation.
</p>
</section1>
</xep>

397
inbox/dynamic-forms.xml
View File

@ -8,21 +8,13 @@
<header>
<title>Data Forms - Dynamic Forms</title>
<abstract>
This specification provides extensions to the data forms model defined in previous XEPs that permits enhanced end-user interaction and
a better user experience. It permits forms to react on user input by permitting the addition, updating or removal of fields in the form,
server-side validation of fields as well as define new states making it possible to display disabled controls,
This specification provides extensions to the data forms model defined in previous XEPs that permit enhanced end-user interaction and
a better user experience. These extensions permit forms to react on user input by permitting the addition, updating or removal of fields in the form
and server-side validation of fields. The extension also defines new states making it possible to display disabled controls,
controls with undefined values or error messages, while still being backwards compatible with the existing data form model with available
extensions.
</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), 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.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; 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. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<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 out of the use or inability to use 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.</liability>
<conformance>
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
</conformance>
</legal>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
@ -34,7 +26,7 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<shortname>dynamic-forms</shortname>
<author>
<firstname>Peter</firstname>
<surname>Waher</surname>
@ -42,6 +34,34 @@
<jid>peter.waher@jabber.org</jid>
<uri>http://www.linkedin.com/in/peterwaher</uri>
</author>
<revision>
<version>0.0.4</version>
<date>2013-12-18</date>
<initials>pw</initials>
<remark>
<p>The element formPostBack has been renamed to <strong>submit</strong>.</p>
<p>The element formUpdated has been renamed to <strong>updated</strong>.</p>
<p>The elements formPostBackResponse and cancelResponse have been removed. Error handling has been updated to conform to use IQ error stanzas and error codes.</p>
</remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2013-12-04</date>
<initials>pw</initials>
<remark>
<p>Namespace changed to urn:xmpp:xdata:dynamic.</p>
</remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2013-10-29</date>
<initials>pw</initials>
<remark>
<p>Added comparison to XEP-0050, Ad-hoc commands.</p>
<p>Added support for server push of asynchronous form changes.</p>
<p>Added an implementation note regarding client-side values.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-07-23</date>
@ -119,6 +139,12 @@
editing the form.
</p>
</li>
<li>
<p>
Permits spontaneous updates of the form, pushed from the form server to the client showing the form. This might be necessary in
cases where the process of aquiring current values may take some time, but the client is required to show a form right away.
</p>
</li>
</ul>
<p>
<strong>Note:</strong> This extension is only dependent upon the <link url='http://xmpp.org/extensions/xep-0004.html'>Data Forms</link> XEP. It works in
@ -126,6 +152,103 @@
in this document may still reference extensions made in other documents, but these are considered to be examples only, used to illustrate
a specific point or example.
</p>
<section2 topic='Comparison to Ad-hoc commands'>
<p>
&xep0050; defines a mechanism to enhance data forms creating dialog wizards with actions that guide the user through pages, where each page
can depend on the input from previous pages. The following list consists of a comparison of the differences between Ad-hoc commands and
Dynamic Forms, and why this extension is not based on the concepts defined in XEP-0050:
</p>
<ul>
<li>
<p>
The main point of this extension is to make the current form dynamic. Pages in a wizard, as defined in ad-hoc commands, are still static
requiring page navigation for the dialog to be updated.
</p>
</li>
<li>
<p>
There might be a desire to make individual pages inside a wizard dynamic by themselves. In this case, this extension might be used to
extend Ad-hoc commands with dynamic pages inside wizards.
</p>
</li>
<li>
<p>
Wizards order their pages linearly, in a one-dimensional array of pages. Navigation is only performed using prev and next actions, and completed with the execute or
complete actions. This might work sufficiently well where page output only is based on input from the previous page. But as soon as the input depends on more pages,
navigation becomes unnecessarily cumbersome. For example a dialog with country, region, city, area, street, building, apartment. To change the country parameter when you
are on the apartment page, requires you to back through many pages, while in the dynamic form you just change the parameter directly, since all are visible
in the same form.
</p>
<p>
The problem gets worse if this is a normal behavior for a form. Say a dialog with a post carrier field, followed by country, city, office, etc.
When the user comes to office and notices that the selected carrier has no office close to you, you change carrier, but don't want to change country and city, if
possible.
</p>
</li>
<li>
<p>
The pages in a wizard do not allow for spontaneous or immediate feedback to the user. Such immediate feedback is of great importance in user-friendly
forms, where complex input is required. Consider the following simple example:
</p>
<p>
Imagine a dialog used for configuring a TCP port scanner to search for specific devices in a network. It might take five parameters: IP range, port range, number of threads,
connection timeout (ms) and number of tries before failing. However, the operator wants to know how much time the operation will take (which is #IP-addresses *
#port numbers * Connection Timeout * Nr Tries / #Threads). To see this in a separate page and then have to go back to the different pages, forwarding to the
time estimate calculation page, etc., is a very cumbersome process. Presenting all this information on a single page using Dynamic Forms is creates a much
better and richer user experience. Changing the value of any of the five parameters will directly update a text parameter presenting the total expected time of the
operation.
</p>
</li>
<li>
<p>
Wizards as defined in Ad-hoc commands are hard-wired to commands as such. Navigation actions are defined outside of the scope of the form itself. This extensions
defines Dynamic Forms as an extension of the Data Form concept. All navigation, post-back fields, etc., are defined within the actual form itself. This makes
it re-usable everywhere data forms are used, including pages inside an Ad-Hoc command wizard.
</p>
</li>
<li>
<p>
Ad-hoc command wizards include the feature to return notes including information, warnings or error information to the user. This information however, is associated
with the current page in the wizard itself. Dynamic Forms contains a means to attach error information directly to individual fields, making feedback more precise.
Together with the server post-back feature immediate server-side validation during user input is possible.
</p>
</li>
<li>
<p>
Dynamic Forms contains a feature that ad-hoc command wizards do not: Read-only fields. These differs from other text fields in that they are rendered as normal
controls, except input is read-only. Together with the server post-back feature this allows the server to enable and disable parameters depending on user
input on the same page. An example can be a checkbox that enabled another field if checked, as a security measure.
</p>
</li>
<li>
<p>
Dynamic Forms defines the concept of an undefined field value. These fields are presented with the available value (if any), but greyed out, signaling to the user that
the value is not well defined for some reason. Perhaps it is only one of many values held my multiple objects in the case when editing multiple objects at once.
Undefined values are not sent back to the server when the form is posted back. When the user edits such a field, the undefined flag is cleared and the field is
presented as a normal control. The main purpose of this flag is to allow for editing multiple objects at once or for editing control forms where current states are
not known at the moment if creating the form.
</p>
</li>
<li>
<p>
Dynamic Forms supports asynchronous updates of the form, where the server can push changes to the form not resulting from user input. This is a powerful feature that
allows the server to update a form being edited by the user to reflect changes on the server. Consider the following examples:
</p>
<p>
Consider a control form containing control fields on a remote device. At the time of displaying the form, the current states of some fields might be unknown. So the fields
are marked perhaps with some default values, but with the undefined flag set for the corresponding fields. At the time of creating the form, a parallel request is made
to the device by the form server, requesting information about current states of the device. When these are received by the server, it issues an update of the form to the
client with the newly received and current field values. The request for values might take some time, so using this mechanism provides a form to the user quickly, clearly
indicating what is missing, and then complements the form when data is available.
</p>
<p>
Another example might be a dialog showing contents on the form server in a multi-user environment where updates to the contents is made. An example can be a file system.
If changes to the contents is made by another user, the server has the possibility to update any current forms to reflect changes made. This decreases the possibility
of inconsistencies in the system, and at the same time increases the user-friendliness of the end-user experience of the application.
</p>
</li>
</ul>
</section2>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<p>The following table lists terms and corresponding descriptions or definitions for use throughout this document.</p>
@ -171,7 +294,7 @@
<section1 topic='Use Cases' anchor='usecases'>
<p>
The following subsections list use cases for the different enhancements defined by this extension. Elements are defined using the namespace
<strong>http://jabber.org/protocol/xdata-dynamic</strong> and namespace prefix <strong>xdd</strong>.
<strong>urn:xmpp:xdata:dynamic</strong> and namespace prefix <strong>xdd</strong>.
</p>
<section2 topic='Publishing post-back fields'>
<p>
@ -185,7 +308,7 @@
<example caption='Publishing post-back fields'>
<![CDATA[
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="http://jabber.org/protocol/xdata-dynamic"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Current location</title>
<instructions>Select your current location to continue.</instructions>
@ -220,7 +343,7 @@
</section2>
<section2 topic='Performing a server post-back'>
<p>
A server post-back is performed by sending an IQ set stanza with a <strong>formPostBack</strong> child element containing the
A server post-back is performed by sending an IQ set stanza with a <strong>submit</strong> child element containing the
current state of the form. The type of the form must be <strong>submit</strong>. The client should also provide the current
user language in a <strong>xml:lang</strong> attribute, if available.
</p>
@ -230,7 +353,7 @@
from='formclient@clayster.com/client'
to='formserver@clayster.com'
id='1'>
<formPostBack xmlns='http://jabber.org/protocol/xdata-dynamic' xml:lang='en'>
<submit xmlns='urn:xmpp:xdata:dynamic' xml:lang='en'>
<x xmlns="jabber:x:data" type="submit">
<field var='xdd session'>
<value>009c7956-001c-43fb-8edb-76bcf74272c9</value>
@ -239,7 +362,7 @@
<value>CL</value>
</field>
</x>
</formPostBack>
</submit>
</iq>]]>
</example>
<p>
@ -247,8 +370,7 @@
submission of the data form.
</p>
<p>
As a response to a successful form post-back, the server returns a <strong>formPostBackResponse</strong> element with a result code of <strong>OK</strong>
containing a new data form, as is shown in the following example:
As a response to a successful form post-back, the server returns the new data form, as is shown in the following example:
</p>
<example caption='Post-back response'>
<![CDATA[
@ -256,9 +378,8 @@
from='formserver@clayster.com'
to='formclient@clayster.com/client'
id='1'>
<formPostBackResponse xmlns='http://jabber.org/protocol/xdata-dynamic' result='OK'>
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="http://jabber.org/protocol/xdata-dynamic"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Current location</title>
<instructions>Select your current location to continue.</instructions>
@ -302,7 +423,6 @@
...
</field>
</x>
</formPostBackResponse>
</iq>]]>
</example>
<p>
@ -326,7 +446,7 @@
<example caption='Publishing read-only fields'>
<![CDATA[
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="http://jabber.org/protocol/xdata-dynamic"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Object properties</title>
<field var='xdd session' type='hidden'>
@ -356,6 +476,10 @@
flag instead, gives greater flexibility when it comes to presentation, as well as permitting the form server
to enable and disable controls during the lifetime of the form.
</p>
<p>
<strong>Note 2:</strong> Make sure to check the implementation note <link url='#clientsidevalues'>Merging Client-Side Values</link> for information
on how to merge updates received from the server with current input made by the client.
</p>
</section2>
<section2 topic='Publishing fields with undefined values'>
<p>
@ -380,7 +504,7 @@
<example caption='Publishing fields with undefined values'>
<![CDATA[
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="http://jabber.org/protocol/xdata-dynamic"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Communication properties</title>
<field var='xdd session' type='hidden'>
@ -429,7 +553,7 @@
<example caption='Publishing fields with undefined values'>
<![CDATA[
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="http://jabber.org/protocol/xdata-dynamic"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Expression</title>
<field var='xdd session' type='hidden'>
@ -474,49 +598,55 @@
from='formclient@clayster.com/client'
to='formserver@clayster.com'
id='4'>
<cancel xmlns='http://jabber.org/protocol/xdata-dynamic'>
<cancel xmlns='urn:xmpp:xdata:dynamic'>
<x xmlns="jabber:x:data" type="submit">
<field var='xdd session'>
<value>009c7956-001c-43fb-8edb-76bcf74272c9</value>
</field>
...
</x>
</formPostBack>
</cancel>
</iq>]]>
</example>
<p>
After receiving the cancel request the form server returns a cancel response having a result code of <strong>OK</strong> if the form
was found (and therefore cancelled), or <strong>NotFound</strong> if the form was not found. The following example shows an OK response:
After receiving the cancel request the form server returns an empty response if the form was found (and therefore cancelled), or an
IQ error stanza with an <strong>item-not-found</strong> error if the form was not found. The following example shows a response where
the form was found and cancelled:
</p>
<example caption='Dynamic form cancelled'>
<![CDATA[
<iq type='result'
from='formserver@clayster.com'
to='formclient@clayster.com/client'
id='4'>
<cancelResponse xmlns='http://jabber.org/protocol/xdata-dynamic' result='OK'/>
</iq>]]>
id='4'/>]]>
</example>
<p>
<strong>Note:</strong> If cancelling a dynamic form using the approach described in this document, there's no need to also submit
a cancel form as defined in the <link url='http://xmpp.org/extensions/xep-0004.html'>Data Forms</link> XEP. The form server automatically
makes sure the form is cancelled in all instances on the form server.
</p>
<p>
<strong>Note 2:</strong> If the dynamic form is invoked from a specific operation that includes its own cancel procedure, like
Ad-hoc command sessions, the dynamic form is automatically and implicitly cancelled if the corresponding operation is cancelled.
There is no need to explicitly cancel the dynamic form as explained in this section in such cases.
</p>
</section2>
<section2 topic='Dynamic form not found during post-back'>
<p>
It might happen that the form server does not find the dynamic form posted by the form client during a post back. Reasons for this can be
that the form does not include a post-back field, or that a form session timeout has occurred and the form server has discarded the dynamic
form to avoid memory leaks. Regardless of the reason, the form server responds using a <strong>NotFound</strong> result in the response, when
the client posts a form that is not found back.
form to avoid memory leaks. Regardless of the reason, the form server responds using an IQ error stanza with the <strong>item-not-found</strong>
error, when the client posts a form that is not found back.
</p>
<example caption='Dynamic form not found during post-back'>
<![CDATA[
<iq type='result'
<iq type='error'
from='formserver@clayster.com'
to='formclient@clayster.com/client'
id='2'>
<formPostBackResponse xmlns='http://jabber.org/protocol/xdata-dynamic' result='NotFound'/>
<error type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>]]>
</example>
<p>
@ -526,25 +656,99 @@
</section2>
<section2 topic='Other error during post-back'>
<p>
If another error occurs during post-back, the form server can inform the client about this, using the <strong>OtherError</strong>
result code, and include an <strong>error</strong> element to describe the error, as is shown in the following example:
If another error occurs during post-back, the form server can inform the client about this by using the relevant error element and
provide further information in a <strong>text</strong> element to describe the error, as is shown in the following example:
</p>
<example caption='Other error during post-back'>
<![CDATA[
<iq type='result'
<iq type='error'
from='formserver@clayster.com'
to='formclient@clayster.com/client'
id='3'>
<formPostBackResponse xmlns='http://jabber.org/protocol/xdata-dynamic' result='OtherError'>
<error>An internal error occurred: Stack limit has been reached.</error>
</formPostBackResponse>
<error type='cancel'>
<internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text>An internal error occurred: Stack limit has been reached.</text>
</error>
</iq>]]>
</example>
</section2>
<section2 topic='Asynchronous updates of forms (server push)'>
<p>
The server may send asynchronous updates to open forms on the client. This can be done if the server detects changes that it wants to inform
the client about. Changes are made by sending a <strong>message</strong> stanza including a <strong>updated</strong> element which in turn
contains the new updated form.
</p>
<p>
Examples can include a control form showing control parameters. While the server is trying to retrieve the current values
it presents the control form with undefined values, and later when values are received by the server, it sends an update to the client with
actual values.
</p>
<p>
Another example can include a dialog containing information on items on the server in a multi-user environment (for instance a file system).
Changes made by users can be displayed in open dialogs to other users as they change.
</p>
<p>
The client may have more than one form open at any given time. It might also be so that the form has been closed prior to receiving or handling the update message,
and is therefore no longer visible. To be able to identify to which form the update corresponds, the <strong>updated</strong>
element is required to include a <strong>sessionVariable</strong> attribute in which it identifies a <strong>unique</strong> identifying
field in the form. When the client receives the update, it goes through all forms it has open. If a form has a field variable with a corresponding
name, and the field variable has a value equal to the value in the updated form, the form should be updated by the contents of the message. If no form is found,
the update is simply ignored. If multiple forms are found, all should be updated.
</p>
<example caption='Asynchronous update of form (server push)'>
<![CDATA[
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Control parameters</title>
<field var='xdd session' type='hidden'>
<value>009c7956-001c-43fb-8edb-76bcf74272c9</value>
</field>
<field var="AnalogOutput" type="text-single" label="Analog Output:">
<desc>Enter a new value for the analog output.</desc>
<xdv:validate xmlns:xdv="http://jabber.org/protocol/xdata-validate" datatype="xs:int">
<xdv:range min="0" max="65535"/>
</xdv:validate>
<value>0</value>
<xdd:notSame/>
</field>
</x>
...
<message from='server@clayster.com'
to='client@clayster.com/client'>
<updated xmlns='urn:xmpp:xdata:dynamic' sessionVariable='xdd session' xml:lang='en'>
<x xmlns="jabber:x:data" type="form"
xmlns:xdd="urn:xmpp:xdata:dynamic"
xmlns:xdv="http://jabber.org/protocol/xdata-validate">
<title>Control parameters</title>
<field var='xdd session' type='hidden'>
<value>009c7956-001c-43fb-8edb-76bcf74272c9</value>
</field>
<field var="AnalogOutput" type="text-single" label="Analog Output:">
<desc>Enter a new value for the analog output.</desc>
<xdv:validate xmlns:xdv="http://jabber.org/protocol/xdata-validate" datatype="xs:int">
<xdv:range min="0" max="65535"/>
</xdv:validate>
<value>49152</value>
</field>
</x>
</updated>
</message>]]>
</example>
<p>
<strong>Note:</strong> Make sure to check the implementation note <link url='#clientsidevalues'>Merging Client-Side Values</link> for information
on how to merge updates received from the server with current input made by the client.
</p>
<p>
<strong>Note 2:</strong> The client should also provide the current user language in a <strong>xml:lang</strong> attribute in the <strong>updated</strong>
element, if available, as is shown in the example above.
</p>
</section2>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the protocol specified herein, regardless if the entity represents a form server or a form client; it MUST advertise
that fact by returning a feature of "http://jabber.org/protocol/xdata-dynamic" in response to &xep0030; information requests.</p>
that fact by returning a feature of "urn:xmpp:xdata:dynamic" in response to &xep0030; information requests.</p>
<example caption="Service discovery information request">
<![CDATA[
<iq type='get'
@ -562,7 +766,7 @@
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='http://jabber.org/protocol/xdata-dynamic'/>
<feature var='urn:xmpp:xdata:dynamic'/>
...
</query>
</iq>]]>
@ -594,7 +798,7 @@
The form server must be aware that some form clients do not support dynamic forms. This in turn implies that form clients
may not call the correct cancel method to cancel a dynamic form. To protect the form server from memory leaks, it must
include a session timeout, and release any dynamic form session resources if no activity has been made during the
corresponding time period. If the client would perform a post-back after the timeout period, a <strong>NotFound</strong>
corresponding time period. If the client would perform a post-back after the timeout period, an <strong>item-not-found</strong>
error message must be returned, to show the corresponding dynamic form session no longer exists, and therefore could
not be found.
</p>
@ -602,6 +806,73 @@
For normal operations, a dynamic form session timeout of 15 minutes is sufficient.
</p>
</section2>
<section2 topic='Merging Client-Side Values' anchor='clientsidevalues'>
<p>
When receiving asynchronous form updates from the server, or when performing a server post-back of a form, it is important
to know how to merge responses from the server with the current form being displayed to the user. As the operation is
asynchronous, and since user input is quick, the user might have input things not known to the server and therefore not
available in form updates. Also, fields not marked for post-back might not have been reported at all to the server, and
therefore, the client is the only one that knows what the user has entered into these fields.
</p>
<p>
So, when receiving form updates, either asynchronously, or as part of a server post-back response, the client needs to merge
the updated form, with the current form. The following rules must be applied. Here, the <strong>updated form</strong> represents the
form in the recent message from the server, the <strong>current form</strong> represents the form currently being edited by the user
and the <strong>resulting form</strong> represents the result of the merger of the updated form and the current form.
</p>
<ul>
<li>
<p>
New fields in the updated form not available in the <strong>current form</strong>, are added as-is to the <strong>resulting form</strong>.
</p>
</li>
<li>
<p>
Fields not available in the <strong>updated form</strong> but available in the <strong>current form</strong>, must be removed from the
<strong>resulting form</strong> regardless if user input is available. Any such user input is lost.
</p>
</li>
<li>
<p>
The order of fields in the resulting form must be the same as the order of fields in the <strong>updated form</strong>.
</p>
</li>
<li>
<p>
Fields available in both the <strong>updated form</strong> and the <strong>current form</strong> are handled depending on if the user has entered
values in the corresponding field in the <strong>current form</strong> or not:
</p>
<ul>
<li>
If the user has <strong>not</strong> edited the value in the corresponding field, the value from the <strong>updated form</strong> is used.
</li>
<li>
If the user has edited the value the corresponding field, the value from the <strong>current form</strong> is used.
</li>
<li>
If the user has edited the value of the corresponding field in the <strong>current form</strong>, but the value is the same as the value
available in the <strong>updated form</strong>, the flag stating that user input has occurred in the field can be cleared.
</li>
</ul>
<br/>
</li>
<li>
<p>
If a field in the <strong>updated form</strong> is flagged as <strong>undefined</strong>, but the <strong>current form</strong> has an edited value,
the form in the <strong>resulting form</strong> must <strong>not</strong> be marked as <strong>undefined</strong>.
</p>
</li>
<li>
<p>
All other properties for fields must be taken from the <strong>updated form</strong> and copied to the <strong>resulting form</strong>.
</p>
</li>
</ul>
<p>
How the above merger is made is implementation specific. One simple implementation can simply be taking the updated form, adding any client-side values to it
(i.e. values edited in the current form) perhaps removing any undefined value flags, and then use the result as a model for the resulting form.
</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>
@ -624,8 +895,8 @@
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/xdata-dynamic'
xmlns='http://jabber.org/protocol/xdata-dynamic'
targetNamespace='urn:xmpp:xdata:dynamic'
xmlns='urn:xmpp:xdata:dynamic'
xmlns:xd="jabber:x:data"
elementFormDefault='qualified'>
@ -661,7 +932,7 @@
</xs:simpleType>
</xs:element>
<xs:element name='formPostBack'>
<xs:element name='submit'>
<xs:complexType>
<xs:sequence>
<xs:element ref='xd:x' minOccurs='1' maxOccurs='1'/>
@ -669,24 +940,15 @@
</xs:complexType>
</xs:element>
<xs:element name='formPostBackResponse'>
<xs:element name='updated'>
<xs:complexType>
<xs:choice>
<xs:element ref='xd:x' minOccurs='0' maxOccurs='1'/>
<xs:element name='error' type='xs:string' minOccurs='0' maxOccurs='1'/>
</xs:choice>
<xs:attribute name='result' type='PostBackResultCode' use='required'/>
<xs:sequence>
<xs:element ref='xd:x' minOccurs='1' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='sessionVariable' type='xs:string' use='required'/>
</xs:complexType>
</xs:element>
<xs:simpleType name='PostBackResultCode'>
<xs:restriction base='xs:string'>
<xs:enumeration value='OK'/>
<xs:enumeration value='NotFound'/>
<xs:enumeration value='OtherError'/>
</xs:restriction>
</xs:simpleType>
<xs:element name='cancel'>
<xs:complexType>
<xs:sequence>
@ -695,13 +957,10 @@
</xs:complexType>
</xs:element>
<xs:element name='cancelResponse'>
<xs:complexType>
<xs:attribute name='result' type='PostBackResultCode' use='required'/>
</xs:complexType>
</xs:element>
</xs:schema>]]>
</code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Karin Forsell and Lance Stout for all valuable feedback.</p>
</section1>
</xep>

560
inbox/eventlogging.xml Normal file
View File

@ -0,0 +1,560 @@
<?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>Event Logging over XMPP</title>
<abstract>This specification provides a common framework for sending events to event logs over XMPP networks.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>eventlogging</shortname>
<author>
<firstname>Peter</firstname>
<surname>Waher</surname>
<email>peter.waher@clayster.com</email>
<jid>peter.waher@jabber.org</jid>
<uri>http://www.linkedin.com/in/peterwaher</uri>
</author>
<revision>
<version>0.0.2</version>
<date>2013-12-02</date>
<initials>pw</initials>
<remark>
<p>Addressed pre-publication feedback from the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-11-10</date>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
to analyze the status or operation of the network and its participants.
</p>
<p>
The basic principle behind interoperable event logging over XMPP is the definition of a common XML element defining the event. This payload is then sent in
a normal message stanza (i.e. with <strong>type='normal'</strong>) to the recipient. The recipient in turn, if it understands the payload, can choose to store it in an event log, forward it or
analyze it accordingly.
</p>
<p>
There are various event log packages available, but none yet defined for XMPP or using a well-defined and known XML format. Therefore, this document defines
such an XML format. This format is able to store <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link> <note>
RFC-5424: The Syslog Protocol &lt;<link url='https://tools.ietf.org/html/rfc5424'>https://tools.ietf.org/html/rfc5424</link>&gt;
</note> compliant event information, even though the <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link> event model has been somewhat extended.
Also, in the use of the facility attribute, this XEP does not have the same restrictions compared to the <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link> specification.
</p>
<p>
This document does not restrict the use of event messages to directed message stanzas alone. It may be envisioned that some would like to publish event information through
&xep0060; or other mechanisms. It is not in the scope of this document to specify such transports however, as it only deals with direct messages, but a brief list is provided
in the <link url='#transportoptions'>Security Considerations</link> section.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<p>The following table lists common terms and corresponding descriptions.</p>
<dl>
<di>
<dt>Event</dt>
<dd>A piece of information describing an event in time.</dd>
</di>
<di>
<dt>Event ID</dt>
<dd>An attribute providing a machine readable ID to the type of event in question without having to parse the message text itself.</dd>
</di>
<di>
<dt>Event Level</dt>
<dd>Provides an additional level on the previous classification (Minor, Medium, Major).</dd>
</di>
<di>
<dt>Event Type</dt>
<dd>Coarse classification of the event (Debug, Informational, Notice, Warning, Error, Critical, Alert, Emergency).</dd>
</di>
<di>
<dt>Facility</dt>
<dd>What type of device, server, application, etc., is sending the message. </dd>
</di>
<di>
<dt>Message</dt>
<dd>A (human readable) text message describing what has occurred.</dd>
</di>
<di>
<dt>Module</dt>
<dd>
The module reporting the event. Larger software packages are often divided into modules. Keeping track of which modules report which events can be useful when
analyzing system performance.
</dd>
</di>
<di>
<dt>Object</dt>
<dd>The object to which the event message refers to, on which the current action is performed.</dd>
</di>
<di>
<dt>Stack Trace</dt>
<dd>
Exact position in the code from which the event was reported or where the error occurred. Reporting it in a separate attribute unclutters the message, and removes the need
to define custom tags.
</dd>
</di>
<di>
<dt>Subject</dt>
<dd>The subject causing the event to take place or performing the action (for instance, user, process, etc.)</dd>
</di>
<di>
<dt>Tag</dt>
<dd>A custom tag or parameter attached to an event. Each tag has a name and a value and an optional data type.</dd>
</di>
<di>
<dt>Timestamp</dt>
<dd>When the event occurred.</dd>
</di>
</dl>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Sending a simple event message' anchor='simpleevent'>
<p>
The following example shows how to send a simple event using a normal message to an event log. Only two parameters are required:
The timestamp of the message goes into the <strong>timestamp</strong> attribute, and the actual messages goes into a child element
named <strong>message</strong>. This event will be treated as a <strong>Minor Informational</strong> event by the recipient.
</p>
<example caption='Simple event message'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:52:23Z'>
<message>Something happened.</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Sending a multi-line event message' anchor='multilinemessage'>
<p>
The following example shows how to send a multi-line event.
</p>
<example caption='Multi-line event message'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-12T11:47:12Z'>
<message>10 objects deleted:
Object 1
...
Object 10</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Specifying type and level' anchor='typelevel'>
<p>
The following example shows how an event message can be categorized with an event type and level.
</p>
<example caption='Specifying type and level'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:54:55Z' type='Warning' level='Major'>
<message>Low on memory.</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Specifying object and subject' anchor='objectsubject'>
<p>
The following example shows how an event message can be further enhanced by providing object and subject information.
</p>
<example caption='Specifying object and subject'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:58:12Z' type='Informational' level='Major' object='Towel' subject='Arthur Dent'>
<message>Object deleted.</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Specifying an event ID' anchor='eventids'>
<p>
The following example shows how to send an event message with an event ID that can be singled out later to be analyzed by administrators, for instance.
</p>
<example caption='Specifying an event ID'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' id='LoginFailed' timestamp='2013-11-10T16:04:45Z' type='Warning' level='Minor' object='user1' subject='10.0.0.1'>
<message>User attempted to login but provided incorrect password.</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Tagging events with custom information' anchor='tags'>
<p>
The following example shows how to tag an event using custom information in a way that is easy to interpret and process.
</p>
<example caption='Tagging events with custom information'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T16:07:01Z' type='Informational' level='Minor'>
<message>Current resources.</message>
<tag name='RAM' value='1655709892' type='xs:long'/>
<tag name='CPU' value='75.45' type='xs:double'/>
<tag name='HardDrive' value='163208757248' type='xs:long'/>
</log>
</message>]]>
</example>
<strong>Note:</strong> Any <strong>tag</strong> elements must come after the <strong>message</strong> element.
</section2>
<section2 topic='Specifying program module' anchor='modules'>
<p>
The following example shows how module information can be provided in events to more easily be able to single out information
relating to the same application running on different machines.
</p>
<example caption='Specifying program module'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T16:17:56Z' type='Error' level='Major' object='object1' subject='user1' module='application1'>
<message>Something horrible happened.</message>
</log>
</message>]]>
</example>
</section2>
<section2 topic='Sending debug information' anchor='debug'>
<p>
The following example shows how to send a debug message with a stack trace, module and custom information.
</p>
<example caption='Sending debug information'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T16:12:25Z' type='Debug' level='Major' module='My new application' stackTrace='file1, line 1, ...'>
<message>Something is rotten in the state of Denmark.</message>
<tag name='a' value='1' type='xs:int'/>
<tag name='b' value='10' type='xs:int'/>
<tag name='s' value='Hello World!' type='xs:string'/>
<stackTrace>File1, Line1, ...
File2, Line2, ...
...</stackTrace>
</log>
</message>]]>
</example>
<strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.
</section2>
<section2 topic='Sending multiple events' anchor='multipleevents'>
<p>
The following example shows how multiple events can be sent in a single message. The receiver should interpret this as two different events having been received.
</p>
<example caption='Sending multiple events'>
<![CDATA[
<message from='device@clayster.com/device' to='eventlog@clayster.com' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:52:23Z'>
<message>Something happened.</message>
</log>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:54:23Z'>
<message>Something else happened.</message>
</log>
</message>]]>
</example>
</section2>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the reception of events as specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:eventlog" in response to &xep0030; information requests.</p>
<example caption="Service discovery information request">
<![CDATA[
<iq type='get'
from='device@clayster.com/device'
to='eventlog@clayster.com'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]>
</example>
<example caption="Service discovery information response">
<![CDATA[
<iq type='result'
from='eventlog@clayster.com'
to='device@clayster.com/device'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:eventlog'/>
...
</query>
</iq>]]>
</example>
<p>
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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Event Type' anchor='eventtype'>
<p>
The following table lists possible event types that can be used. If none is specified for an event, it is assumed that the event is <strong>Informational</strong>.
It is largely based on the severity levels of <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link>.
</p>
<table caption='Event Types'>
<tr>
<th>Type</th>
<th>Description</th>
</tr>
<tr>
<td>Debug</td>
<td>Developers can ask applications to send debug messages during development or testing to more easily see what happens in a system.</td>
</tr>
<tr>
<td>Informational</td>
<td>An informational message describing a normal event.</td>
</tr>
<tr>
<td>Notice</td>
<td>Represents a significant condition or change that administrators should be aware of.</td>
</tr>
<tr>
<td>Warning</td>
<td>A warning condition. If not taken into account, the condition could turn into an error.</td>
</tr>
<tr>
<td>Error</td>
<td>An error condition. A condition has been detected that is considered to be an error or a fault.</td>
</tr>
<tr>
<td>Critical</td>
<td>A critical condition. An error so great that it could escalate into something graver if not addressed.</td>
</tr>
<tr>
<td>Alert</td>
<td>An alert condition. Action must be taken immediately.</td>
</tr>
<tr>
<td>Emergency</td>
<td>System is unusable.</td>
</tr>
</table>
</section2>
<section2 topic='Event Level' anchor='eventlevel'>
<p>
Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).
</p>
<table caption='Event Levels'>
<tr>
<th>Level</th>
<th>Description</th>
</tr>
<tr>
<td>Minor</td>
<td>Minor events, concerning normal operating procedures.</td>
</tr>
<tr>
<td>Medium</td>
<td>Medium events.</td>
</tr>
<tr>
<td>Major</td>
<td>More substantial events or events that are affecting larger parts of the system.</td>
</tr>
</table>
</section2>
<section2 topic='Event ID' anchor='eventid'>
<p>
Using Event IDs, the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc.
It is easier to group, parse or interpret events and their tags if you know what type of event it is. Event IDs are manufacturer specific, and only provide a means
to more easily extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).
</p>
<p>
<strong>Note:</strong> To avoid problems when running applications using different locales, event IDs should never be localized.
</p>
</section2>
<section2 topic='Object' anchor='object'>
<p>
An event is often linked to an object, e.g. on which object an action was performed, or which object is reporting a condition. The object field permits
the tagging of objects in a common way. It is later easy to extract all events relating to a specific object by using this attribute.
</p>
</section2>
<section2 topic='Subject' anchor='subject'>
<p>
An event is often also linked to a subject, i.e. who or what performed a given action resulting in the event or condition. The subject field permits
the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subject by using this attribute.
</p>
</section2>
<section2 topic='Facility' anchor='facility'>
<p>
Facility can be either a facility in the network sense or in the system sense. This document does not restrict its use to the possible choices defined by
other protocols such as <link url='https://tools.ietf.org/html/rfc5424'>Syslog</link>, and leaves it open. However, it is left as a special attribute since
it is important in monitoring applications.
</p>
</section2>
<section2 topic='Module' anchor='module'>
<p>
A module is part of a larger software package. Using the module attribute makes it easier to attribute events to specific parts of a distributed
application and analyze them separately.
</p>
</section2>
<section2 topic='Stack Trace' anchor='stacktrace'>
<p>
Stack Traces can be important information to developers and correlate events to actual locations in the code that generated the event. This document
does not specify any particular format for stack traces.
</p>
</section2>
<section2 topic='Tag' anchor='tag'>
<p>
Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a data type.
Data types are specified using Qualified Names (QNames). If possible, they should adhere to the list of
<link url='http://xmpp.org/registrar/xdv-datatypes.html'>Data Forms Validation Datatypes</link> <note>
Data Forms Validation Datatypes &lt;<link url='http://xmpp.org/registrar/xdv-datatypes.html'>http://xmpp.org/registrar/xdv-datatypes.html</link>&gt;
</note> that is maintained by the XMPP Registrar.
</p>
<p>
<strong>Note:</strong> To avoid problems when running applications using different locales, tag names should never be localized.
</p>
</section2>
<section2 topic='Normalized tables' anchor='normalizedtables'>
<p>
If persisting received events in a database, care should be taken if normalized tables are used for storage of tags names and values, event IDs, objects, subjects,
facilities and modules. If this is the case, the receiver should look for types of values that can be incompatible with normalized tables (such as floating point values or numbers
in general, GUIDs, resource names in JIDs etc.) and replace them with some descriptive text and append the corresponding value in the message text instead. This to avoid problems with indexes in
databases because of devices implemented by third parties.
</p>
<p>
It is still valid to send information like sequence numbers, unique GUIDs, measurements, resource names in JIDs etc. in tag names and values, but such information
should be avoided in event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line.
</p>
</section2>
<section2 topic='Multi-line messages and stack traces' anchor='multilinemessagesstacktraces'>
<p>
The messag text and stack trace parts of an event message lie as simple type valued child elements (xs:string). This allows for simple encoding of multi-line text
information into these two parameters. However, do not indent new lines when serializing multi-line text to these parameters to make the XML look nicer. The recipient
cannot know what whitespace is indenting and what is part of the actual information.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<section2 topic='Time Zones' anchor='timezones'>
<p>
All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.
</p>
<p>
<strong>Note:</strong> If time zone is not available, it is supposed to be undefined. The recipient of an event message without time zone information
should assume the sender has the same time zone as the received, if not explicitly configured otherwise on the recipient side.
</p>
<p>
If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.
</p>
</section2>
<section2 topic='xml:lang' anchor='lang'>
<p>
Event messages SHOULD contain an <strong>xml:lang</strong> attribute on the message stanza to specify the language
used in message texts, etc. If language information is not available, e.g. if relaying messages are not created by the device itself,
the <strong>xml:lang</strong> attribute can be omitted.
</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Zero configuration' anchor='zeroconf'>
<p>
Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive
and should not be sent to anybody just because they support the event log feature as defined in this document.
</p>
</section2>
<section2 topic='Sensitive information' anchor='sensitiveinfo'>
<p>
<strong>Never</strong> log information that should be handled securely or encrypted, such as passwords.
</p>
</section2>
<section2 topic='Transport options' anchor='transportoptions'>
<p>
The following subsections lists different transport options together with security considerations for each one.
</p>
<section3 topic='Direct messages'>
<p>
This document explicitly describes how to send event messages in direct messages. If sensitive information is being sent,
end-to-end encryption should be considered.
</p>
</section3>
<section3 topic='Publish/Subscribe'>
<p>
Event messages could be published using <link url='http://xmpp.org/extensions/xep-0060.html'>Publish-Subscribe</link>. But, even more care should
be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern
should be avoided.
</p>
</section3>
</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>
The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:eventlog'
xmlns='urn:xmpp:eventlog'
elementFormDefault='qualified'>
<xs:element name='log'>
<xs:complexType>
<xs:sequence>
<xs:element name='message' type='xs:string' minOccurs='1' maxOccurs='1'/>
<xs:element name='tag' minOccurs='0' maxOccurs='unbounded'>
<xs:complexType>
<xs:attribute name='name' type='xs:string' use='required'/>
<xs:attribute name='value' type='xs:string' use='required'/>
<xs:attribute name='type' type='xs:QName' use='optional' default='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='stackTrace' type='xs:string' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='timestamp' type='xs:dateTime' use='required'/>
<xs:attribute name='id' type='xs:string' use='optional'/>
<xs:attribute name='type' type='EventType' use='optional' default='Informational'/>
<xs:attribute name='level' type='EventLevel' use='optional' default='Minor'/>
<xs:attribute name='object' type='xs:string' use='optional'/>
<xs:attribute name='subject' type='xs:string' use='optional'/>
<xs:attribute name='facility' type='xs:string' use='optional'/>
<xs:attribute name='module' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:simpleType name='EventType'>
<xs:restriction base='xs:string'>
<xs:enumeration value='Debug'/>
<xs:enumeration value='Informational'/>
<xs:enumeration value='Notice'/>
<xs:enumeration value='Warning'/>
<xs:enumeration value='Error'/>
<xs:enumeration value='Critical'/>
<xs:enumeration value='Alert'/>
<xs:enumeration value='Emergency'/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='EventLevel'>
<xs:restriction base='xs:string'>
<xs:enumeration value='Major'/>
<xs:enumeration value='Medium'/>
<xs:enumeration value='Minor'/>
</xs:restriction>
</xs:simpleType>
</xs:schema>]]>
</code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks in alphabetical order to Dave Cridland, Joachim Lindborg, Karin Forsell, Ludovic Bocquet, Markus Kohlhase, Matthew Wild, Mike Taylor, Philipp Hancke, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.</p>
</section1>
</xep>

133
inbox/jingle-grouping.xml Normal file
View File

@ -0,0 +1,133 @@
<?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>Jingle Grouping Framework</title>
<abstract>This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<revision>
<version>0.0.1</version>
<date>2013-11-25</date>
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
&fippo;
</header>
<section1 topic="Introduction" anchor="intro">
<p>&rfc5888; defines a framework to group SDP 'm' lines for different purposes. A mapping to Jingle as an extension to &xep0166; is defined in this document.</p>
<p>It is anticipated that the primary use of this is with the &bundle; framework used in WebRTC.</p>
</section1>
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
<p>The SDP format defined in <cite>RFC 5888</cite> is shown below.</p>
<code>
a=group:semantics identification-tag
</code>
<p>An example follows.</p>
<code>
a=group:LS voice webcam
</code>
<p>This SDP attribute is translated to Jingle as a &lt;group/&gt; element qualified by the 'urn:xmpp:jingle:apps:grouping:0' namespace, as shown below. The semantics is mapped to a 'semantics' attribute. The identification-tags are mapped to content elements whose name attribute is set to the identification-tag.</p>
<code><![CDATA[
<group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='semantics'>
<content name='identification-tag 1'/>
<content name='identification-tag 2'/>
</group>
]]></code>
<p>An example follows.</p>
<code><![CDATA[
<group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='LS'>
<content name='voice'/>
<content name='webcam'/>
</group>
]]></code>
<p>The &lt;group/&gt; element is included as child of the &lt;jingle/&gt; element.</p>
<code><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='rg6s5134'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='BUNDLE'>
<content name='voice'/>
<content name='webcam'/>
</group>
<content creator='initiator' name='voice'>
[ ... ]
</content>
<content creator='initiator' name='webcam'>
[ ... ]
</content>
</jingle>
</iq>
]]></code>
<p>Note: the identification-tags correspond to the &lt;content/&gt; 'name' attributes. These in turn map to the 'mid' attribute in SDP.</p>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports the grouping framework described in <cite>RFC 5888</cite>, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5888':</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='calvin@usrobots.lit/lab'
to='herbie@usrobots.lit/home'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
from='herbie@usrobots.lit/home'
to='calvin@usrobots.lit/lab'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:ietf:rfc:5888'/>
</query>
</iq>
]]></example>
<p>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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
<p>Thanks to Emil Ivov and Lance Stout for their feedback.</p>
<p>The XML format for this specification originates from <cite>libjingle</cite><note>libjingle is now part of the WebRTC Native Code Package available from <link url='http://webrtc.org'>webrtc.org</link>.</note>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:jingle:apps:grouping:0</li>
</ul>
<p>The &REGISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TODO</p>
</section1>
</xep>

170
inbox/jingle-sources.xml Normal file
View File

@ -0,0 +1,170 @@
<?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>Source-Specific Media Attributes in Jingle</title>
<abstract>This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<revision>
<version>0.0.1</version>
<date>2013-11-25</date>
<initials>ph</initials>
<remark><p>First draft.</p></remark>
</revision>
&fippo;
</header>
<section1 topic="Introduction" anchor="intro">
<p>&rfc5576; provides a mechanism to describe attributes of individual media sources (identified by their synchronization source) within a media stream. A mapping to Jingle as an extension to &xep0167; is defined in this document.</p>
</section1>
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
<section2 topic='The ssrc attribute' anchor='sdp-ssrc'>
<p>The SDP format defined in <cite>RFC 5576</cite> is shown below.</p>
<code>
a=ssrc:&lt;ssrc-id&gt; &lt;attribute&gt;
a=ssrc:&lt;ssrc-id&gt; &lt;attribute&gt;:&lt;value&gt;
</code>
<p>This maps to Jingle as a &lt;source/&gt; element qualified by the 'urn:xmpp:jingle:apps:rtp:ssma:0' namespace. Since 'ssrc' is a media attribute in SDP, the &lt;source/&gt; element is included as child of the Jingle &lt;description/&gt; element.</p>
<code><![CDATA[
<source ssrc='ssrc-id' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='attribute'/>
<parameter name='attribute' value='value'/>
</source>
]]></code>
<p>Each ssrc-id maps to a &lt;source/&gt; element whose 'ssrc' attribute is set to the ssrc-id. The associated attributes map to &lt;parameter/&gt; children with 'name' and 'value' attributes. If there is no value in the SDP, the value parameter shall be omitted.</p>
<p>An example follows:</p>
<code>
a=ssrc:1656081975 cname:Yv/wvbCdsDW2Prgd
a=ssrc:1656081975 msid:MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIv MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIva0
a=ssrc:1656081975 mslabel:MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIv
a=ssrc:1656081975 label:MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIva0
</code>
<code><![CDATA[
<source ssrc='1656081975' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='cname' value='Yv/wvbCdsDW2Prgd'/>
<parameter name='msid' value='MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIv MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIva0'/>
<parameter name='mslabel' value='MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIv'/>
<parameter name='label' value='MLTJKIHilGn71fNQoszkQ4jlPTuS5vJyKVIva0'/>
</source>
]]></code>
</section2>
<section2 topic='The ssrc-group attribute' anchor='sdp-ssrc-group'>
<p>The SDP format defined in <cite>RFC 5576</cite> is shown below.</p>
<code>
a=ssrc-group:&lt;semantics&gt; &lt;ssrc-id&gt; ...
</code>
<p>This maps to Jingle as a &lt;ssrc-group/&gt; element qualified by the 'urn:xmpp:jingle:apps:rtp:ssma:0' namespace. Like the &lt;source/&gt; element, this is included as child of the Jingle &lt;description/&gt; element. The SDP 'semantics' parameter is mapped to the semantics attribute (for consistency with <cite>FIXME jingle-grouping FIXME</cite>) and the list of ssrc-ids is mapped to &lt;source/&gt; elements whole 'ssrc' attribute is set to the ssrc-id.</p>
<code><![CDATA[
<ssrc-group xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' semantics='semantics'>
<source ssrc='ssrc-id'/>
[...]
</ssrc-group>
]]></code>
</section2>
</section1>
<section1 topic='Example' anchor='example'>
<p>A minimal example follows:</p>
<code>
m=video 1 RTP/SAVPF 100 116 117
a=rtpmap:100 VP8/90000
a=ssrc-group:FID 2301230316 386328120
a=ssrc:2301230316 cname:T5qvrIZj42v//eYQ
a=ssrc:386328120 cname:uEYgNtStZyTF74sM
a=ssrc-group:FID 3139499595 2613715171
a=ssrc:3139499595 cname:re8jhxkly9bxzuxr
a=ssrc:2613715171 cname:f83avsiw6n1m7vi
</code>
<p>This is mapped to Jingle as follows:</p>
<code><![CDATA[
<content creator='initiator' name='webcam'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
<payload-type id='100' name='VP8' clockrate='90000'/>
<ssrc-group xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' semantics='FID'>
<source ssrc='2301230316'/>
<source ssrc='386328120'/>
</ssrc-group>
<ssrc-group xmlns='urn:xmpp:jingle:apps:rtp:ssma:0' semantics='FID'>
<source ssrc='3139499595'/>
<source ssrc='2613715171'/>
</ssrc-group>
<source ssrc='2301230316' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='cname' value='T5qvrIZj42v//eYQ'/>
</source>
<source ssrc='386328120' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='cname' value='uEYgNtStZyTF74sM'/>
</source>
<source ssrc='3139499595' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='cname' value='re8jhxkly9bxzuxr'/>
</source>
<source ssrc='2613715171' xmlns='urn:xmpp:jingle:apps:rtp:ssma:0'>
<parameter name='cname' value='f83avsiw6n1m7vi'/>
</source>
</description>
</content>
]]></code>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports source specific media attributes as described in <cite>RFC 5576</cite>, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5576':</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='calvin@usrobots.lit/lab'
to='herbie@usrobots.lit/home'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
from='herbie@usrobots.lit/home'
to='calvin@usrobots.lit/lab'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:ietf:rfc:5576'/>
</query>
</iq>
]]></example>
<p>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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<!--
<section1 topic='Acknowledgements' anchor='acks'>
</section1>
-->
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:jingle:apps:rtp:ssma:0</li>
</ul>
<p>The &REGISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TODO</p>
</section1>
</xep>

134
inbox/peptzo.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>User Time Zone</title>
<abstract>This specification defines a payload format for communicating information about a user's time zone. The payload format is typically transported using the personal eventing protocol, a profile of XMPP publish-subscribe specified in XEP-0163.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0082</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Lance</firstname>
<surname>Stout</surname>
<email>lance@lance.im</email>
<jid>lance@lance.im</jid>
</author>
<revision>
<version>0.1</version>
<date>2013-10-28</date>
<initials>lance</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0060; and &xep0163; can be used to publish a wide variety of "extended presence" information about users. This document specifies an extended presence payload format that communicates information about a user's time zone. For example, this information may be of interest to a user's contacts for displaying notices advising against starting a chat at 4am in the user's local time.</p>
<p>Time zone information can also be obtained through &xep0202; by directly querying a full JID for a user. However, given that some clients are chiefly concerned with the time zone offset, and in the interest of reducing floods of IQ requests, we define a way to expose the time zone offset via PEP.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<section2 topic='TZO Element' anchor='protocol-elements'>
<p>The numeric time zone offset from UTC for the user is expressed as the textual content of the &lt;tzo/&gt; element qualified by the 'urn:xmpp:timezone:0' namespace. <note>While &xep0202; defines its own &lt;tzo/&gt; element, the schema allows for neither its reuse as a standalone element nor for the use of the &lt;time/&gt; element without a &lt;utc/&gt; element.</note> The format MUST conform to the Time Zone Definition (TZD) specified in &xep0082;.</p>
</section2>
<section2 topic='Transport Mechanism' anchor='protocol-transport'>
<p>When a user wishes to share time zone information, its client may publish that fact to a PEP node whose NodeID is "urn:xmpp:timezone:0" &NSNOTE;. Because time zone information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to the &PRESENCE; stanza type.</p>
<example caption='User Publishes Time Zone Offset'><![CDATA[
<iq type='set' from='juliet@capulet.example/balcony' id='tzo1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:timezone:0'>
<item>
<tzo xmlns='urn:xmpp:timezone:0'>-07:00</tzo>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>The time zone offset is then delivered to all subscribers:</p>
<example caption='Time Zone Offset is Delivered to All Subscribers'><![CDATA[
<message from='juliet@capulet.example' to='romeo@montague.example'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:timezone:0'>
<item id='1feea9cceec2537e1b561e66d45bc566e276f22f'>
<tzo xmlns='urn:xmpp:timezone:0'>-07:00</tzo>
</item>
</items>
</event>
</message>
]]></example>
<p>When the user wishes to stop broadcasting its time zone offset, the user's client SHOULD send an empty &lt;tzo/&gt; element with the same ItemID:</p>
<example caption='User Publishes Stop Information'><![CDATA[
<iq type='set' from='juliet@capulet.example/balcony' id='tzo2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:timezone:0'>
<item id='1feea9cceec2537e1b561e66d45bc566e276f22f'>
<tzo xmlns='urn:xmpp:timezone:0'/>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<example caption='Stop Information is Delivered to All Subscribers'><![CDATA[
<message from='juliet@capulet.example' to='romeo@montague.example'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:timezone:0'>
<item id='1feea9cceec2537e1b561e66d45bc566e276f22f'>
<tzo xmlns='urn:xmpp:timezone:0'/>
</item>
</items>
</event>
</message>
]]></example>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.</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'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>The &REGISTRAR; includes 'urn:xmpp:timezone:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
<ul>
<li>urn:xmpp:timezone:0</li>
</ul>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:timezone:0'
xmlns='urn:xmpp:timezone:0'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
</xs:documentation>
</xs:annotation>
<xs:element name='tzo' type='xs:string'/>
</xs:schema>
]]></code>
</section1>
</xep>

326
inbox/rayo-cpa.xml Normal file
View File

@ -0,0 +1,326 @@
<?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>Rayo CPA</title>
<abstract>This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for performing Call Progress Analysis on a call under the control of a Rayo client.</abstract>
&LEGALNOTICE;
<number>NOT_YET_ASSIGNED</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0327 Rayo</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Ben</firstname>
<surname>Langfeld</surname>
<email>ben@langfeld.me</email>
<jid>ben@langfeld.me</jid>
<uri>http://langfeld.me</uri>
</author>
<revision>
<version>0.0.1</version>
<date>2013-10-02</date>
<initials>bl</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications is to establish the progress characteristics of the session, such as dtmf, fax or modem tones, or to differentiate between a human and an answering machine. This specification extends the core Rayo specification, and specifically its Input component to describe a protocol for establishing such progress analysis and gathering its results.</p>
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='Glossary' anchor='terms-glossary'>
<dl>
<di>
<dt>CPA</dt>
<dd>Call progress analysis.</dd>
</di>
</dl>
</section2>
</section1>
<section1 topic='Session Flow' anchor='session'>
<p>This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.</p>
<p>CPA is achieved as a special case of the core input component. All rules regarding component execution and the input component in particular apply from the core specification. When a call's controlling party wishes to begin detection of signals from the suported set, it SHOULD begin an input component with the mode attribute set as 'cpa'.</p>
<p>The grammars supplied determine the types of signal detected and parameters applied to their detection. The grammars MUST be referenced by URI in the format described <link url="#def-grammar">below</link>. If a Rayo server supports this specification, it MUST invoke its supported CPA function using the parameters provided from the grammars; if it does not support this specification or any of the supplied parameters within the grammar, it MUST raise an error according to the rules in the core specification.</p>
<example caption='Client requests CPA from a call, indicating interest in speech detection and DTMF'><![CDATA[
<iq from='juliet@capulet.lit/balcony'
to='9f00061@call.shakespeare.lit'
type='set'
id='h7ed2'>
<input xmlns='urn:xmpp:rayo:input:1' mode='cpa'>
<grammar url="urn:xmpp:rayo:cpa:speech:1?maxTime=4000;minSpeechDuration=4000;minVolume=10;finalSilence=2000;terminate=true" />
<grammar url="urn:xmpp:rayo:cpa:dtmf:1" />
</input>
</iq>
]]></example>
<p>The server MUST validate that it has appropriate resources/mechanisms to collect the requested signals before acknowledging the component creation.</p>
<section2 topic='Events' anchor='session-events'>
<p>If the meta-attribute named 'terminate' is set to true in the grammar, the component MUST terminate on the first signal match it detects. If it is set to false, signals MUST be reported as events until the component is instructed to stop.</p>
<example caption="Component indicates that a signal was detected"><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28' to='juliet@capulet.lit/courtyard'>
<signal xmlns="urn:xmpp:rayo:cpa:1" type="urn:xmpp:rayo:cpa:dtmf:1" duration="4690" value="1"/>
</presence>
]]></example>
</section2>
<section2 topic='Completion' anchor='session-completion'>
<p>The input completion reason MUST be one of the supported reasons from the core specification or a <link url='#def-signal'>signal</link>, indicating that the CPA engine detected one of the requested signals. Any signals other than those requested by the input grammar should be ignored.</p>
<example caption="Component indicates it has completed due to one of the grammars matching a detected signal"><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28'
to='juliet@capulet.lit/courtyard'
type='unavailable'>
<complete xmlns='urn:xmpp:rayo:ext:1'>
<signal xmlns="urn:xmpp:rayo:cpa:1" type="urn:xmpp:rayo:cpa:speech:1" duration="4690" value="machine"/>
</complete>
</presence>
]]></example>
</section2>
</section1>
<section1 topic='Formal Definition' anchor='def'>
<section2 topic='Grammar Format' anchor='def-grammar'>
<p>The grammar URI declares the signal type of interest and the parameters which apply to their detection. The URI should be composed of a URN from <link url='#def-signal-types'>the following list of allowed signal types</link>, and parameters to modify their detection as a query string. The names and allowed values of these parameters are implementation specific. Servers MUST support one reserved parameter named 'terminate', whose value indicates the termination behaviour of the component on signal detection as described <link url='#session-events'>above</link>.</p>
</section2>
<section2 topic='Signal Element' anchor='def-signal'>
<p>Describes a detected signal.</p>
<p>The attributes of the &lt;grammar/&gt; element are as follows.</p>
<table caption='Attributes of Signal Element'>
<tr>
<th>Attribute</th>
<th>Definition</th>
<th>Possible Values</th>
<th>Default</th>
<th>Inclusion</th>
</tr>
<tr>
<td>type</td>
<td>Indicates the type of signal detected.</td>
<td>Any URI value from <link url='#def-signal-types'>the listed signal types</link></td>
<td>none</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>duration</td>
<td>Indicates the duration of the received signal in milliseconds</td>
<td>An integer value in milliseconds.</td>
<td>none</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>value</td>
<td>Indicates the value of the signal received if applicable.</td>
<td>For dtmf tones it is the digit detected, for speech may be human|machine|notsure and for beeps may be a frequency in Hz.</td>
<td>none</td>
<td>OPTIONAL</td>
</tr>
</table>
</section2>
<section2 topic='Signal Types' anchor='def-signal-types'>
<p>Signal types may be one of the following:</p>
<table caption='Signal type URIs'>
<tr>
<th>URI</th>
<th>Description</th>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:beep:1</td>
<td>Detect a beep.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:dtmf:1</td>
<td>Detect DTMF tones.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:speech:1</td>
<td>Detect speech and decide human or machine.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:fax-ced:1</td>
<td>Detect a fax CED tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:fax-cng:1</td>
<td>Detect a fax CNG tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:ring:1</td>
<td>Detect a ringing tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:busy:1</td>
<td>Detect a busy tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:congestion:1</td>
<td>Detect a congestion tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:sit:1</td>
<td>Detect a Special Information Tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:modem:1</td>
<td>Detect a modem tone.</td>
</tr>
<tr>
<td>urn:xmpp:rayo:cpa:offhook:1</td>
<td>Detect an off-hook tone.</td>
</tr>
</table>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>STRONGLY RECOMMENDED.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If a Rayo server supports Rayo CPA, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo|cpa:0" &VNOTE; in response to a &xep0030; information request.</p>
<example caption="Service Discovery Information Request - Client to Server"><![CDATA[
<iq from='kingclaudius@shakespeare.lit/castle'
id='disco1'
to='call.rayo.org'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery Information Response - Client to Server"><![CDATA[
<iq from='call.rayo.org'
id='disco1'
to='kingclaudius@shakespeare.lit/castle'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:rayo:0'/>
<feature var='urn:xmpp:rayo:cpa:0'/>
</query>
</iq>
]]></example>
<p>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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions.</p>
</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespaces:</p>
<ul>
<li>urn:xmpp:rayo:cpa:1</li>
<li>urn:xmpp:rayo:cpa:beep:1</li>
<li>urn:xmpp:rayo:cpa:dtmf:1</li>
<li>urn:xmpp:rayo:cpa:speech:1</li>
<li>urn:xmpp:rayo:cpa:fax-ced:1</li>
<li>urn:xmpp:rayo:cpa:fax-cng:1</li>
<li>urn:xmpp:rayo:cpa:ring:1</li>
<li>urn:xmpp:rayo:cpa:busy:1</li>
<li>urn:xmpp:rayo:cpa:congestion:1</li>
<li>urn:xmpp:rayo:cpa:sit:1</li>
<li>urn:xmpp:rayo:cpa:modem:1</li>
<li>urn:xmpp:rayo:cpa:offhook:1</li>
</ul>
<p>The &REGISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.</p>
</section2>
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
<p>If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of <cite>XEP-0053</cite>.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<section2 topic='Rayo CPA' anchor='schema-rayo-cpa'>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:xmpp:rayo:input:1"
xmlns:tns="urn:xmpp:rayo:cpa:1"
elementFormDefault="qualified"
xmlns:core="urn:xmpp:rayo:1">
<annotation>
<documentation>
The protocol documented by this schema is defined at http://rayo.org/xep
</documentation>
</annotation>
<!-- Signal element -->
<element name="signal">
<annotation>
<documentation>
Describes a detected signal.
</documentation>
</annotation>
<complexType>
<simpleContent>
<attribute name="type" use="required">
<annotation>
<documentation>
Indicates the type of signal detected.
</documentation>
</annotation>
<simpleType>
<restriction base="token">
<enumeration value="urn:xmpp:rayo:cpa:beep:1" />
<enumeration value="urn:xmpp:rayo:cpa:dtmf:1" />
<enumeration value="urn:xmpp:rayo:cpa:speech:1" />
<enumeration value="urn:xmpp:rayo:cpa:fax-ced:1" />
<enumeration value="urn:xmpp:rayo:cpa:fax-cng:1" />
<enumeration value="urn:xmpp:rayo:cpa:ring:1" />
<enumeration value="urn:xmpp:rayo:cpa:busy:1" />
<enumeration value="urn:xmpp:rayo:cpa:congestion:1" />
<enumeration value="urn:xmpp:rayo:cpa:sit:1" />
<enumeration value="urn:xmpp:rayo:cpa:modem:1" />
<enumeration value="urn:xmpp:rayo:cpa:offhook:1" />
</restriction>
</simpleType>
</attribute>
<attribute name="duration" type="core:durationType" use="optional" default="">
<annotation>
<documentation>
Indicates the duration of the received signal in milliseconds
</documentation>
</annotation>
</attribute>
<attribute name="value" type="token" use="optional" default="">
<annotation>
<documentation>
Indicates the value of the signal received if applicable. For dtmf tones it is the digit detected, for speech may be human|machine|notsure and for beeps may be a frequency in Hz.
</documentation>
</annotation>
</attribute>
</simpleContent>
</complexType>
</element>
</schema>
]]></code>
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>The authors would like to acknowledge the input of teams at Tropo Inc, Mojo Lingo and Grasshopper in the development of this specification.</p>
<p>Specific individuals who have contributed to the specification or to software significant to its completion include:</p>
<ul>
<li>Ben Langfeld</li>
<li>Chris Rienzo</li>
<li>Martín Pérez</li>
</ul>
</section1>
</xep>

441
inbox/rayo-fax.xml Normal file
View File

@ -0,0 +1,441 @@
<?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>Rayo Fax</title>
<abstract>This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for sending and receiving faxcimilies via a call under the control of a Rayo client.</abstract>
&LEGALNOTICE;
<number>NOT_YET_ASSIGNED</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0327 Rayo</spec>
<spec>XEP-xxxx Rayo CPA</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Ben</firstname>
<surname>Langfeld</surname>
<email>ben@langfeld.me</email>
<jid>ben@langfeld.me</jid>
<uri>http://langfeld.me</uri>
</author>
<revision>
<version>0.0.1</version>
<date>2013-10-02</date>
<initials>bl</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Rayo allows for the third-party control of media sessions such as telephone calls. A common requirement in telephony applications providing backward compatability with legacy systems is to support sending and receiving faxes. This specification extends the core Rayo specification, to describe a protocol for this use case.</p>
</section1>
<section1 topic='Session Flow' anchor='session'>
<p>This section describes the form, function and order of Rayo stanzas sent across the wire, and the circumstances in which they apply and/or may arise.</p>
<section2 topic='Receiving Faxes' anchor='session-receiving'>
<p>A Rayo client may utilise <link url=''>Rayo CPA</link> to establish a fax CNG tone before initiating fax receipt using the receivefax component described below.</p>
<p>The receivefax component accepts a fax from a caller, stores it, and makes it available to Rayo clients. The component is created using a <link url='def-receivefax'>&lt;receivefax/&gt; command</link>.</p>
<example caption='Client receives a fax'><![CDATA[
<iq from='juliet@capulet.lit/balcony'
to='9f00061@call.shakespeare.lit'
type='set'
id='h7ed2'>
<receivefax xmlns='urn:xmpp:rayo:fax:1'/>
</iq>
]]></example>
<p>The server MUST validate that it has apropriate resources/mechanisms to receive the fax before acknowledging the component creation.</p>
<section3 topic='Commands' anchor='session-receiving-commands'>
<p>The receivefax component does not implement any intermediary commands.</p>
</section3>
<section3 topic='Events' anchor='session-receiving-events'>
<p>The receivefax component does not provide any intermediate events.</p>
</section3>
<section3 topic='Completion' anchor='session-receiving-completion'>
<p>The receivefax completion reason MUST be one of the <link url='#def-components-complete-reason'>core Rayo reasons</link> or <link url='#def-finish'>finish</link> (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received.</p>
<p>The server MUST present the fax for consumption by the client by way of fax meta-data on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size &amp; page count data as specified on the <link url='#def-fax'>fax element</link>. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.</p>
<example caption="Component indicates it has completed due to being finished, providing the fax"><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28'
to='juliet@capulet.lit/courtyard'
type='unavailable'>
<complete xmlns='urn:xmpp:rayo:ext:1'>
<finish xmlns='urn:xmpp:rayo:fax:complete:1'/>
<fax xmlns='urn:xmpp:rayo:fax:complete:1' url='http://shakespere.lit/faxes/fax1.tiff' resolution='595x841' size='12287492817' pages='3'/>
<metadata xmlns='urn:xmpp:rayo:fax:complete:1' name="fax-transfer-rate" value="10000" />
</complete>
</presence>
]]></example>
</section3>
</section2>
<section2 topic='Sending Faxes' anchor='session-receiving'>
<p>Sending faxes can be achieved by using the Sendfax component. A conformant server MUST support image/tiff documents, and MAY also support others. A conformant server MUST support fetching documents via an HTTP URL and MAY support other URL schemes.</p>
<example caption='Client sends a fax document to a call'><![CDATA[
<iq from='juliet@capulet.lit/balcony'
to='9f00061@call.shakespeare.lit'
type='set'
id='h7ed2'>
<sendfax xmlns='urn:xmpp:rayo:fax:1'>
<document xmlns='urn:xmpp:rayo:fax:1' url='http://shakespere.lit/my_fax.tiff'/>
</sendfax>
</iq>
]]></example>
<p>Additionally, a sendfax component MAY include in its completion reason one or more <link url='#def-metadata'>&lt;metadata/&gt; elements</link> describing the result of transmitting the document, like so:</p>
<example caption='Client finishes sending a fax document to a call'><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28'
to='juliet@capulet.lit/courtyard'
type='unavailable'>
<complete xmlns='urn:xmpp:rayo:ext:1'>
<finish xmlns='urn:xmpp:rayo:fax:complete:1'/>
<metadata xmlns='urn:xmpp:rayo:fax:complete:1' name="fax-transfer-rate" value="10000" />
</complete>
</presence>
]]></example>
</section2>
</section1>
<section1 topic='Formal Definition' anchor='def'>
<section2 topic='Receivefax Element' anchor='def-receivefax'>
<p>Instructs the server to begin receiving a fax.</p>
<p>The &lt;receivefax/&gt; element MUST be empty.</p>
<p>The &lt;receivefax/&gt; element has no attributes.</p>
</section2>
<section2 topic='Sendfax Element' anchor='def-sendfax'>
<p>Instructs the server to begin transmitting a fax.</p>
<p>The &lt;sendfax/&gt; element MUST be empty.</p>
<p>The &lt;sendfax/&gt; element has no attributes.</p>
</section2>
<section2 topic='Fax Element' anchor='def-fax'>
<p>Provides the result of a received fax, as a reference to its location.</p>
<p>The &lt;fax/&gt; element MUST be empty.</p>
<p>The attributes of the &lt;fax/&gt; element are as follows.</p>
<table caption='Attributes of Fax Element'>
<tr>
<th>Attribute</th>
<th>Definition</th>
<th>Possible Values</th>
<th>Inclusion</th>
</tr>
<tr>
<td>url</td>
<td>Indicates the URL at which the fax is made available.</td>
<td>A valid URI.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>resolution</td>
<td>Indicates the resolution of the received fax.</td>
<td>A string in MxN format, where M and N are integers in pixels.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>pages</td>
<td>Indicates the number of pages in the received fax.</td>
<td>An integer.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>size</td>
<td>Indicates the filesize of the received fax.</td>
<td>A positive integer in bytes.</td>
<td>REQUIRED</td>
</tr>
</table>
</section2>
<section2 topic='Document Element' anchor='def-document'>
<p>Provides data for a document to be sent as a fax.</p>
<p>The &lt;document/&gt; element MUST be empty.</p>
<p>The attributes of the &lt;document/&gt; element are as follows.</p>
<table caption='Attributes of Document Element'>
<tr>
<th>Attribute</th>
<th>Definition</th>
<th>Possible Values</th>
<th>Inclusion</th>
</tr>
<tr>
<td>url</td>
<td>Indicates the URL at which the document to send is available.</td>
<td>A valid URI.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>identity</td>
<td>Indicates the identity from which the fax should appear to be sent.</td>
<td>A phone number string in E.164 format.</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>header</td>
<td>The header line to add to each page of the transmitted fax.</td>
<td>A string.</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>pages</td>
<td>The (set of) range of pages of the document to transmit.</td>
<td>A string (or set of strings separated by ',') in the format M[-N], where M and N are integers and the dash and second integer are optional. The set is combinatory and dash-separated integers signify a range of pages. The index is one-based.</td>
<td>OPTIONAL</td>
</tr>
</table>
</section2>
<section2 topic='Metadata Element' anchor='def-metadata'>
<p>Provides implementation-specific key-value pairs of metadata regarding the transmission or receipt of a fax document.</p>
<p>The &lt;metadata/&gt; element MUST be empty.</p>
<p>The attributes of the &lt;metadata/&gt; element are as follows.</p>
<table caption='Attributes of Metadata Element'>
<tr>
<th>Attribute</th>
<th>Definition</th>
<th>Inclusion</th>
</tr>
<tr>
<td>name</td>
<td>A token giving the name by which the metadata may be known.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>value</td>
<td>The string value of the named metadata.</td>
<td>REQUIRED</td>
</tr>
</table>
</section2>
<section2 topic='Finish Element' anchor='def-finish'>
<p>Indicates that the component came to an end due to the document being received successfully.</p>
<p>The &lt;finish/&gt; element MUST be empty.</p>
<p>The &lt;finish/&gt; element has no attributes.</p>
</section2>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If a Rayo server supports Rayo Fax, it MUST advertise that fact by returning a feature of "urn:xmpp:rayo:fax:1" &VNOTE; in response to a &xep0030; information request.</p>
<example caption="Service Discovery Information Request - Client to Server"><![CDATA[
<iq from='kingclaudius@shakespeare.lit/castle'
id='disco1'
to='call.rayo.org'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service Discovery Information Response - Client to Server"><![CDATA[
<iq from='call.rayo.org'
id='disco1'
to='kingclaudius@shakespeare.lit/castle'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:rayo:1'/>
<feature var='urn:xmpp:rayo:fax:1'/>
</query>
</iq>
]]></example>
<p>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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>A server MUST document any cases where its behaviour differs from that in this specification (such as lack of support for particular options/components/etc) and return an error whenever a command is not understood. A server MUST NOT silently ignore any instructions.</p>
</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespaces:</p>
<ul>
<li>urn:xmpp:rayo:fax:1</li>
<li>urn:xmpp:rayo:fax:complete:1</li>
</ul>
<p>The &REGISTRAR; includes the foregoing namespaces in its registry at &NAMESPACES;, as governed by &xep0053;.</p>
</section2>
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
<p>If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of <cite>XEP-0053</cite>.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<section2 topic='Rayo Fax' anchor='schema-rayo-fax'>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:xmpp:rayo:fax:1"
xmlns:tns="urn:xmpp:rayo:fax:1"
elementFormDefault="qualified"
xmlns:core="urn:xmpp:rayo:1">
<annotation>
<documentation>
The protocol documented by this schema is defined at http://rayo.org/xep
</documentation>
</annotation>
<!-- Fax receipt command -->
<element name="receivefax" type="core:empty">
<annotation>
<documentation>
Instructs the server to begin receiving a fax.
</documentation>
</annotation>
</element>
<!-- Fax transmission command -->
<element name="sendfax" type="core:empty">
<annotation>
<documentation>
Instructs the server to begin transmitting a fax.
</documentation>
</annotation>
</element>
<!-- Fax document data -->
<element name="document" type="core:empty">
<annotation>
<documentation>
Provides the result of a received fax, including a reference to its location.
</documentation>
</annotation>
<attribute name="url" type="anyURI" use="required">
<annotation>
<documentation>
Indicates the URL at which the document to send is available.
</documentation>
</annotation>
</attribute>
<attribute name="identity" type="string" use="optional">
<annotation>
<documentation>
Indicates the identity from which the fax should appear to be sent.
</documentation>
</annotation>
</attribute>
<attribute name="header" type="string" use="optional">
<annotation>
<documentation>
The header line to add to each page of the transmitted fax.
</documentation>
</annotation>
</attribute>
<attribute name="pages" type="string" use="optional">
<annotation>
<documentation>
A string (or set of strings separated by ',') in the format M[-N], where M and N are integers and the dash and second integer are optional. The set is combinatory and dash-separated integers signify a range of pages. The index is one-based.
</documentation>
</annotation>
</attribute>
</element>
</schema>
]]></code>
</section2>
<section2 topic='Rayo Fax Complete' anchor='schema-fax-complete'>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:xmpp:rayo:fax:complete:1"
xmlns:tns="urn:xmpp:rayo:fax:complete:1"
elementFormDefault="qualified"
xmlns:core="urn:xmpp:rayo:1">
<annotation>
<documentation>
The protocol documented by this schema is defined at http://rayo.org/xep
</documentation>
</annotation>
<!-- Received Fax data -->
<element name="fax" type="core:empty">
<annotation>
<documentation>
Provides the result of a received fax, including a reference to its location.
</documentation>
</annotation>
<attribute name="url" type="anyURI" use="required">
<annotation>
<documentation>
Indicates the URL at which the fax is made available.
</documentation>
</annotation>
</attribute>
<attribute name="resolution" type="string" use="required">
<annotation>
<documentation>
Indicates the resolution of the received fax in MxN format, where M and N are integers in pixels.
</documentation>
</annotation>
</attribute>
<attribute name="pages" type="nonNegativeInteger" use="required">
<annotation>
<documentation>
Indicates the number of pages in the received fax.
</documentation>
</annotation>
</attribute>
<attribute name="size" type="long" use="required">
<annotation>
<documentation>
Indicates the filesize (in bytes) of the received fax.
</documentation>
</annotation>
</attribute>
</element>
<complexType name="metadataType">
<attribute name="name" type="token" use="required">
<annotation>
<documentation>
A token giving the name by which the metadata may be known.
</documentation>
</annotation>
</attribute>
<attribute name="value" type="string" use="required">
<annotation>
<documentation>
The string value of the named metadata.
</documentation>
</annotation>
</attribute>
</complexType>
<!-- Finish reason -->
<element name="finish" type="core:empty">
<annotation>
<documentation>
Indicates that the component came to an end due to the document being received successfully.
</documentation>
</annotation>
</element>
</schema>
]]></code>
</section2>
</section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>The authors would like to acknowledge the input of teams at Mojo Lingo and Grasshopper in the development of this specification.</p>
<p>Specific individuals who have contributed to the specification or to software significant to its completion include:</p>
<ul>
<li>Ben Langfeld</li>
<li>Chris Rienzo</li>
</ul>
</section1>
</xep>

12
inbox/sox.xml
View File

@ -28,6 +28,12 @@
<email>fluffy@cisco.com</email>
<jid>fluffy@cisco.com</jid>
</author>
<revision>
<version>0.0.2</version>
<date>2013-12-02</date>
<initials>psa</initials>
<remark><p>Clarified scope and intent of the protocol.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2013-06-12</date>
@ -38,8 +44,8 @@
<section1 topic='Introduction' anchor='intro'>
<p>The Session Description Protocol (SDP) &rfc4566; is widely used to communicate information about media sessions, typically using the offer/answer model &rfc3264;. For example, when the Session Initiation Protocol (SIP) &rfc3261; is used for establishing media sessions, the payloads of the SIP messages contain SDP payloads. The use of SDP continues to gain force, since SDP has been adopted for use in the WebRTC technologies being defined at the &IETF; and &W3C; for real-time communication among web browsers.</p>
<p>Some user agents that might want to participate in WebRTC interactions use XMPP as their primary or only communication channel. For example, a browser-based XMPP application might use a JavaScript library that connects to an XMPP server using &xmppoverwebsocket; or using &xep0124; and &xep0206;. Although such an application could use &xep0166; and &xep0167; between the client and the server, converting the Jingle XML format into SDP (and associated SIP headers) might require use of a server-side gateway, and such a gateway might introduce unnecessary complexity into the system (e.g., keeping session state in the gateway). Enabling the user agent to natively send SDP (and a minimal set of SIP headers) can make it easier for XMPP client developers to build real-time communication applications using existing SDP and SIP libraries, especially in the context of WebRTC.</p>
<p>By specifying a way to send SDP/SIP over XMPP (a.k.a. "SoX"), this document effectively defines another reliable transport method for SIP/SDP messages. However, it is envisioned that this method will be used only by XMPP-only endpoints, not by native SIP or dual-stack SIP/XMPP &cusax; endpoints. It is important to note that SoX is not intended to deprecate Jingle, only to provide a convenient way to reliably transport SIP/SDP traffic for communication with native SIP and dual-stack SIP/XMPP endpoints. Finally, because SoX payloads contain only minimal SIP headers (needed for message delivery in certain scenarios) and SDP content, the method is not designed for sending arbitrary SIP message bodies, only SDP.</p>
<p>Some user agents that might want to participate in WebRTC interactions use XMPP as their primary or only communication channel. For example, a browser-based XMPP application might use a JavaScript library that connects to an XMPP server using &xmppoverwebsocket; or using &xep0124; and &xep0206;. Although such an application could use &xep0166; and &xep0167; between the client and the server, converting the Jingle XML format into SDP (and associated SIP headers) might require use of a server-side gateway, and such a gateway might introduce unnecessary complexity into the system (e.g., keeping session state in the gateway). Enabling the user agent to natively send SDP (and a minimal set of SIP headers) can make it easier for XMPP client developers to build real-time communication applications using existing SDP and SIP libraries, especially in the context of WebRTC. Even outside of WebRTC, the ability to send SDP/SIP over XMPP can be useful in deployments where XMPP-capable endpoints need to communicate with SIP endpoints such as IP phones.</p>
<p>By specifying a way to send SDP/SIP over XMPP (a.k.a. "SoX"), this document effectively defines a reliable transport method for SIP/SDP messages. However, it is envisioned that this method will be used only by XMPP-only endpoints, not by native SIP or dual-stack SIP/XMPP &rfc7081; endpoints. It is also important to note that SoX is not intended to replace Jingle as a general-purpose method for negotiating media sessions among XMPP entities; instead, it provides a convenient way to reliably transport SIP/SDP traffic for communication from XMPP-only endpoints to native SIP and dual-stack SIP/XMPP endpoints. Finally, because SoX payloads contain only minimal SIP headers (needed for message delivery in certain scenarios) and SDP content, the method is not designed for sending arbitrary SIP message bodies, only SDP.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
@ -128,7 +134,7 @@ a=sendrecv
</section1>
<section1 topic='Address Mapping' anchor='addressing'>
<p>Address mapping between SIP and XMPP can be a challenge. See &xmppsipcore; for details.</p>
<p>Address mapping between SIP and XMPP can be a challenge. See &stoxcore; for details.</p>
<p>The 'to' attribute and 'from' attribute of the XMPP &MESSAGE; stanza need not match the "To" header and "From" header of the SoX payload. For example, the sender might know (based on vCard data or a directory lookup) that the SIP address of the intended recipient is different from the XMPP address of the intended recipient. This is possible in so-called CUSAX scenarios; although the CUSAX specification recommends that all SDP signalling be sent over SIP rather than XMPP, the sender might be an XMPP-only endpoint and the intended recipient might be a CUSAX endpoint.</p>
<p>However, in general it is easier for a user agent to simply set the SIP "To" and "From" headers to the same identifiers (JIDs) used for the XMPP 'to' and 'from' attributes.</p>
</section1>

2
index.shtml
View File

@ -5,7 +5,7 @@
<!--#include virtual="/includes/head.txt" -->
<h2>XMPP Extensions</h2>
<p><a class="standardsButton" href="atom.xml">ATOM</a>&nbsp;&nbsp;<a class="standardsButton" href="rss.xml">RSS</a></p>
<p><a class="standardsButton" href="atom.xml">ATOM</a>&#160;&#160;<a class="standardsButton" href="rss.xml">RSS</a></p>
<p>XMPP is the Extensible Messaging and Presence Protocol, a set of open <a href='/tech/'>technologies</a> for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.</p>
<p>The <a href='/xsf/'>XMPP Standards Foundation</a> (XSF) develops extensions to <a href="/">XMPP</a> through a standards process centered around XMPP Extension Protocols (XEPs). The <a href="xep-0001.html">process</a> is managed by the <a href="editor.shtml">XMPP Extensions Editor</a> and involves intensive discussion on the <a href="http://mail.jabber.org/mailman/listinfo/standards/">Standards mailing list</a>, formal review and <a href="/council/votes.shtml">voting</a> by the <a href="/council/">XMPP Council</a>, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal <a href="ipr-policy.shtml">IPR Policy</a> for wide implementation. Submissions are <a href='submit.shtml'>welcome</a> (see also the <a href="/extensions/inbox/">&quot;inbox&quot;</a>). All XEPs and related files are under <a href="/xsf/sourcecontrol.shtml">source control</a>, <a href="/extensions/attic/">old versions</a> are available, and IETF-style <a href="/extensions/refs/">XML reference files</a> are provided. A compressed archive of all current XEPs can be downloaded <a href="/extensions/xepbundle.tar.bz2">here</a>. You can view and submit XEP-related bugs and feature requests at the <a href='http://tracker.xmpp.org/browse/SPEC'>issue tracker</a>.</p>

4
xep-0080.xml
View File

@ -178,7 +178,7 @@
<td>bearing</td>
<td>xs:decimal</td>
<td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north <note>It is the responsibility of the receiver to translate bearing into decimal degrees relative to magnetic north, if desired.</note></td>
<td>&nbsp;</td>
<td>&#160;</td>
</tr>
<tr>
<td>building</td>
@ -202,7 +202,7 @@
<td>datum</td>
<td>xs:string</td>
<td>GPS datum <note>If datum is not included, receiver MUST assume WGS84; receivers MUST implement WGS84; senders MAY use another datum, but it is not recommended.</note></td>
<td>&nbsp;</td>
<td>&#160;</td>
</tr>
<tr>
<td>description</td>

8
xep-0115.xml
View File

@ -368,14 +368,14 @@
<p>Two identities: "client/pc/Psi" and "client/pc/&#936;"</p>
</li>
<li>
<p>S = 'client/pc/el/&#936;&nbsp;0.11&lt;client/pc/en/Psi&nbsp;0.11&lt;'</p>
<p>S = 'client/pc/el/&#936;&#160;0.11&lt;client/pc/en/Psi&#160;0.11&lt;'</p>
</li>
<li>
<p>Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".</p>
</li>
<li>
<p>
S = 'client/pc/el/&#936;&nbsp;0.11&lt;client/pc/en/Psi&nbsp;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
S = 'client/pc/el/&#936;&#160;0.11&lt;client/pc/en/Psi&#160;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
<br />http://jabber.org/protocol/disco#items&lt;http://jabber.org/protocol/muc&lt;'.
</p>
</li>
@ -383,14 +383,14 @@
<p>Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").</p>
</li>
<li>
<p>S = 'client/pc/el/&#936;&nbsp;0.11&lt;client/pc/en/Psi&nbsp;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
<p>S = 'client/pc/el/&#936;&#160;0.11&lt;client/pc/en/Psi&#160;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
<br />http://jabber.org/protocol/disco#items&lt;http://jabber.org/protocol/muc&lt;urn:xmpp:dataforms:softwareinfo&lt;'</p>
</li>
<li>
<p>Sort the fields by var and append the value(s): "ip_version&lt;ipv4&lt;ipv6", "os&lt;Mac", "os_version&lt;10.5.1", "software&lt;Psi", "software_version&lt;0.11".</p>
</li>
<li>
<p>S = 'client/pc/el/&#936;&nbsp;0.11&lt;client/pc/en/Psi&nbsp;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
<p>S = 'client/pc/el/&#936;&#160;0.11&lt;client/pc/en/Psi&#160;0.11&lt;http://jabber.org/protocol/caps&lt;http://jabber.org/protocol/disco#info&lt;
<br />http://jabber.org/protocol/disco#items&lt;http://jabber.org/protocol/muc&lt;urn:xmpp:dataforms:softwareinfo&lt;
<br />ip_version&lt;ipv4&lt;ipv6&lt;os&lt;Mac&lt;os_version&lt;10.5.1&lt;software&lt;Psi&lt;software_version&lt;0.11&lt;'</p>
</li>

143
xep-0124.xml
View File

@ -11,6 +11,7 @@
&LEGALNOTICE;
<number>0124</number>
<status>Draft</status>
<interim/>
<type>Standards Track</type>
<jig>Standards</jig>
<dependencies>
@ -28,6 +29,13 @@
&dizzyd;
&stpeter;
&metajack;
&lance;
<revision>
<version>1.11rc2</version>
<date>2013-12-10</date>
<initials>ls</initials>
<remark><p>Incorporated patches from community review.</p></remark>
</revision>
<revision>
<version>1.10</version>
<date>2010-07-02</date>
@ -157,9 +165,9 @@
</header>
<section1 topic="Introduction" anchor='intro'>
<p>The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;.</p>
<p>BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as &websocket; and &rhttp;.</p>
<p>BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as WebSocket &rfc6455; and &rhttp;.</p>
<p>BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) <note>Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note> or even access to HTTP headers.</p>
<p>BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support <link url="#multi">Multiple Streams</link> and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.</p>
<p>BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.</p>
<p>Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -204,20 +212,92 @@
<p>Furthermore, no aspect of this protocol limits its use to communication between a client and a server. For example, it could be used for communication between a server and a peer server if such communication can occur for the relevant application (e.g., in XMPP). However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use the native connection transport for the relevant application. (However, on some unreliable networks, BOSH might enable more stable communication between servers.)</p>
</section1>
<section1 topic="The BOSH Technique" anchor='technique'>
<p>Since HTTP is a synchronous request/response protocol, the traditional solution to emulating a bidirectional-stream over HTTP involved the client intermittently polling the connection manager to discover if it has any data queued for delivery to the client. This naive approach wastes a lot of network bandwidth by polling when no data is available. It also reduces the responsiveness of the application since the data spends time queued waiting until the connection manager receives the next poll (HTTP request) from the client. This results in an inevitable trade-off between responsiveness and bandwidth, since increasing the polling frequency will decrease latency but simultaneously increase bandwidth consumption (or vice versa if polling frequency is decreased).</p>
<p>The technique employed by BOSH achieves both low latency and low bandwidth consumption by encouraging the connection manager not to respond to a request until it actually has data to send to the client. As soon as the client receives a response from the connection manager it sends another request, thereby ensuring that the connection manager is (almost) always holding a request that it can use to "push" data to the client.</p>
<p>If the client needs to send some data to the connection manager then it simply sends a second request containing the data. Unfortunately most constrained clients do not support HTTP Pipelining (concurrent requests over a single connection), so the client typically needs to send the data over a second HTTP connection. The connection manager always responds to the request it has been holding on the first connection as soon as it receives a new request from the client -- even if it has no data to send the client. It does so to make sure the client can send more data immediately if necessary. (The client SHOULD NOT open more than two HTTP connections to the connection manager at the same time, <note>In order to reduce network congestion, <cite>RFC 2616</cite> recommends that clients SHOULD NOT keep more than two HTTP connections to the same HTTP server open at the same time. Clients running in constrained enviroments typically have no choice but to abide by that recommendation.</note> so it would otherwise have to wait until the connection manager responds to one of the requests.)</p>
<p>BOSH works reliably even if network conditions force every HTTP request to be made over a different TCP connection. However, if as is usually the case, the client is able to use HTTP/1.1, then (assuming reliable network conditions) all requests during a session will pass over the same two persistent TCP connections. Almost all of the time (see below) the client is able to push data on one of the connections, while the connection manager is able to push data on the other (so latency is as low as a standard TCP connection). It's interesting to note that the roles of the two connections typically switch whenever the client sends data to the connection manager.</p>
<p>If there is no traffic in either direction for an agreed amount of time (typically several minutes), then the connection manager responds to the client with no data, and that response immediately triggers a fresh client request. The connection manager does so to ensure that if a network connection is broken then both parties will realise within a reasonable amount of time. This exchange is similar to the "keep-alive" or "ping" that is common practice over most persistent TCP connections. Since the BOSH technique involves no polling, bandwidth consumption is not significantly greater than a standard TCP connection. <note>If there is no traffic other than the "pings" then bandwidth consumption will be double that of a TCP connection (although double nothing is still nothing). If data is sent in large packets then bandwidth consumption will be almost identical.</note></p>
<p>Most of the time data can be pushed immediately. However, if one of the endpoints has just pushed some data then it will usually have to wait for a network round trip until it is able to push again. If HTTP Pipelining is available to the client then multiple concurrent requests are possible. Thus the client can always push data immediately. It can also ensure the connection manager is always holding enough requests such that even during bursts of activity it will never have to wait before pushing data. Furthermore, if the pool of requests being held by the connection manager is large enough, then the client will not be under pressure to send a new empty request immediately after receiving data from the connection manager. It can instead wait until it needs to send data. Therefore, if over time the traffic to and from the client is balanced, bandwidth consumption will be about the same as if a standard TCP connection were being used.</p>
<p>Each block of data pushed by the connection manager is a complete HTTP response. So, unlike the Comet technique, the BOSH technique works through intermediate proxies that buffer partial HTTP responses. It is also fully compliant with HTTP/1.0 -- which does not provide for chunked transfer encoding.</p>
<p>The technique employed by BOSH, which is sometimes called "HTTP long polling", reduces latency and bandwidth consumption over other HTTP polling techniques. When the client sends a request, the connection manager does not immediately send a response; instead it holds the request open until it has data to actually send to the client (or an agreed-to length of inactivity has elapsed). The client then immediately sends a new request to the connection manager, continuing the long polling loop.</p>
<p>If the connection manager does not have any data to send to the client after some agreed-to length of time<note>This time is typically on the order of tens of seconds (e.g., 60), and is determined during session creation</note>, it sends a response with an empty &lt;body/&gt;. This serves a similar purpose to whitespace keep-alives or &xep0199;; it helps keep a socket connection active which prevents some intermediaries (firewalls, proxies, etc) from silently dropping it, and helps to detect breaks in a reasonable amount of time.</p>
<p>Where clients and connection managers support persistent connections (i.e. "Connection: keep-alive" from HTTP/1.0, and which is the default state for HTTP/1.1), these sockets remain open for an extended length of time, awaiting the client's next request. This reduces the overhead of socket establishment, which can be very expensive if HTTP over Secure Sockets Layer (SSL) is used.</p>
<p>If the client has data to send while a request is still open, it establishes a second socket connection to the connection manager to send a new request. The connection manager immediately responds to the previously held request (possibly with no data) and holds open this new request. This results in the connections switching roles; the "old" connection is responded to and left awaiting new requests, while the "new" connection is now used for the long polling loop.</p>
<p>The following diagram illustrates this technique (possibly after XMPP session establishment)</p>
<code><![CDATA[
|
+-+ <-- empty body request
|X|
|-|
| |
| |
| |
| |
|-| <-- empty body response
|*|
+-+
|
+-+ <-- empty body request
|X|
|-|
| |
| |
| |
| |
|-| <-- empty body response
|*|
+-+
|
+-+ <-- empty body request
|X| socket opened --> ===
|-| |
| | new message out --> +-+
|-| <-- empty body response |X|
|*| |-|
+-+ | |
| | |
| | |
| | |
| empty body response --> |-|
| |*|
| +-+
| |
| empty body request --> +-+
| |X|
| |-|
| | |
+-+ <-- new message out | |
|X| empty body response --> |-|
|-| <-- new message in |*|
|*| +-+
+-+ |
| |
+-+ <-- empty body request |
|X| |
|-| |
| | |
| | new message out --> +-+
|-| <-- new message in |X|
|*| |-|
+-+ | |
| | |
| | |
| | |
| empty body response --> |-|
| |*|
| +-+
| |
| empty body request --> +-+
| |X|
| |-|
| | |
| | |
| | |
| | |
| empty body response --> |-|
| |*|
| +-+
| |
]]></code>
</section1>
<section1 topic="HTTP Overview" anchor='overview'>
<p>The requirements of <cite>RFC 2616</cite> MUST be met for both requests and responses. Additional HTTP headers not specified herein MAY be included, but receivers SHOULD ignore any such headers. Clients and connection managers MAY omit headers that are not mandated by <cite>RFC 2616</cite> and would otherwise be ignored (e.g. if the client has constrained bandwidth), but clients are advised that network and proxy policies could block such requests.</p>
<p>All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single &lt;body/&gt; wrapper which encapsulates the XML elements being transferred (see <link url="#wrapper">&lt;body/&gt; Wrapper Element</link>).</p>
<p>Clients SHOULD send all HTTP requests over a single persistent HTTP/1.1 connection using HTTP Pipelining. However, a client MAY deliver its POST requests in any way permitted by <cite>RFC 1945</cite> or <cite>RFC 2616</cite>. For example, constrained clients can be expected to open more than one persistent connection instead of using Pipelining, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.</p>
<p>Clients MUST send all HTTP requests as POST requests in any way permitted by <cite>RFC 1945</cite> or <cite>RFC 2616</cite>. For example, clients can be expected to open more than one persistent connection, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries might buffer each partial HTTP request or response and only forward the full request or response once it is available.</p>
<p>Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.</p>
<p>Requests and responses MAY include HTTP headers not specified herein. The receiver SHOULD ignore any such headers.</p>
<p>Each BOSH session MAY share the HTTP connection(s) it uses with other HTTP traffic, including other BOSH sessions and HTTP requests and responses completely unrelated to this protocol (e.g., web page downloads). However, the responses to requests that are not part of the session sent over the same connection using HTTP pipelining (or queued to be sent over the same connection) might be delayed if they were sent while a request that is part of the session is being held (since the connection manager MUST send its responses in the same order that the requests were received, and the connection manager typically delays its responses).</p>
<p>The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive.</p>
</section1>
<section1 topic="&lt;body/&gt; Wrapper Element" anchor='wrapper'>
@ -241,7 +321,7 @@
<li><strong>'xml:lang'</strong> -- This attribute (as defined in Section 2.12 of &w3xml;) specifies the default language of any human-readable XML character data sent or received during the session.</li>
<li><strong>'ver'</strong> -- This attribute specifies the highest version of the BOSH protocol that the client supports. The numbering scheme is "&lt;major&gt;.&lt;minor&gt;" (where the minor number MAY be incremented higher than a single digit, so it MUST be treated as a separate integer). Note: The 'ver' attribute should not be confused with the version of any protocol being transported.</li>
<li><strong>'wait'</strong> -- This attribute specifies the longest time (in seconds) that the connection manager is allowed to wait before responding to any request during the session. This enables the client to limit the delay before it discovers any network failure, and to prevent its HTTP/TCP connection from expiring due to inactivity.</li>
<li><strong>'hold'</strong> -- This attribute specifies the maximum number of requests the connection manager is allowed to keep waiting at any one time during the session. If the client is not able to use HTTP Pipelining then this SHOULD be set to "1".</li>
<li><strong>'hold'</strong> -- This attribute specifies the maximum number of requests the connection manager is allowed to keep waiting at any one time during the session. If the client is able to reuse connections, this value SHOULD be set to "1".</li>
</ul>
<p>Note: Clients that only support <link url="#poll">Polling Sessions</link> MAY prevent the connection manager from waiting by setting 'wait' or 'hold' to "0". However, polling is NOT RECOMMENDED since the associated increase in bandwidth consumption and the decrease in responsiveness are both typically one or two orders of magnitude!</p>
<p>A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a "proxy" connection manager, a client SHOULD include a <strong>'route'</strong> attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:example.com:9999"). <note>Although the syntax of the 'route' attribute bears a superficial resemblance to a URI or IRI, it is not a URI/IRI and MUST NOT be processed in accordance with the rules specified in <cite>RFC 3986</cite>, <cite>RFC 3987</cite>, or (for XMPP) <cite>RFC 5122</cite>.</note> A connection manager that is configured to work only with a single server (or only with a defined list of domains and the associated list of hostnames and ports that are serving those domains) MAY ignore the 'route' attribute. (Note that the 'to' attribute specifies the domain being served, not the hostname of the machine that is serving the domain.)</p>
@ -273,21 +353,22 @@ Content-Length: 104
<ul>
<li><strong>'sid'</strong> -- This attribute specifies the SID</li>
<li><strong>'wait'</strong> -- This is the longest time (in seconds) that the connection manager will wait before responding to any request during the session. The time MUST be less than or equal to the value specified in the session request.</li>
<li><strong>'hold'</strong> -- This attribute informs the client about the maximum number of requests the connection manager will keep waiting at any one time during the session. This value MUST NOT be greater than the value specified by the client in the session request.</li>
</ul>
<p>The &lt;body/&gt; element SHOULD also include the following attributes (they SHOULD NOT be included in any other responses):</p>
<ul>
<li><strong>'ver'</strong> -- This attribute specifies the highest version of the BOSH protocol that the connection manager supports, or the version specified by the client in its request, whichever is lower.</li>
<li><strong>'polling'</strong> -- This attribute specifies the shortest allowable polling interval (in seconds). This enables the client to not send empty request elements more often than desired (see <link url="#poll">Polling Sessions</link> and <link url="#overactive">Overactivity</link>).</li>
<li><strong>'inactivity'</strong> -- This attribute specifies the longest allowable inactivity period (in seconds). This enables the client to ensure that the periods with no requests pending are never too long (see <link url="#poll">Polling Sessions</link> and <link url="#inactive">Inactivity</link>).</li>
<li><strong>'requests'</strong> -- This attribute enables the connection manager to limit the number of simultaneous requests the client makes (see <link url="#overactive">Overactivity</link> and <link url="#poll">Polling Sessions</link>). The RECOMMENDED values are either "2" or one more than the value of the 'hold' attribute specified in the session request.</li>
<li><strong>'hold'</strong> -- This attribute informs the client about the maximum number of requests the connection manager will keep waiting at any one time during the session. This value MUST NOT be greater than the value specified by the client in the session request.</li>
<li><strong>'requests'</strong> -- This attribute enables the connection manager to limit the number of simultaneous requests the client makes (see <link url="#overactive">Overactivity</link> and <link url="#poll">Polling Sessions</link>). This value must be larger than the 'hold' attribute value specified in the session request. The RECOMMENDED value is one more than the value of the 'hold' attribute specified in the session request.</li>
<li><strong>'to'</strong> -- This attribute communicates the identity of the backend server to which the client is attempting to connect.</li>
</ul>
<p>The connection manager MAY include an <strong>'accept'</strong> attribute in the session creation response element, to specify a space-separated list of the content encodings it can decompress. After receiving a session creation response with an 'accept' attribute, clients MAY include an HTTP Content-Encoding header in subsequent requests (indicating one of the encodings specified in the 'accept' attribute) and compress the bodies of the requests accordingly.</p>
<p>The connection manager MAY include an <strong>'accept'</strong> attribute in the session creation response element, to specify a comma-separated list of the content encodings it can decompress. After receiving a session creation response with an 'accept' attribute, clients MAY include an HTTP Content-Encoding header in subsequent requests (indicating one of the encodings specified in the 'accept' attribute) and compress the bodies of the requests accordingly.</p>
<p>A connection manager MAY include an <strong>'ack'</strong> attribute (set to the value of the 'rid' attribute of the session creation request) to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any response is meaningful (see <link url="#ack">Acknowledgements</link>).</p>
<p>If the connection manager supports session pausing (see <link url="#inactive">Inactivity</link>) then it SHOULD advertise that to the client by including a <strong>'maxpause'</strong> attribute in the session creation response element. The value of the attribute indicates the maximum length of a temporary session pause (in seconds) that a client can request.</p>
<p>For both requests and responses, the &lt;body/&gt; element and its content SHOULD be UTF-8 encoded. If the HTTP Content-Type header of a request/response specifies a character encoding other than UTF-8, then the connection manager MAY convert between UTF-8 and the other character encoding. However, even in this case, it is OPTIONAL for the connection manager to convert between encodings. The connection manager MAY inform the client which encodings it can convert by setting the optional <strong>'charsets'</strong> attribute in the session creation response element to a space-separated list of encodings. <note>Each character set name (or character encoding name -- we use the terms interchangeably) SHOULD be of type NMTOKEN, where the names are separated by the white space character #x20, resulting in a tokenized attribute type of NMTOKENS (see Section 3.3.1 of &w3xml;). Strictly speaking, the Character Sets registry maintained by the Internet Assigned Numbers Authority (see &lt;<link url='http://www.iana.org/assignments/character-sets'>http://www.iana.org/assignments/character-sets</link>&gt;) allows a character set name to contain any printable US-ASCII character, which might include characters not allowed by the NMTOKEN construction of XML 1.0; however, the only existing character set name which includes such a character is "NF_Z_62-010_(1973)".</note></p>
<p>As soon as the connection manager has established a connection to the server and discovered its identity, it MAY forward the identity to the client by including a <strong>'from'</strong> attribute in a response, either in its session creation response, or (if it has not received the identity from the server by that time) in any subsequent response to the client. If it established a secure connection to the server (as defined in <link url='#session'>Initiating a BOSH Session</link>), then in the same response the connection manager SHOULD also include the <strong>'secure'</strong> attribute set to "true" or "1".</p>
<p>As soon as the connection manager has established a connection to the server and discovered its identity, it MAY forward the identity to the client by including a <strong>'from'</strong> attribute in a response, either in its session creation response, or (if it has not received the identity from the server by that time) in any subsequent response to the client.</p>
<example caption="Session creation response">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -308,7 +389,7 @@ Content-Length: 128
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<example caption="Subsequent response with 'from' and 'secure' attributes">
<example caption="Subsequent response with 'from' attribute">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 128
@ -487,7 +568,7 @@ Content-Length: 68
<p>Note: If the connection manager did not specify a 'polling' attribute in the session creation response, then it MUST allow the client to send requests as frequently as it chooses.</p>
</section1>
<section1 topic='Polling Sessions' anchor='poll'>
<p>It is not always possible for a constrained client to either use HTTP Pipelining or open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for payloads it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its <link url="#session-response">Session Creation Response</link> to "1", however this is NOT RECOMMENDED.</p>
<p>It is not always possible for a constrained client to open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for payloads it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its <link url="#session-response">Session Creation Response</link> to "1", however this is NOT RECOMMENDED.</p>
<p>If a session will use polling, the connection manager SHOULD specify a higher than normal value for the 'inactivity' attribute (see <link url="#inactive">Inactivity</link>) in its session creation response. The increase SHOULD be greater than the value it specifies for the 'polling' attribute.</p>
<p>If the client sends two consecutive empty new requests (i.e. requests with incremented rid attributes, not repeat requests) within a period shorter than the number of seconds specified by the 'polling' attribute (the shortest allowable polling interval) in the session creation response, and if the connection manager's response to the first request contained no payloads, then upon reception of the second request the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client.</p>
<example caption="Too frequent polling response">
@ -500,7 +581,7 @@ Content-Length: 68
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>Note: If the connection manager did not specify a 'polling' attribute in the session creation response, then it MUST allow the client to poll as frequently as it chooses.</p>
</section1>
<section1 topic='Terminating the HTTP Session' anchor='terminate'>
<section1 topic='Terminating the BOSH Session' anchor='terminate'>
<p>At any time, the client MAY gracefully terminate the session by sending a &lt;body/&gt; element with a 'type' attribute set to "terminate". The termination request MAY include one or more payloads that the connection manager MUST forward to the server to ensure graceful logoff.</p>
<example caption="Session termination by client">
<![CDATA[POST /webclient HTTP/1.1
@ -544,7 +625,9 @@ Content-Length: 68
</section2>
<section2 topic='Broken Connections' anchor='rids-broken'>
<p>Unreliable network communications or client constraints can result in broken connections. The connection manager SHOULD remember the 'rid' and the associated HTTP response body of the client's most recent requests which were not session pause requests (see <link url="#inactive">Inactivity</link>) and which did not result in an HTTP or binding error. The number of responses to non-pause requests kept in the buffer SHOULD be either the same as the maximum number of simultaneous requests allowed by the connection manager or, if <link url="#ack">Acknowledgements</link> are being used, the number of responses that have not yet been acknowledged.</p>
<p>If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a &lt;body/&gt; wrapper possessing appropriate attributes and optionally containing one or more XML payloads). If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error:</p>
<p>If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a &lt;body/&gt; wrapper possessing appropriate attributes and optionally containing one or more XML payloads).</p>
<p>If the connection manager receives a request for a 'rid' which has already been received but to which it has not yet responded then it SHOULD respond immediately to the existing request with a recoverable binding condition (see <link url="#errorstatus-recover">Recoverable Binding Conditions</link>) and send any future response to the latest request. There is a possibility that a client might subvert polling frequency limits by deliberately sending requests for the same 'rid' multiple times, and so a connection manager implementation MAY choose to impose a limit to the frequency or number of requests for the same 'rid'. If the client exceeds this limit then the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client (see <link url="#errorstatus-terminal">Terminal Binding Conditions</link>).</p>
<p>If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error:</p>
<example caption="Response not in buffer error">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -574,6 +657,7 @@ Content-Length: 68
...
K(n) = hex(SHA-1(K(n-1)))
</example>
<p>Because case is not significant in hexadecimal encoding, key comparisons SHOULD be case insensitive.</p>
</section2>
<section2 topic="Use of Keys" anchor='keys-use'>
<p>The client MUST set the 'newkey' attribute of the first request in the session to the value K(n).</p>
@ -604,7 +688,7 @@ Content-Length: 88
sid='SomeSID'
key='bfb06a6f113cd6fd3838ab9d300fdb4fe3da2f7d'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>The connection manager MAY verify the key by calculating the SHA-1 hash of the key and comparing it to the 'newkey' attribute of the previous request (or the 'key' attribute if the 'newkey' attribute was not set). If the values do not match (or if it receives a request without a 'key' attribute and the 'newkey' or 'key' attribute of the previous request was set), then the connection manager MUST NOT process the element, MUST terminate the session, and MUST return an 'item-not-found' terminal binding error.</p>
<p>The connection manager MAY verify the key by calculating the SHA-1 hash of the key and performing a case insensitive comparison of it to the 'newkey' attribute of the previous request (or the 'key' attribute if the 'newkey' attribute was not set). If the values do not match (or if it receives a request without a 'key' attribute and the 'newkey' or 'key' attribute of the previous request was set), then the connection manager MUST NOT process the element, MUST terminate the session, and MUST return an 'item-not-found' terminal binding error.</p>
<example caption="Invalid Key Sequence Error">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -645,7 +729,7 @@ Content-Length: 188
<section1 topic='Multiple Streams' anchor='multi'>
<section2 topic="Introduction" anchor='multi-intro'>
<p>The OPTIONAL feature described in this section enables multiple XML streams to be contained within a single HTTP session. This feature is essential in runtime environments that prevent HTTP Pipelining, thereby constraining the number of simultaneous HTTP requests a client can make to each connection manager, since clients running in such environments need multi-stream sessions if they are to connect using more than one account at the same time. This feature also reduces network traffic for any client that needs to establish parallel streams over HTTP.</p>
<p>The OPTIONAL feature described in this section enables multiple XML streams to be contained within a single HTTP session. This feature allows for clients to connect using more than one account at the same time. This feature also reduces network traffic for any client that needs to establish parallel streams over HTTP.</p>
</section2>
<section2 topic="Discovery" anchor='multi-discover'>
<p>If a connection manager supports the multi-streams feature, it MUST include a 'stream' attribute in its <link url="#session-response">Session Creation Response</link>. If a client does not receive the 'stream' attribute then it MUST assume that the connection manager does not support the feature. <note>Therefore a client and a connection manager will be compatible even if one or the other offers no support for multi-stream sessions.</note></p>
@ -670,7 +754,7 @@ Content-Length: 128
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
</section2>
<section2 topic="Adding Streams To A Session" anchor='multi-add'>
<p>If the connection manager included a 'stream' attribute in its session creation response then the client MAY ask it to open another stream at any time by sending it an empty &lt;body/&gt; element with a 'to' attribute. The request MUST include valid 'sid' and 'rid' <note>The 'rid' attribute is always incremented normally without reference to any 'stream' attribute.</note> attributes, and SHOULD also include an 'xml:lang' attribute. The request MAY include 'route', 'from' and 'secure' attributes (see <link url="#session-request">Session Creation Request</link>), but it SHOULD NOT include 'ver', 'content', 'hold' or 'wait' attributes (since a new session is not being created).</p>
<p>If the connection manager included a 'stream' attribute in its session creation response then the client MAY ask it to open another stream at any time by sending it an empty &lt;body/&gt; element with a 'to' attribute. The request MUST include valid 'sid' and 'rid' <note>The 'rid' attribute is always incremented normally without reference to any 'stream' attribute.</note> attributes, and SHOULD also include an 'xml:lang' attribute. The request MAY include either 'route' or 'from' attributes (see <link url="#session-request">Session Creation Request</link>), but it SHOULD NOT include 'ver', 'content', 'hold' or 'wait' attributes (since a new session is not being created).</p>
<example caption="Requesting another stream">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.example.com
@ -684,7 +768,7 @@ Content-Length: 104
route='xmpp:example.com:9999'
xml:lang='en'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>If the connection manager did not indicate its support for multiple streams at the start of the session, then it MUST ignore the extra attributes and treat the request as a normal empty request for payloads (see <link url="#payloads">Sending and Receiving XML Payloads</link>). <note>This helps to ensure backwards-compatibility with older implementations.</note> Otherwise it MUST open a new stream with the specified server (see <link url="#session-response">Session Creation Response</link>), generate a new stream name, and respond to the client with the name. The response MAY also include 'from' and 'secure' attributes, but it SHOULD NOT include 'sid', 'requests', 'polling', 'hold', 'inactivity', 'maxpause', 'accept', 'charsets', 'ver' or 'wait' attributes.</p>
<p>If the connection manager did not indicate its support for multiple streams at the start of the session, then it MUST ignore the extra attributes and treat the request as a normal empty request for payloads (see <link url="#payloads">Sending and Receiving XML Payloads</link>). <note>This helps to ensure backwards-compatibility with older implementations.</note> Otherwise it MUST open a new stream with the specified server (see <link url="#session-response">Session Creation Response</link>), generate a new stream name, and respond to the client with the name. The response MAY also include the 'from' attribute, but it SHOULD NOT include 'sid', 'requests', 'polling', 'hold', 'inactivity', 'maxpause', 'accept', 'charsets', 'ver' or 'wait' attributes.</p>
<example caption="Add stream response">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -693,12 +777,12 @@ Content-Length: 128
<body stream='secondStreamName'
from='example.com'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>Note: If the response did not include either 'from' or 'secure' attributes then they MAY be sent in a subsequent response instead (see <link url="#session-response">Session Creation Response</link>). In that case the 'stream' attribute MUST also be specified.</p>
<p>Note: If the response did not include a 'from' attribute then they MAY be sent in a subsequent response instead (see <link url="#session-response">Session Creation Response</link>). In that case the 'stream' attribute MUST also be specified.</p>
</section2>
<section2 topic="Transmitting Payloads" anchor='multi-transmit'>
<p>If more than one stream has been opened within a session, then all non-empty &lt;body/&gt; elements sent by the connection manager MUST include a 'stream' attribute that specifies which stream <em>all</em> the payloads it contains belong to. The client SHOULD include a 'stream' attribute for the same purpose. The client MAY omit the 'stream' attribute if it wants the connection manager to broadcast the payloads over all open streams. Note: A &lt;body/&gt; element MUST NOT contain different payloads for different streams.</p>
<p>If a stream name does not correspond to one of the session's open streams, then the receiving connection manager SHOULD return an 'item-not-found' terminal binding error, or the receiving client SHOULD terminate the session. However, if the receiving entity has only just closed the stream (and the sender might not have been aware of that when it sent the payloads), then it MAY instead simply silently ignore any payloads the &lt;body/&gt; element contains.</p>
<p>Note: Empty &lt;body/&gt; elements that do not include a 'from' or 'secure' attribute SHOULD NOT include a 'stream' attribute (since nothing is being transmitted for any stream). If such a &lt;body/&gt; element does include a 'stream' attribute then the receiving entity SHOULD ignore the attribute.</p>
<p>Note: Empty &lt;body/&gt; elements that do not include a 'from' attribute SHOULD NOT include a 'stream' attribute (since nothing is being transmitted for any stream). If such a &lt;body/&gt; element does include a 'stream' attribute then the receiving entity SHOULD ignore the attribute.</p>
<example caption="Client sends payload with a stream name">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.example.com
@ -747,7 +831,7 @@ Content-Length: 188
</body>]]></example>
</section2>
<section2 topic='Closing a Stream' anchor='multi-close'>
<p>If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section <link url="#terminate">Terminating the HTTP Session</link> above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any payloads the terminate request contains to all streams), and terminate the session.</p>
<p>If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section <link url="#terminate">Terminating the BOSH Session</link> above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any payloads the terminate request contains to all streams), and terminate the session.</p>
<example caption="Client closes one stream">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.example.com
@ -951,8 +1035,7 @@ Content-Length: 68
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='HTTP Pipelining' anchor='impl-pipelining'>
<p>Even if the client requests HTTP Pipelining and the connection manager supports it, there is no guarantee that pipelining will succeed, because it might not be supported by intermediate proxies.</p>
<p>The best the client can do is to request the use of HTTP Pipelining by setting the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections.</p>
<p>HTTP pipelining allows a client to send multiple requests over the same HTTP socket connection without waiting for the corresponding responses. However, <cite>RFC 2616</cite> notes that only idempotent methods should be allowed to use HTTP pipelining, which does not include the POST method used extensively by BOSH. Furthermore, there is no guarantee that pipelining will succeed because intermediate proxies might not support it. Therefore, clients and connection managers SHOULD NOT use HTTP Pipelining.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -1075,6 +1158,6 @@ Content-Length: 68
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
<p>Thanks to Mike Cumings, Tomas Karasek, Tobias Markmann, Chris Seymour, Safa Sofuo&#287;lu, Stefan Strigler, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback.</p>
<p>Thanks to Dave Cridland, Mike Cumings, Tomas Karasek, Steffen Larsen, Tobias Markmann, Matt Miller, Chris Seymour, Safa Sofuo&#287;lu, Stefan Strigler, Mike Taylor, Winfriend Tilanus, Matthew Wild, Kevin Winters, and Christopher Zorn for their feedback.</p>
</section1>
</xep>

21
xep-0152.xml
View File

@ -11,7 +11,6 @@
&LEGALNOTICE;
<number>0152</number>
<status>Proposed</status>
<lastcall>2013-03-19</lastcall>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -24,6 +23,12 @@
<shortname>reach</shortname>
&stpeter;
&hildjj;
<revision>
<version>0.6</version>
<date>2013-12-02</date>
<initials>psa</initials>
<remark><p>Further clarified the intent of the protocol.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2013-09-25</date>
@ -70,13 +75,13 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<p>Sometimes it is desirable to augment instant messaging (IM) with another real-time communications medium, such as a voice conversation conducted over the traditional public switched telephone network (PSTN) or Voice over Internet Protocol (VoIP) applications. In order to facilitate this functionality, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<ul>
<li><p>Publish the address(es) in the user's vCard (see &xep0054; and &xep0292;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).</p></li>
<li><p>Send the address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Transport</link> section of this document and is consistent with &rfc6121; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send address(es) to the appropriate &xep0060; node; this option is described in the <link url='#transport-pep'>PEP Transport</link> section of this document but might not be available at all service providers.</p></li>
</ul>
<p>This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard.</p>
<p>This document defines methods for publishing addresses at which a user can be reached temporarily, as opposed to semi-permanent addresses of the kind that are more appropriately communicated in a user's vCard. We illustrate this usage through the scenario of a user sending a reachability address upon entering a physical conference room and then sending an updated notification (without a reachability address) upon leaving the conference room. Similar scenarios might apply when an XMPP implementation is used with technologies such as WebRTC and in deployments of the combined use of SIP and XMPP ("CUSAX"; &rfc7081;).</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -120,7 +125,7 @@
<section2 topic='Presence Transport' anchor='transport-presence'>
<p>To broadcast reachability addresses in presence information, a user's client includes the &lt;reach/&gt; element in the &PRESENCE; stanza it sends to its server.</p>
<p>For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discovery a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.</p>
<p>For example, consider someone who walks into a conference room at the office. Via nearfield communication, the user's XMPP client might auto-discover a 'tel:' URI for the room audio system and a 'sip:' URI for the room video system.</p>
<example caption="User&apos;s Client Includes Reachability Addresses in Presence"><![CDATA[
<presence from='romeo@example.com/mobile'>
<reach xmlns='urn:xmpp:reach:0'>
@ -131,7 +136,7 @@
]]></example>
<p>The user's server then broadcasts that presence stanza to all entities who are subscribed to the user's presence:</p>
<example caption="User&apos;s Server Broadcasts Presence Information"><![CDATA[
<presence from='romeo@montague.net' to='juliet@capulet.com'>
<presence from='romeo@montague.net/mobile' to='juliet@capulet.com'>
<reach xmlns='urn:xmpp:reach:0'>
<addr uri='tel:+1-303-555-1212'/>
<addr uri='sip:room123@example.com'/>
@ -229,8 +234,8 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>To preserve network bandwidth, the sender SHOULD NOT include the &lt;desc/&gt; element unless that information is deemed necessary to enable communication.</p>
<p>A recipient SHOULD attempt communications with reachability addresses in the order that the &lt;addr/&gt; elements appear within the &lt;reach/&gt; element.</p>
<p>To preserve network bandwidth, the sender ought not include the &lt;desc/&gt; element unless that information is deemed necessary to enable communication.</p>
<p>A recipient ought to attempt communications with reachability addresses in the order that the &lt;addr/&gt; elements appear within the &lt;reach/&gt; element.</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
@ -239,7 +244,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>Security considerations for XMPP presence and PEP publication are described in RFC 6120, RFC 6121, XEP-0060, and XEP-0163.</p>
<t>Advertising a telephone number, SIP URI, or other real-time communication address to one contact or to multiple contacts introduces the possibility of information leakage and subsequent attacks (e.g., unsolicited phone calls). Clients are advised to appropriately warn users about the dangers of such attacks.</t>
<t>Advertising a telephone number, SIP URI, or other real-time communication address to multiple contacts in an unencrypted way (e.g., via XMPP presence or PEP in cases where not all hops are TLS-protected) introduces the possibility of information leakage and subsequent attacks such as unsolicited phone calls. Clients are advised to appropriately warn users about the dangers of such attacks. Alternatively, if the address is especially sensitive (say, a hashname &rfc6920; for use in a system that enables direct private communication outside of XMPP), then a client could send it in a message that itself is end-to-end encrypted.</t>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

39
xep-0156.xml
View File

@ -27,8 +27,8 @@
&stpeter;
&lance;
<revision>
<version>1.1</version>
<date>2013-10-22</date>
<version>1.1rc2</version>
<date>2013-12-03</date>
<initials>ls/psa</initials>
<remark><p>Defined HTTP lookup methods using well-known URIs as specified in RFC 5785.</p></remark>
</revision>
@ -100,7 +100,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile) and &xmppoverwebsocket;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Without ways to auto-discovering alternative connection methods, the relevant information would need to be provided manually by a human user, which is cumbersome and error-prone.</p>
<p>Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile) and &xmppoverwebsocket;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Without ways to auto-discover alternative connection methods, the relevant information would need to be provided manually by a human user (which is cumbersome and error-prone) or hard-coded into XMPP software applications (which is brittle and not interoperable).</p>
<p>This document defines two ways to encapsulate information about alternative connection methods for auto-discovery:</p>
<ol>
<li>DNS TXT resource records</li>
@ -136,10 +136,10 @@
</section2>
<section2 topic='Examples' anchor='dnsexamples'>
<p>The following examples show two DNS TXT resource records: the first indicates support for the XMPP Over BOSH connection method defined in <cite>XEP-0124</cite> and <cite>XEP-0206</cite> and the second indicates support for WAP connections (the latter connection method is not yet defined).</p>
<p>The following examples show two DNS TXT resource records: the first indicates support for the XMPP Over BOSH connection method defined in <cite>XEP-0124</cite> and <cite>XEP-0206</cite> and the second indicates support for XMPP over WebSocket connections defined in &xmppoverwebsocket;.</p>
<example caption='TXT Resource Records'><![CDATA[
_xmppconnect IN TXT "_xmpp-client-xbosh=https://bosh.jabber.org:5280/bind"
_xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
_xmppconnect IN TXT "_xmpp-client-xbosh=https://web.example.org:5280/bosh"
_xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
]]></example>
</section2>
@ -162,19 +162,19 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
<ol start='1'>
<li>HTTP queries for host-meta information MUST be used only as a fallback after the methods specified in <cite>RFC 6120</cite> have been exhausted.</li>
<li>A domain SHOULD NOT present information in host-meta link records that is available via the DNS SRV records defined in <cite>RFC 6120</cite>.</li>
<li>The order of XMPP related link entries in the host-meta file records SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.</li>
<li>The order of XMPP related link entries in the host-meta file SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.</li>
</ol>
</section2>
<section2 topic='Examples' anchor='httpexamples'>
<p>The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in <cite>XEP-0124</cite> and <cite>XEP-0206</cite> and the second indicates support for the &xmppoverwebsocket; connection method.</p>
<p>The following examples show two host-meta link records: the first indicates support for the XMPP Over BOSH connection method defined in <cite>XEP-0124</cite> and <cite>XEP-0206</cite> and the second indicates support for the XMPP Over WebSocket connection method defined in <cite>draft-ietf-xmpp-websocket</cite>.</p>
<example caption='Result for /.well-known/host-meta'><![CDATA[<?xml version='1.0' encoding=utf-9'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
...
<Link rel="urn:xmpp:alt-connections:xbosh"
href="https://example.com:5280/bosh" />
href="https://web.example.com:5280/bosh" />
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://example.com:5280/websocket" />
href="wss://web.example.com:443/ws" />
...
</XRD>
]]></example>
@ -185,11 +185,11 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
...
{
"rel": "urn:xmpp:alt-connections:xbosh",
"href": "https://example.com:5280/bosh"
"href": "https://web.example.com:5280/bosh"
},
{
"rel": "urn:xmpp:alt-connections:websocket",
"href": "wss://example.com:5280/websocket"
"href": "wss://web.example.com:443/ws"
},
...
]
@ -200,6 +200,7 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
<section1 topic='Security Considerations' anchor='security'>
<p>It is possible that advertisement of alternative connection methods can introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care needs to be taken in determining which alternative connection methods are appropriate to advertise.</p>
<p>Entities that use these connection methods need to ensure that they conform to the security considerations of each method (e.g., by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -228,7 +229,8 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
]]></code>
<p>The registrant can register more than one attribute at a time, each contained in a separate &lt;method/&gt; element.</p>
</section3>
<section3 topic='Initial Registration' anchor='registrar-altconn-init'>
<section3 topic='Registered Values' anchor='registrar-altconn-values'>
<p>This document registers the following values.</p>
<code><![CDATA[
<method>
<name>_xmpp-client-httppoll</name>
@ -239,11 +241,20 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector"
<doc>XEP-0025</doc>
</method>
<method>
<name>_xmpp-client-websocket</name>
<desc>XMPP Over WebSocket connection method</desc>
<syntax>
The ws: or wss: URL at which to contact the WebSocket connection manager or proxy
</syntax>
<doc>draft-ietf-xmpp-websocket</doc>
</method>
<method>
<name>_xmpp-client-xbosh</name>
<desc>XMPP Over Bosh connection method</desc>
<syntax>
The http: or https: URL at which to contact the HTTP Binding connection manager or proxy
The http: or https: URL at which to contact the HTTP Binding (BOSH) connection manager or proxy
</syntax>
<doc>XEP-0206</doc>
</method>

2
xep-0186.xml
View File

@ -10,7 +10,7 @@
<abstract>This document specifies an XMPP-compatible protocol for user invisibility.</abstract>
&LEGALNOTICE;
<number>0186</number>
<status>Experimental</status>
<status>Deferred</status>
<lastcall>2012-07-13</lastcall>
<type>Standards Track</type>
<sig>Standards</sig>

18
xep-0206.xml
View File

@ -26,6 +26,13 @@
</schemaloc>
&ianpaterson;
&stpeter;
&lance;
<revision>
<version>1.4rc1</version>
<date>2013-11-08</date>
<initials>ls</initials>
<remark><p>Incorporated patches from community review.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2010-07-02</date>
@ -69,7 +76,7 @@
</section1>
<section1 topic="Session Creation Request" anchor='initiate'>
<p>The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP &lt;stream:stream/&gt; element as defined in <cite>RFC 3920</cite> and &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<p>The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP &lt;stream:stream/&gt; element as defined in &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<example caption="Requesting a session with a version attribute">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.jabber.org
@ -83,7 +90,6 @@ Content-Length: 104
rid='1573741820'
to='example.com'
route='xmpp:example.com:9999'
secure='true'
wait='60'
xml:lang='en'
xmpp:version='1.0'
@ -110,7 +116,6 @@ Content-Length: 674
from='example.com'
accept='deflate,gzip'
sid='SomeSID'
secure='true'
charsets='ISO_8859-1 ISO-2022-JP'
xmpp:restartlogic='true'
xmpp:version='1.0'
@ -146,12 +151,12 @@ Content-Length: 483
</body>
]]></example>
<p>Note: The client SHOULD ignore any Transport Layer Security (TLS) feature since BOSH channel encryption SHOULD be negotiated at the HTTP layer.</p>
<p>TLS compression (as defined in <cite>RFC 3920</cite>) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding.</p>
<p>TLS compression (as defined in &rfc6120;) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding.</p>
<p>Note: The 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace SHOULD also be included on the request and response when adding new streams to a session.</p>
</section1>
<section1 topic="Authentication and Resource Binding" anchor='preconditions-sasl'>
<p>A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to <cite>RFC 3920</cite> and draft-ietf-xmpp-3920bis.</p>
<p>A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to &rfc6120;</p>
<example caption="SASL authentication step 1">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.example.com
@ -307,7 +312,7 @@ Content-Length: 68
</section1>
<section1 topic='recipient-unavailable' anchor='recipient-unavailable'>
<p>It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of <cite>RFC 3921</cite>:</p>
<p>It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of &rfc6121;</p>
<ol>
<li>If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.</li>
<li>If the delivered stanza was &IQ;, return a &unavailable; error to the sender.</li>
@ -365,6 +370,7 @@ Content-Length: 68
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Dave Cridland, Steffen Larsen, Matt Miller, Jack Moffitt, Stefan Strigler, Mike Taylor, Winfried Tilanus, Ashley Ward, and Matthew Wild for their feedback.</p>
<p>Thanks to Kevin Winters for his assistance with the schema.</p>
</section1>

2
xep-0257.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password.</abstract>
&LEGALNOTICE;
<number>0257</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>

2
xep-0267.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines a convention for presence subscriptions between XMPP servers.</abstract>
&LEGALNOTICE;
<number>0267</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0268.xml
View File

@ -12,7 +12,7 @@
<abstract>This specification defines methods for incident reporting among XMPP server deployments using the IODEF format produced by the IETF's INCH Working Group.</abstract>
&LEGALNOTICE;
<number>0268</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0275.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension for communicating the reputation of any entity on the network.</abstract>
&LEGALNOTICE;
<number>0275</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0276.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension that enables a user to send directed presence with a request for the target to also share presence information for the duration of a communications session.</abstract>
&LEGALNOTICE;
<number>0276</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>None</sig>
<approver>Council</approver>

2
xep-0277.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines a method for microblogging over XMPP.</abstract>
&LEGALNOTICE;
<number>0277</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>None</sig>
<approver>Council</approver>

2
xep-0289.xml
View File

@ -10,7 +10,7 @@
<abstract>This document provides a protocol for federating MUC rooms together in order to reduce the effects of constrained network (e.g. unreliability, severely limited bandwidth) on the room occupants.</abstract>
&LEGALNOTICE;
<number>0289</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0295.xml
View File

@ -20,7 +20,7 @@
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<supersededby>XEP-0335</supersededby>
<shortname>N/A</shortname>
&ksmith;
&mwild;

56
xep-0301.xml
View File

@ -243,9 +243,9 @@
<tr>
<th>event</th>
<th>Description</th>
<th>Action&nbsp;Elements</th>
<th>Sender&nbsp;Support</th>
<th>Recipient&nbsp;Support</th>
<th>Action&#160;Elements</th>
<th>Sender&#160;Support</th>
<th>Recipient&#160;Support</th>
</tr>
<tr>
<td>new</td>
@ -333,26 +333,26 @@
<th>Action</th>
<th>Element</th>
<th>Description</th>
<th>Sender&nbsp;Support</th>
<th>Recipient&nbsp;Support</th>
<th>Sender&#160;Support</th>
<th>Recipient&#160;Support</th>
</tr>
<tr>
<td>Insert&nbsp;Text</td>
<td>&lt;t&nbsp;p='#'&gt;text&lt;/t&gt;</td>
<td>Insert&#160;Text</td>
<td>&lt;t&#160;p='#'&gt;text&lt;/t&gt;</td>
<td>Insert specified <strong>text</strong> at position 'p' in message.</td>
<td><strong>REQUIRED</strong></td>
<td><strong>REQUIRED</strong></td>
</tr>
<tr>
<td>Erase&nbsp;Text</td>
<td>&lt;e&nbsp;p='#'&nbsp;n='#'/&gt;</td>
<td>Erase&#160;Text</td>
<td>&lt;e&#160;p='#'&#160;n='#'/&gt;</td>
<td>Remove 'n' characters before position 'p' in message<em>.</em></td>
<td>RECOMMENDED</td>
<td><strong>REQUIRED</strong></td>
</tr>
<tr>
<td>Wait&nbsp;Interval</td>
<td>&lt;w&nbsp;n='#'/&gt;</td>
<td>Wait&#160;Interval</td>
<td>&lt;w&#160;n='#'/&gt;</td>
<td>Wait 'n' milliseconds.</td>
<td>RECOMMENDED</td>
<td>RECOMMENDED</td>
@ -633,7 +633,7 @@
</section3>
<section3 topic="Usage with Chat States" anchor="usage_with_chat_states">
<p>Real-time text can be used in conjunction with <strong>Chat State Notifications</strong>. It is best to handle <strong>XEP-0301</strong> and <strong>XEP-0085</strong> transmissions in separate &lt;message/&gt; stanzas. Chat states such as &lt;composing/&gt; or &lt;active/&gt; are sent separately from &lt;rtt/&gt; elements.</p>
<p>Chat states are handled as specified by <strong>XEP-0085</strong>. The continuous transmission of real-time text corresponds to a &lt;composing/&gt; chat state. Therefore, the timing of the &lt;composing/&gt; chat state coincides with the beginning of continuous &lt;rtt/&gt; transmission.&nbsp;</p>
<p>Chat states are handled as specified by <strong>XEP-0085</strong>. The continuous transmission of real-time text corresponds to a &lt;composing/&gt; chat state. Therefore, the timing of the &lt;composing/&gt; chat state coincides with the beginning of continuous &lt;rtt/&gt; transmission.</p>
</section3>
<section3 topic="Usage with Last Message Correction" anchor="usage_with_last_message_correction">
<p>It is possible to use <strong>Last Message Correction</strong> with real-time text. If <strong>XEP-0308</strong> is implemented in concert with this specification, the following rules apply:</p>
@ -841,49 +841,49 @@
<tr>
<th>Element</th>
<th>Action</th>
<th>Real -Time&nbsp;Message</th>
<th>Cursor&nbsp;Position*</th>
<th>Real -Time&#160;Message</th>
<th>Cursor&#160;Position*</th>
</tr>
<tr>
<td>&lt;t&gt;Helo&lt;/t&gt;</td>
<td>Output&nbsp;"Helo"</td>
<td>Output&#160;"Helo"</td>
<td>Helo</td>
<td>4</td>
</tr>
<tr>
<td>&lt;e/&gt;</td>
<td>Erase&nbsp;1&nbsp;character&nbsp;from&nbsp;end&nbsp;of&nbsp;line.</td>
<td>Erase&#160;1&#160;character&#160;from&#160;end&#160;of&#160;line.</td>
<td>Hel</td>
<td>3</td>
</tr>
<tr>
<td>&lt;t&gt;lo...planet&lt;/t&gt;</td>
<td>Output&nbsp;"lo...planet"&nbsp;at&nbsp;end&nbsp;of&nbsp;line.</td>
<td>Output&#160;"lo...planet"&#160;at&#160;end&#160;of&#160;line.</td>
<td>Hello...planet</td>
<td>14</td>
</tr>
<tr>
<td>&lt;e&nbsp;n='6'/&gt;</td>
<td>Erase&nbsp;6&nbsp;characters&nbsp;from&nbsp;end&nbsp;of&nbsp;line</td>
<td>&lt;e&#160;n='6'/&gt;</td>
<td>Erase&#160;6&#160;characters&#160;from&#160;end&#160;of&#160;line</td>
<td>Hello...</td>
<td>8</td>
</tr>
<tr>
<td>&lt;t&gt;&nbsp;World&lt;/t&gt;</td>
<td>Output&nbsp;"&nbsp;World"&nbsp;at&nbsp;end&nbsp;of&nbsp;line.</td>
<td>Hello...&nbsp;World</td>
<td>&lt;t&gt;&#160;World&lt;/t&gt;</td>
<td>Output&#160;"&#160;World"&#160;at&#160;end&#160;of&#160;line.</td>
<td>Hello...&#160;World</td>
<td>14</td>
</tr>
<tr>
<td>&lt;e&nbsp;n='3'&nbsp;p='8'/&gt;</td>
<td>Erase&nbsp;3&nbsp;characters&nbsp;before&nbsp;position&nbsp;8</td>
<td>Hello&nbsp;World</td>
<td>&lt;e&#160;n='3'&#160;p='8'/&gt;</td>
<td>Erase&#160;3&#160;characters&#160;before&#160;position&#160;8</td>
<td>Hello&#160;World</td>
<td>5</td>
</tr>
<tr>
<td>&lt;t&nbsp;p='5'&gt;&nbsp;there,&lt;/t&gt;</td>
<td>Output&nbsp;"&nbsp;there,"&nbsp;at&nbsp;position&nbsp;5</td>
<td>Hello&nbsp;there,&nbsp;World</td>
<td>&lt;t&#160;p='5'&gt;&#160;there,&lt;/t&gt;</td>
<td>Output&#160;"&#160;there,"&#160;at&#160;position&#160;5</td>
<td>Hello&#160;there,&#160;World</td>
<td>12</td>
</tr>
</table>

2
xep-0309.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification shows how to combine and extend a number of existing XMPP protocols for improved sharing of information about XMPP servers.</abstract>
&LEGALNOTICE;
<number>0309</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0312.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines a publish-subscribe feature that enables a subscriber to automatically receive pubsub and PEP notifications since the last logout time of a specific resource.</abstract>
&LEGALNOTICE;
<number>0312</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0314.xml
View File

@ -31,7 +31,7 @@
</abstract>
&LEGALNOTICE;
<number>0314</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>

2
xep-0315.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines an XMPP protocol extension for including XML-data in XEP-0004 data forms.</abstract>
&LEGALNOTICE;
<number>0315</number>
<status>Experimental</status>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>

52
xep-0320.xml
View File

@ -18,6 +18,7 @@
<spec>XMPP Core</spec>
<spec>XEP-0166</spec>
<spec>XEP-0167</spec>
<spec>RFC 4145</spec>
<spec>RFC 4572</spec>
<spec>RFC 5763</spec>
</dependencies>
@ -31,6 +32,18 @@
-->
<discuss>jingle</discuss>
&fippo;
<revision>
<version>0.2</version>
<date>2013-10-22</date>
<initials>ph</initials>
<remark>
<ul>
<li>Changed namespace to urn:xmpp:jingle:apps:dtls:0.</li>
<li>Removed &quot;required&quot; attribute based on implementation feedback.</li>
<li>Added setup attribute to map SDP setup attribute.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-04-16</date>
@ -62,18 +75,23 @@ a=fingerprint:hash-func fingerprint
<code>
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
</code>
<p>This SDP attribute can be translated into Jingle as a &lt;fingerprint/&gt; element qualified by the 'urn:xmpp:tmp:jingle:apps:dtls:0' namespace, as shown below.</p>
<p>Additionally, the SDP setup attribute defined in &rfc4145; must be mapped, whose usage for DTLS-SRTP is defined in <cite>RFC 5763</cite>.</p>
<code>
a=setup:role
</code>
<p>These SDP attributes can be translated into Jingle as a &lt;fingerprint/&gt; element qualified by the 'urn:xmpp:jingle:apps:dtls:0' namespace, as shown below.</p>
<code><![CDATA[
<fingerprint xmlns='urn:xmpp:tmp:jingle:apps:dtls:0' hash='hash-func'>fingerprint</fingerprint>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='hash-func' setup='role'>
fingerprint
</fingerprint>
]]></code>
<p>An example follows.</p>
<code><![CDATA[
<fingerprint mlns='urn:xmpp:tmp:jingle:apps:dtls:0' hash='sha-256'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-256' setup='actpass'>
02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
</fingerprint>
]]></code>
<p>Note: since DTLS can be used to protect non-RTP sessions like SCTP including the fingerprint in the &lt;encryption/&gt; element defined in &xep0167; was deemed inappropriate. Also, the &lt;encryption/&gt; element defined there only applies to the encryption of the RTP data part, whereas DTLS (and DTLS-SRTP) protects the whole message.</p>
<p>If the Jingle initiator wishes to use DTLS-SRTP, it includes the &lt;fingerprint/&gt; element in its session invitation. If the initiator requires the use of DTLS, the &lt;fingerprint/&gt; element MUST include a 'required' attribute whose logical value is TRUE and whose lexical value is "true" or "1" &BOOLEANNOTE;, where this attribute defaults to a logical value of FALSE (i.e., a lexical value of "false" or "0").</p>
<p>If the Jingle initiator wishes to use DTLS-SRTP, it includes the &lt;fingerprint/&gt; element in its session invitation.</p>
<example caption="Initiator sends session invitation with DTLS fingerprint"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='uz61v4m4'
@ -94,7 +112,7 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<fingerprint xmlns='urn:xmpp:tmp:jingle:apps:dtls:0' hash='sha-256' required='true'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-256' setup='actpass'>
02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
</fingerprint>
<candidate component='1'
@ -143,7 +161,7 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='YH75Fviy6338Vbrhrlp8Yh'
ufrag='9uB6'>
<fingerprint xmlns='urn:xmpp:tmp:jingle:apps:dtls:0' hash='sha-256' required='1'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-256' setup='active'>
BD:E8:2C:D3:BD:B6:98:50:45:7D:5B:36:89:53:31:15:52:25:88:82:06:95:88:A3:3D:A5:43:8D:5C:21:21:66
</fingerprint>
<candidate component='1'
@ -176,7 +194,7 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='YH75Fviy6338Vbrhrlp8Yh'
ufrag='9uB6'>
<fingerprint xmlns='urn:xmpp:tmp:jingle:apps:dtls:0' hash='sha-256' required='1'>
<fingerprint xmlns='urn:xmpp:jingle:apps:dtls:0' hash='sha-256' setup='active'>
BD:E8:2C:D3:BD:B6:98:50:45:7D:5B:36:89:53:31:15:52:25:88:82:06:95:88:A3:3D:A5:43:8D:5C:21:21:66
</fingerprint>
<candidate component='1'
@ -230,7 +248,7 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
<p>Thanks to Justin Uberti.</p>
<p>Thanks to Justin Uberti and Lance Stout.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
@ -252,8 +270,8 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:tmp:jingle:apps:dtls:0'
xmlns='urn:xmpp:tmp:jingle:apps:dtls:0'
targetNamespace='urn:xmpp:jingle:apps:dtls:0'
xmlns='urn:xmpp:jingle:apps:dtls:0'
elementFormDefault='qualified'>
<xs:annotation>
@ -268,12 +286,20 @@ a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:C
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='hash' type='xs:string' use='required'/>
<xs:attribute name='required' type='xs:boolean' default='false'/>
<xs:attribute name='setup' use='required'/>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='active'/>
<xs:enumeration value='passive'/>
<xs:enumeration value='actpass'/>
<xs:enumeration value='holdconn'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section1>

22
xep-0326.xml
View File

@ -3751,37 +3751,37 @@
<tr>
<td>id</td>
<td>required</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>The ID of the node in the data source.</td>
</tr>
<tr>
<td>displayName</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>If provided, a string presentable to users. If localization is supported and a correct language attribute was provided, this string will be localized.</td>
</tr>
<tr>
<td>nodeType</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>A string representing the type of the node.</td>
</tr>
<tr>
<td>localId</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>If provided, an ID for the node, but unique locally between siblings.</td>
</tr>
<tr>
<td>logId</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>If provided, an ID for the node, as it would appear or be used in system logs.</td>
</tr>
<tr>
<td>cacheType</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>Used to uniquely identify the node in sources where the ID of the node is not sufficient. Example: In a spatial ordering different nodes may represent
countries, regions, cities, areas, streets, buildings and apartments in the same source. However, the ID of each node would depend on what type of node it
represents. It might be valid to have a region, city and/or area with the same ID. So, to these circumstances, a Cache Type of Country, Region, City, Area,
@ -3790,13 +3790,13 @@
<tr>
<td>state</td>
<td>required</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>Current overall state of the node.</td>
</tr>
<tr>
<td>hasChildren</td>
<td>required</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>If the node has children or not.</td>
</tr>
<tr>
@ -3830,19 +3830,19 @@
<tr>
<td>parentId</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>The node ID of the parent node. If not available, the node is considered a root node.</td>
</tr>
<tr>
<td>parentCacheType</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>The Cache Type of the parent node.</td>
</tr>
<tr>
<td>lastChanged</td>
<td>optional</td>
<td>&nbsp;</td>
<td>&#160;</td>
<td>When the node was last changed. Can be used by clients to synchronize content between the concentrator and itself.</td>
</tr>
</table>

71
xep-0329.xml
View File

@ -31,11 +31,13 @@
<jid>j.lagrange@jabber.org</jid>
<jid>j.lagrange@gajim.org</jid>
</author>
<author>
<firstname>Lance</firstname>
<surname>Stout</surname>
<email>lancestout@gmail.com</email>
</author>
&lance;
<revision>
<version>0.2</version>
<date>2013-11-19</date>
<initials>jl</initials>
<remark><p>Corrected namespace to use XSF format.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-06-11</date>
@ -75,7 +77,7 @@
from='juliet@capulet.com/chamber'
to='romeo@montague.net/home'
id='1234'>
<query xmlns="urn:xmpp:fis" />
<query xmlns="urn:xmpp:fis:0" />
</iq>
]]>
</example>
@ -86,7 +88,7 @@
from='romeo@montague.net/home'
to='juliet@capulet.com/chamber'
id='1234'>
<query xmlns="urn:xmpp:fis">
<query xmlns="urn:xmpp:fis:0">
<directory name='documents'/>
<directory name='pics'/>
<directory name='audio'/>
@ -101,7 +103,7 @@
from='romeo@montague.net/home'
to='juliet@capulet.com/chamber'
id='1234'>
<query xmlns="urn:xmpp:fis" />
<query xmlns="urn:xmpp:fis:0" />
</iq>
]]>
</example>
@ -112,11 +114,11 @@
from='juliet@capulet.com/chamber'
to='romeo@montague.net/home'
id='1234'>
<query xmlns="urn:xmpp:fis" node="documents" />
<query xmlns="urn:xmpp:fis:0" node="documents" />
</iq>
]]>
</example>
<p>When replying with a list of files, the offering entity can choose to either reply with verbose information on the file using the file attributes defined by &xep0254; or it may reply only with the 'name' attribute, which is required and MUST be included in every response.</p>
<p>When replying with a list of files, the offering entity can choose to either reply with verbose information on the file using the file attributes defined by &xep0234; or it may reply only with the 'name' attribute, which is required and MUST be included in every response.</p>
<p>It is RECOMENDED, when the list files to be sent is small, that a verbose response be made (in order to avoid going back and forth requesting information), and that a non-verbose reponse be made otherwise. This recomendation is made to save bandwidth.</p>
<example caption='The offering entity replies with information about a particular directory'>
<![CDATA[
@ -124,7 +126,7 @@
from='romeo@montague.net/home'
to='juliet@capulet.com/chamber'
id='1234'>
<query xmlns="urn:xmpp:fis" node="documents">
<query xmlns="urn:xmpp:fis:0" node="documents">
<file xmlns='urn:xmpp:jingle:apps:file-transfer:3'>
<name>test.txt</name>
<date>1969-07-21T02:56:15Z</date>
@ -148,7 +150,7 @@
from='juliet@capulet.com/chamber'
to='romeo@montague.net/home'
id='1234'>
<query xmlns="urn:xmpp:fis" node="documents/test2.txt" />
<query xmlns="urn:xmpp:fis:0" node="documents/test2.txt" />
</iq>
]]>
</example>
@ -158,7 +160,7 @@
from='romeo@montague.net/home'
to='juliet@capulet.com/chamber'
id='1234'>
<query xmlns="urn:xmpp:fis" node="test2.txt">
<query xmlns="urn:xmpp:fis:0" node="test2.txt">
<file xmlns='urn:xmpp:jingle:apps:file-transfer:3'>
<name>test2.txt</name>
<size>1000</size>
@ -179,49 +181,6 @@
<section2 topic='Out of Band Transfer' anchor='out-of-band'>
<p>One obvious way to overcome the limitations of sending large stanzas in-band, is to transfer that information out of band. &xep0265; could be used for that purpose. It is hereby RECOMMENDED its implementation when the offering entity has a massive amount of files that would not be practical to advertise in-band.</p>
<p>It is further recommended that when using XEP-0265, the entire directory structure, along with all the files in the shared folder and subfolders, be exchanged in one single reply. Also, all the files attributes should be included. This is to avoid wasting bandwidth initiating out of band streams going back and forth. </p>
<!--
<p>One obvious way to overcome the limitations of sending large stanzas in-band, is to transfer that information out of band. Several extensions have tackled that problem, for example &xep0265; and &xep0105; could be used for this purpose. Unfortunately, both of those extensions are deprecated and thus it is not advised their implementation.</p>
<p>A workaround which would provide the same functionality as those xeps, is to advertise the existence of a tree.xml file in the root of the shared folder. This file would contain the whole directory structure of the shared folder. Its format is exactly the same as the stanzas defined herein, with the exception that it MUST NOT include the "iq" portion of the stanza.</p>
<p>It is strongly RECOMMENDED that tree.xml include relevant information of the files in order to avoid wasting bandwidth</p>
<example caption='The format of tree.xml'>
<![CDATA[
<match>
<offer>
<file>
<date>1969-07-21T02:56:15Z</date>
<desc>This is a test. If this were a real file...</desc>
<name>test.txt</name>
<size>1022</size>
<hash xmlns='urn:xmpp:hashes:1' algo='sha-1'>552da749930852c69ae5d2141d3766b1</hash>
</file>
<file>
<name>test2.txt</name>
<date>1970-07-21T02:56:15Z</date>
<desc/>
<size>1000</size>
<hash xmlns='urn:xmpp:hashes:1' algo='sha-1'>662da749930852c69ae5d2141d3766b1</hash>
</file>
<directory name='/pics'>
<file>
<name>test3.png</name>
<date>1980-07-21T02:56:15Z</date>
<desc/>
<size>10340</size>
<hash xmlns='urn:xmpp:hashes:1' algo='sha-1'>662da749930852c69ae5d2141d3776b1</hash>
</file>
<file>
<name>test4.png</name>
<date>1990-07-21T02:56:15Z</date>
<desc/>
<size>10740</size>
<hash xmlns='urn:xmpp:hashes:1' algo='sha-1'>662da749930852c69ae5d2141d3776b2</hash>
</file>
</directory>
</offer>
</match>
]]>
</example>
-->
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='implementation'>

18
inbox/json-containers.xml → xep-0335.xml
View File

@ -8,15 +8,9 @@
<header>
<title>JSON Containers</title>
<abstract>This specification defines an element to be used for encapsulating JSON data in XMPP.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2012 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), 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.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; 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. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<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 out of the use or inability to use 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.</liability>
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
&LEGALNOTICE;
<number>0335</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -28,6 +22,12 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&mwild;
<revision>
<version>0.1</version>
<date>2013-10-25</date>
<initials>psa</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2013-10-09</date>

22
xep.ent
View File

@ -374,7 +374,6 @@ THE SOFTWARE.
<!ENTITY SDN.801c "<span class='ref'>SDN.801c</span> <note>SDN.801c: Access Control Concept and Mechanism, US National Security Agency, Revision C, 12 May 1999.</note>" >
<!ENTITY unicode "<span class='ref'>Unicode</span> <note>The Unicode Standard, Version 3.2.0 (The Unicode Consortium, 2000).</note>" >
<!ENTITY wap "<span class='ref'><link url='http://www.wapforum.org/'>Wireless Access Protocol (WAP)</link></span> <note>Wireless Access Protocol (WAP) &lt;<link url='http://www.wapforum.org/'>http://www.wapforum.org/</link>&gt;.</note>" >
<!ENTITY websocket "<span class='ref'><link url='http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol'>The Web Socket Protocol</link></span> <note>The Web Socket Protocol &lt;<link url='http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol'>http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol</link>&gt;.</note>" >
<!ENTITY wv-csp "<span class='ref'><link url='http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html'>WV Client-Server Protocol v1.1</link></span> <note>Wireless Village Client-Server Protocol v1.1 &lt;<link url='http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html'>http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html</link>&gt;.</note>" >
<!ENTITY xfn "<span class='ref'><link url='http://gmpg.org/xfn/index'>XHTML Friends Network (XFN)</link></span> <note>XHTML Friends Network (XFN) &lt;<link url='http://gmpg.org/xfn/index'>http://gmpg.org/xfn/index</link>&gt;.</note>" >
<!ENTITY xmlrpc "<span class='ref'><link url='http://www.xmlrpc.com/spec'>XML-RPC</link></span> <note>XML-RPC &lt;<link url='http://www.xmlrpc.com/spec'>http://www.xmlrpc.com/spec</link>&gt;.</note>" >
@ -538,6 +537,7 @@ THE SOFTWARE.
<!ENTITY rfc4119 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4119'>RFC 4119</link></span> <note>RFC 4119: A Presence-based GEOPRIV Location Object Format &lt;<link url='http://tools.ietf.org/html/rfc4119'>http://tools.ietf.org/html/rfc4119</link>&gt;.</note>" >
<!ENTITY rfc4120 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4120'>RFC 4120</link></span> <note>RFC 4120: The Kerberos Network Authentication Service (V5) &lt;<link url='http://tools.ietf.org/html/rfc4120'>http://tools.ietf.org/html/rfc4120</link>&gt;.</note>" >
<!ENTITY rfc4122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4122'>RFC 4122</link></span> <note>RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace &lt;<link url='http://tools.ietf.org/html/rfc4122'>http://tools.ietf.org/html/rfc4122</link>&gt;.</note>" >
<!ENTITY rfc4145 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4145'>RFC 4145</link></span> <note>RFC 4145: TCP-Based Media Transport in the Session Description Protocol (SDP) &lt;<link url='http://tools.ietf.org/html/rfc4145'>http://tools.ietf.org/html/rfc4145</link>&gt;.</note>" >
<!ENTITY rfc4227 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4227'>RFC 4227</link></span> <note>RFC 4227: Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) &lt;<link url='http://tools.ietf.org/html/rfc4227'>http://tools.ietf.org/html/rfc4227</link>&gt;.</note>" >
<!ENTITY rfc4251 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4251'>RFC 4251</link></span> <note>RFC 4251: The Secure Shell (SSH) Protocol Architecture &lt;<link url='http://tools.ietf.org/html/rfc4251'>http://tools.ietf.org/html/rfc4251</link>&gt;.</note>" >
<!ENTITY rfc4252 "<span class='ref'><link url='http://tools.ietf.org/html/rfc4252'>RFC 4252</link></span> <note>RFC 4252: The Secure Shell (SHS) Authentication Protocol &lt;<link url='http://tools.ietf.org/html/rfc4252'>http://tools.ietf.org/html/rfc4252</link>&gt;.</note>" >
@ -603,10 +603,13 @@ THE SOFTWARE.
<!ENTITY rfc5450 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5450'>RFC 5450</link></span> <note>RFC 5450: Transmission Time Offsets in RTP Streams &lt;<link url='http://tools.ietf.org/html/rfc5450'>http://tools.ietf.org/html/rfc5450</link>&gt;.</note>" >
<!ENTITY rfc5547 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5547'>RFC 5547</link></span> <note>RFC 5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer &lt;<link url='http://tools.ietf.org/html/rfc5547'>http://tools.ietf.org/html/rfc5547</link>&gt;.</note>" >
<!ENTITY rfc5574 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5574'>RFC 5574</link></span> <note>RFC 5574: RTP Payload Format for the Speex Codec &lt;<link url='http://tools.ietf.org/html/rfc5574'>http://tools.ietf.org/html/rfc5574</link>&gt;.</note>" >
<!ENTITY rfc5576 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5576'>RFC 5576</link></span> <note>RFC 5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) &lt;<link url='http://tools.ietf.org/html/rfc5576'>http://tools.ietf.org/html/rfc5576</link>&gt;.</note>" >
<!ENTITY rfc5646 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5646'>RFC 5646</link></span> <note>RFC 5646: Tags for Identifying Languages &lt;<link url='http://tools.ietf.org/html/rfc5646'>http://tools.ietf.org/html/rfc5646</link>&gt;.</note>" >
<!ENTITY rfc5763 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5763'>RFC 5763</link></span> <note>RFC 5763: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) &lt;<link url='http://tools.ietf.org/html/rfc5763'>http://tools.ietf.org/html/rfc5763</link>&gt;.</note>" >
<!ENTITY rfc5802 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5802'>RFC 5802</link></span> <note>RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms &lt;<link url='http://tools.ietf.org/html/rfc5802'>http://tools.ietf.org/html/rfc5802</link>&gt;.</note>" >
<!ENTITY rfc5888 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5888'>RFC 5888</link></span> <note>RFC 5888: The Session Description Protocol (SDP) Grouping Framework &lt;<link url='http://tools.ietf.org/html/rfc5888'>http://tools.ietf.org/html/rfc5888</link>&gt;.</note>" >
<!ENTITY rfc5952 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5952'>RFC 5952</link></span> <note>RFC 5952: A Recommendation for IPv6 Address Text Representation &lt;<link url='http://tools.ietf.org/html/rfc5952'>http://tools.ietf.org/html/rfc5952</link>&gt;.</note>" >
<!ENTITY rfc5988 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5988'>RFC 5988</link></span> <note>RFC 5988: Web Linking &lt;<link url='http://tools.ietf.org/html/rfc5988'>http://tools.ietf.org/html/rfc5988</link>&gt;.</note>" >
<!ENTITY rfc6045 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6045'>RFC 6045</link></span> <note>RFC 6045: Real-time Inter-network Defense (RID) &lt;<link url='http://tools.ietf.org/html/rfc6045'>http://tools.ietf.org/html/rfc6045</link>&gt;.</note>" >
<!ENTITY rfc6051 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6051'>RFC 6051</link></span> <note>RFC 6051: Rapid Synchronisation of RTP Flows &lt;<link url='http://tools.ietf.org/html/rfc6051'>http://tools.ietf.org/html/rfc6051</link>&gt;.</note>" >
<!ENTITY rfc6120 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6120'>RFC 6120</link></span> <note>RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/rfc6120'>http://tools.ietf.org/html/rfc6120</link>&gt;.</note>" >
@ -622,6 +625,7 @@ THE SOFTWARE.
<!ENTITY rfc6331 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6331'>RFC 6331</link></span> <note>RFC 6331: Moving DIGEST-MD5 to Historic &lt;<link url='http://tools.ietf.org/html/rfc6331'>http://tools.ietf.org/html/rfc6331</link>&gt;.</note>" >
<!ENTITY rfc6350 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6350'>RFC 6350</link></span> <note>RFC 6350: vCard Format Specification &lt;<link url='http://tools.ietf.org/html/rfc6350'>http://tools.ietf.org/html/rfc6350</link>&gt;.</note>" >
<!ENTITY rfc6351 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6351'>RFC 6351</link></span> <note>RFC 6351: vCard XML Representation &lt;<link url='http://tools.ietf.org/html/rfc6351'>http://tools.ietf.org/html/rfc6351</link>&gt;.</note>" >
<!ENTITY rfc6415 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6415'>RFC 6415</link></span> <note>RFC 6415: Web Host Metadata &lt;<link url='http://tools.ietf.org/html/rfc6415'>http://tools.ietf.org/html/rfc6415</link>&gt;.</note>" >
<!ENTITY rfc6443 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6443'>RFC 6443</link></span> <note>RFC 6443: Framework for Emergency Calling Using Internet Multimedia &lt;<link url='http://tools.ietf.org/html/rfc6443'>http://tools.ietf.org/html/rfc6443</link>&gt;.</note>" >
<!ENTITY rfc6455 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6455'>RFC 6455</link></span> <note>RFC 6455: The WebSocket Protocol &lt;<link url='http://tools.ietf.org/html/rfc6455'>http://tools.ietf.org/html/rfc6455</link>&gt;.</note>" >
<!ENTITY rfc6473 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6473'>RFC 6473</link></span> <note>RFC 6473: vCard KIND:application &lt;<link url='http://tools.ietf.org/html/rfc6473'>http://tools.ietf.org/html/rfc6351</link>&gt;.</note>" >
@ -629,6 +633,8 @@ THE SOFTWARE.
<!ENTITY rfc6716 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6716'>RFC 6716</link></span> <note>RFC 6716: Definition of the Opus Audio Codec &lt;<link url='http://tools.ietf.org/html/rfc6716'>http://tools.ietf.org/html/rfc6716</link>&gt;.</note>" >
<!ENTITY rfc6762 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6762'>RFC 6762</link></span> <note>RFC 6762: Multicast DNS &lt;<link url='http://tools.ietf.org/html/rfc6762'>http://tools.ietf.org/html/rfc6762</link>&gt;.</note>" >
<!ENTITY rfc6763 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6763'>RFC 6763</link></span> <note>RFC 6763: DNS-Based Service Discovery &lt;<link url='http://tools.ietf.org/html/rfc6763'>http://tools.ietf.org/html/rfc6763</link>&gt;.</note>" >
<!ENTITY rfc6920 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6920'>RFC 6920</link></span> <note>RFC 6920: Naming Things with Hashes &lt;<link url='http://tools.ietf.org/html/rfc6920'>http://tools.ietf.org/html/rfc6920</link>&gt;.</note>" >
<!ENTITY rfc7081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7081'>RFC 7081</link></span> <note>RFC 7081: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc7081'>http://tools.ietf.org/html/rfc7081</link>&gt;.</note>" >
<!-- Internet-Drafts -->
@ -664,7 +670,8 @@ THE SOFTWARE.
<!ENTITY stoxcore "<span class='ref'><strong><link url='http://tools.ietf.org/html/draft-ietf-stox-core'>draft-ietf-stox-core</link></strong></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-core'>http://tools.ietf.org/html/draft-ietf-stox-core</link>&gt;.</note>" >
<!ENTITY tcprobust "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure'>Improving TCP's Robustness to Blind In-Window Attacks</link></span> <note>Improving TCP's Robustness to Blind In-Window Attacks &lt;<link url='http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure'>http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure</link>&gt;. Work in progress.</note>" >
<!ENTITY turn "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-behave-turn'>TURN</link></span> <note>Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) &lt;<link url='http://tools.ietf.org/html/draft-ietf-behave-turn'>http://tools.ietf.org/html/draft-ietf-behave-turn</link>&gt;. Work in progress.</note>" >
<!ENTITY xmppoverwebsocket "<span class='ref'><link url='https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/'>XMPP Over WebSocket</link></span> <note>An XMPP Sub-protocol for WebSocket &lt;<link url='https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/'>https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/</link>&gt;. Work in progress.</note>" >
<!ENTITY xmppoverwebsocket "<span class='ref'><link url='https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/'>XMPP Over WebSocket</link></span> <note>An XMPP Sub-protocol for WebSocket &lt;<link url='https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/'>https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/</link>&gt;. Work in progress.</note>" >
<!ENTITY bundle "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/'>Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers</link></span> <note>Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers &lt;<link url='http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/'>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/</link>&gt;. Work in progress.</note>" >
<!-- IANA registries -->
@ -689,11 +696,11 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!ENTITY xmppe2e "<span class='ref'><link url='http://tools.ietf.org/html/rfc3923'>XMPP E2E</link></span> <note>RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc3923'>http://tools.ietf.org/html/rfc3923</link>&gt;.</note>" >
<!ENTITY xmppim "<span class='ref'><link url='http://tools.ietf.org/html/rfc6121'>XMPP IM</link></span> <note>RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://tools.ietf.org/html/rfc6121'>http://tools.ietf.org/html/rfc6121</link>&gt;.</note>" >
<!ENTITY xmppiri "<span class='ref'><link url='http://tools.ietf.org/html/rfc5122'>XMPP URI Scheme</link></span> <note>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>&gt;.</note>" >
<!ENTITY xmppsipchat "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat'>draft-saintandre-sip-xmpp-chat</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat &lt;<link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat'>http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat</link>&gt; (work in progress).</note>" >
<!ENTITY xmppsipcore "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core'>draft-saintandre-sip-xmpp-core</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core'>http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core</link>&gt; (work in progress).</note>" >
<!ENTITY xmppsipim "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im'>draft-saintandre-sip-xmpp-im</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging &lt;<link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im'>http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im</link>&gt; (work in progress).</note>" >
<!ENTITY xmppsipmedia "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media'>draft-saintandre-sip-xmpp-media</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions &lt;<link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media'>http://tools.ietf.org/html/draft-saintandre-sip-xmpp-media</link>&gt; (work in progress).</note>" >
<!ENTITY xmppsippresence "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence'>draft-saintandre-sip-xmpp-presence</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence &lt;<link url='http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence'>http://tools.ietf.org/html/draft-saintandre-sip-xmpp-presence</link>&gt; (work in progress).</note>" >
<!ENTITY stoxchat "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-stox-chat'>draft-ietf-stox-chat</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-chat'>http://tools.ietf.org/html/draft-ietf-stox-chat</link>&gt; (work in progress).</note>" >
<!ENTITY stoxcore "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-stox-core'>draft-ietf-stox-core</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-core'>http://tools.ietf.org/html/draft-ietf-stox-core</link>&gt; (work in progress).</note>" >
<!ENTITY stoxim "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-stox-im'>draft-ietf-stox-im</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-im'>http://tools.ietf.org/html/draft-ietf-stox-im</link>&gt; (work in progress).</note>" >
<!ENTITY stoxmedia "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-stox-media'>draft-ietf-stox-media</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-media'>http://tools.ietf.org/html/draft-ietf-stox-media</link>&gt; (work in progress).</note>" >
<!ENTITY stoxpresence "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-stox-presence'>draft-ietf-stox-presence</link></span> <note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence &lt;<link url='http://tools.ietf.org/html/draft-ietf-stox-presence'>http://tools.ietf.org/html/draft-ietf-stox-presence</link>&gt; (work in progress).</note>" >
<!ENTITY xmppurn "<span class='ref'><link url='http://tools.ietf.org/html/rfc4854'>XMPP URNs</link></span> <note>A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc4854'>http://tools.ietf.org/html/rfc4854</link>&gt;.</note>" >
<!ENTITY xtls "<span class='ref'><link url='http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption'>Jingle XTLS</link></span> <note>Extensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security (&quot;XTLS&quot;) &lt;<link url='http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption'>http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption</link>&gt;.</note>" >
<!ENTITY saslext "<span class='ref'><link url='http://tools.ietf.org/html/draft-meyer-xmpp-sasl-cert-management'>Client Certificate Management for SASL EXTERNAL</link></span> <note>Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/draft-meyer-xmpp-sasl-cert-management'>http://tools.ietf.org/html/draft-meyer-xmpp-sasl-cert-management</link>&gt;.</note>" >
@ -1294,3 +1301,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!ENTITY xep0332 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0332.html'>HTTP Over XMPP Transport (XEP-0332)</link></span> <note>XEP-0332: HTTP Over XMPP Transport &lt;<link url='http://xmpp.org/extensions/xep-0332.html'>http://xmpp.org/extensions/xep-0332.html</link>&gt;.</note>" >
<!ENTITY xep0333 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0333.html'>Chat Markers (XEP-0333)</link></span> <note>XEP-0333: Chat Markers &lt;<link url='http://xmpp.org/extensions/xep-0333.html'>http://xmpp.org/extensions/xep-0333.html</link>&gt;.</note>" >
<!ENTITY xep0334 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0334.html'>Message Processing Hints (XEP-0334)</link></span> <note>XEP-0334: Message Processing Hints &lt;<link url='http://xmpp.org/extensions/xep-0334.html'>http://xmpp.org/extensions/xep-0334.html</link>&gt;.</note>" >
<!ENTITY xep0335 "<span class='ref'><link url='http://xmpp.org/extensions/xep-0335.html'>JSON Containers (XEP-0335)</link></span> <note>XEP-0335: JSON Containers &lt;<link url='http://xmpp.org/extensions/xep-0335.html'>http://xmpp.org/extensions/xep-0335.html</link>&gt;.</note>" >

4
xep.xsl
View File

@ -1035,6 +1035,10 @@ OR OTHER DEALINGS IN THE SOFTWARE.
</span>
</xsl:template>
<xsl:template match='sub'>
<sub><xsl:apply-templates/></sub>
</xsl:template>
<xsl:template match='pre'>
<pre><xsl:apply-templates/></pre>
</xsl:template>

19
xep2texml.xsl
View File

@ -99,8 +99,8 @@
\usepackage{fontspec,xltxtra,xunicode}
\defaultfontfeatures{Mapping=tex-text}
\setromanfont[Ligatures={Common}]{Gentium}
\setsansfont[Scale=MatchLowercase]{Gentium}
\setromanfont[Ligatures={Common}]{Gentium Basic}
\setsansfont[Scale=MatchLowercase]{Gentium Basic}
\setmonofont[Scale=MatchLowercase]{Inconsolata}
\setkomafont{descriptionlabel}{\normalfont\bfseries}
@ -306,6 +306,21 @@
<cmd name="footnote"><parm><xsl:apply-templates/></parm></cmd>
</xsl:template>
<!-- em -->
<xsl:template match="em">
<cmd name="emph"><parm><xsl:apply-templates/></parm></cmd>
</xsl:template>
<!-- strong -->
<xsl:template match="strong">
<cmd name="textbf"><parm><xsl:apply-templates/></parm></cmd>
</xsl:template>
<!-- sub -->
<xsl:template match="sub">
<math><cmd name="textsuperscript"><parm><xsl:apply-templates/></parm></cmd></math>
</xsl:template>
<!-- span[@class='super'] -->
<xsl:template match="span[@class='super']">
<math><spec cat="sup"/><spec cat="bg"/><xsl:apply-templates/><spec cat="eg"/></math>