moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Remove trailing whitespace from all XML files.

This commit is contained in:
Emmanuel Gil Peyrot 2017-08-02 20:49:11 +01:00 committed by Sam Whited
parent 901ccc83de
commit e8d49ee6ed
45 changed files with 1128 additions and 1128 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
inbox/bidi.xml
View File

@ -81,13 +81,13 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<section1 topic='Examples' anchor='examples'> <section1 topic='Examples' anchor='examples'>
<p>This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback. </p> <p>This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback. </p>
<example caption='Bidirectional Streams with SASL Authentication'><![CDATA[ <example caption='Bidirectional Streams with SASL Authentication'><![CDATA[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit' to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'> xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18' id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'> from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features> S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -95,13 +95,13 @@ S: <stream:features>
</stream:features> </stream:features>
C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit' to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'> xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a' id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'> from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features> S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
@ -113,31 +113,31 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>
Y2FwdWxldC5saXQ=</auth> Y2FwdWxldC5saXQ=</auth>
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit' to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'> xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a' id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'> from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features/> S: <stream:features/>
<!-- At this point, S is allowed to send C stanzas from capulet.lit <!-- At this point, S is allowed to send C stanzas from capulet.lit
since that is the value of 'to' in the stream open sent by C above. since that is the value of 'to' in the stream open sent by C above.
--> -->
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get' C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq> id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result' S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq> id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
]]></example> ]]></example>
<example caption='Bidirectional Streams with Server Dialback'><![CDATA[ <example caption='Bidirectional Streams with Server Dialback'><![CDATA[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit' to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'> xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18' id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'> from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features> S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -145,13 +145,13 @@ S: <stream:features>
</stream:features> </stream:features>
C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams' C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback' xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit' to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'> xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback' S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a' id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'> from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features> S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
@ -164,13 +164,13 @@ C: <bidi xmlns='urn:xmpp:bidi'/>
<!-- At this point S may send from capulet.lit. <!-- At this point S may send from capulet.lit.
--> -->
S: <db:result from='montague.lit' to='capulet.lit' type='valid'/> S: <db:result from='montague.lit' to='capulet.lit' type='valid'/>
C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get' C: <iq from='juliet@capulet.lit/balcony' to='montague.lit' type='get'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq> id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result' S: <iq from='montague.lit' to='juliet@capulet.lit/balcony' type='result'
id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq> id='8dfc70af'><query xmlns='urn:xmpp:ping'/></iq>
S: <db:result from='conference.montague.lit' to='capulet.lit'> S: <db:result from='conference.montague.lit' to='capulet.lit'>
1bac3ef56fed987cfe098c9785c654a5476ed765</db:result> 1bac3ef56fed987cfe098c9785c654a5476ed765</db:result>
<!-- The above is also legal - S attempts to authenticate as <!-- The above is also legal - S attempts to authenticate as
a different domain as well, presumably a MUC domain a different domain as well, presumably a MUC domain
--> -->
C: <db:result from='capulet.lit' to='conference.montague.lit' type='valid'/> C: <db:result from='capulet.lit' to='conference.montague.lit' type='valid'/>

78
inbox/buddycloud-channels.xml
View File

@ -128,7 +128,7 @@
</section2> </section2>
<section2 topic="Buddycloud Channels" anchor="Buddycloud Channels"> <section2 topic="Buddycloud Channels" anchor="Buddycloud Channels">
<p> <p>
Buddycloud channels are a bundle of <cite>XEP-0060</cite> publish-subscribe nodes with Buddycloud channels are a bundle of <cite>XEP-0060</cite> publish-subscribe nodes with
identical subscribers and permissions presented as a JID-like identical subscribers and permissions presented as a JID-like
name (example: name (example:
<link url="buddycloud:juliet@capulit.lit">juliet@capulet.lit</link> <link url="buddycloud:juliet@capulit.lit">juliet@capulet.lit</link>
@ -232,7 +232,7 @@
]]> ]]>
</example> </example>
<p>The entity then iterates through the &lt;item/&gt; elements, sending an <p>The entity then iterates through the &lt;item/&gt; elements, sending an
info discovery request to each JID. info discovery request to each JID.
</p> </p>
<example caption="The Entity sends a disco#info request to each component"> <example caption="The Entity sends a disco#info request to each component">
<![CDATA[ <![CDATA[
@ -280,7 +280,7 @@
</section2> </section2>
</section1> </section1>
<section1 topic="Register" anchor="register" xml:base="sections/40.register.xml"> <section1 topic="Register" anchor="register" xml:base="sections/40.register.xml">
<p>Upon connection to the buddycloud server a user should send a register <p>Upon connection to the buddycloud server a user should send a register
stanza.</p> stanza.</p>
<example caption="The Entity sends a register request to the domain"> <example caption="The Entity sends a register request to the domain">
@ -294,11 +294,11 @@
]]> ]]>
</example> </example>
<p>The register request creates the user's personal channels on first use <p>The register request creates the user's personal channels on first use
and has the additional benefit of creating additional new channel nodes and has the additional benefit of creating additional new channel nodes
as they become available on the server (e.g. 'status' node, 'geoloc' nodes). as they become available on the server (e.g. 'status' node, 'geoloc' nodes).
</p> </p>
</section1> </section1>
<section1 topic="Channel and Node Configuration" anchor="channel-config" xml:base="sections/50.node-config.xml"> <section1 topic="Channel and Node Configuration" anchor="channel-config" xml:base="sections/50.node-config.xml">
<p>Node metadata is used to describe the channel to users. All nodes in a <p>Node metadata is used to describe the channel to users. All nodes in a
@ -767,32 +767,32 @@
<p>Many of the item use cases follow those from <cite>XEP-0060</cite>. This section notes <p>Many of the item use cases follow those from <cite>XEP-0060</cite>. This section notes
the departures from the parent XEP and specific requirements. the departures from the parent XEP and specific requirements.
</p> </p>
<section2 topic="Retrieving items" anchor="items-retrieve"> <section2 topic="Retrieving items" anchor="items-retrieve">
<section3 topic="Recent Items" anchor="items-recent"> <section3 topic="Recent Items" anchor="items-recent">
<p>It is possible to retrieve any new items since last retrieval from all subscribed channels ('<em>/posts</em>' nodes specifically) since last retrieval using the <strong>recent items</strong> functionality. <p>It is possible to retrieve any new items since last retrieval from all subscribed channels ('<em>/posts</em>' nodes specifically) since last retrieval using the <strong>recent items</strong> functionality.
</p> </p>
<example caption="Recent items query"> <example caption="Recent items query">
<![CDATA[ <![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1"> <iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub"> <pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1" <recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z" since="2014-04-18T10:46.100Z"
max="50" max="50"
parent-only="true" /> parent-only="true" />
</pubsub> </pubsub>
</iq> </iq>
]]> ]]>
</example> </example>
<example caption="Recent items reply"> <example caption="Recent items reply">
<![CDATA[ <![CDATA[
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1"> <iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub"> <pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/romeo@montague.lit/posts"> <items node="/user/romeo@montague.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,16584564008760001"> <item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,16584564008760001">
...atom payload... ...atom payload...
@ -811,16 +811,16 @@
...atom payload... ...atom payload...
</item> </item>
</items> </items>
</pubsub> </pubsub>
</iq> </iq>
]]> ]]>
</example> </example>
<p>In this example <em>max</em> represents the maximum number of items the user wishes to retrieve <p>In this example <em>max</em> represents the maximum number of items the user wishes to retrieve
from any one channel, <em>since</em> is the datetime from which posts should start, and from any one channel, <em>since</em> is the datetime from which posts should start, and
<em>parent-only</em> allows users to requests posts which only start a discussion <em>parent-only</em> allows users to requests posts which only start a discussion
(i.e. no reply posts).</p> (i.e. no reply posts).</p>
<section4 topic="Error Cases" anchor="items-recent-errorcases"> <section4 topic="Error Cases" anchor="items-recent-errorcases">
<p>The following extended error cases are used: <p>The following extended error cases are used:
</p> </p>
@ -843,19 +843,19 @@
</li> </li>
</ul> </ul>
</section4> </section4>
</section3> </section3>
</section2> </section2>
<section2 topic="Deleting items" anchor="items-delete"> <section2 topic="Deleting items" anchor="items-delete">
<example caption="The client sends"> <example caption="The client sends">
<![CDATA[ <![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32"> <iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub"> <pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1"> <retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/> <item id="1291048772456"/>
</retract> </retract>
</pubsub> </pubsub>
</iq> </iq>
]]> ]]>
</example> </example>
@ -868,10 +868,10 @@
replace the deleted post replace the deleted post
<example caption="The Buddycloud server sends retractions out to online clients"> <example caption="The Buddycloud server sends retractions out to online clients">
<![CDATA[ <![CDATA[
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit"> <message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event"> <event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts"> <items node="/user/channeluser@example.com/posts">
<retract id="1291048772456"/> <retract id="1291048772456"/>
<item id="1291048772456"> <item id="1291048772456">
<deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0" ref="xmpp:buddycloud.capulet.lit?pubsub;action=retrieve;node=/user/juliet@capulet.lit/posts;item=1291048772456" when="2012-07-01T15:08:32.950Z"> <deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0" ref="xmpp:buddycloud.capulet.lit?pubsub;action=retrieve;node=/user/juliet@capulet.lit/posts;item=1291048772456" when="2012-07-01T15:08:32.950Z">
<updated>2012-07-01T15:08:32.950Z</updated> <updated>2012-07-01T15:08:32.950Z</updated>
@ -884,8 +884,8 @@
<verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb> <verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb>
</deleted-entry> </deleted-entry>
</item> </item>
</items> </items>
</event> </event>
</message> </message>
]]> ]]>
</example> </example>
@ -1209,7 +1209,7 @@
<p> <p>
The Buddycloud server should make sure that the remote server The Buddycloud server should make sure that the remote server
component is the authoritative Buddycloud server for the domain it component is the authoritative Buddycloud server for the domain it
claims to represent. This is done by running the server discovery <!-- claims to represent. This is done by running the server discovery <!--
how do we reference a section in this document? --> how do we reference a section in this document? -->
process and confirming the same XMPP component name. process and confirming the same XMPP component name.
</p> </p>

84
inbox/calendaring.xml
View File

@ -15,17 +15,17 @@
<!ENTITY ITEM "&lt;item/&gt;"> <!ENTITY ITEM "&lt;item/&gt;">
<!ENTITY ITEMS "&lt;items/&gt;"> <!ENTITY ITEMS "&lt;items/&gt;">
<!ENTITY PUBSUB "&lt;pubsub/&gt;"> <!ENTITY PUBSUB "&lt;pubsub/&gt;">
<!ENTITY VEVENT "&lt;vevent/&gt;"> <!ENTITY VEVENT "&lt;vevent/&gt;">
<!ENTITY VTODO "&lt;vtodo/&gt;"> <!ENTITY VTODO "&lt;vtodo/&gt;">
<!ENTITY VJOURNAL "&lt;vjournal/&gt;"> <!ENTITY VJOURNAL "&lt;vjournal/&gt;">
<!ENTITY VFREEBUSY "&lt;vfreebusy/&gt;"> <!ENTITY VFREEBUSY "&lt;vfreebusy/&gt;">
<!ENTITY VALARM "&lt;valarm/&gt;"> <!ENTITY VALARM "&lt;valarm/&gt;">
<!ENTITY VTIMEZONE "&lt;vtimezone/&gt;"> <!ENTITY VTIMEZONE "&lt;vtimezone/&gt;">
<!ENTITY SN "calendar"> <!ENTITY SN "calendar">
<!ENTITY NS "urn:xmpp:tmp:&SN;:0"> <!ENTITY NS "urn:xmpp:tmp:&SN;:0">
<!ENTITY TODO "## TODO. ##"> <!ENTITY TODO "## TODO. ##">
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
@ -99,7 +99,7 @@
<p>This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by <cite>iTIP</cite>. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by <cite>CalDAV</cite>. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.</p> <p>This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by <cite>iTIP</cite>. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by <cite>CalDAV</cite>. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.</p>
<p>The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel <cite>iCalendar</cite>-based calendar components, as well as search for busy time information. The protocol is a superset of <cite>Publish-Subscribe</cite> and will gracefully degrade to <cite>Publish-Subscribe</cite> for clients that do not support the calendaring extensions defined.</p> <p>The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel <cite>iCalendar</cite>-based calendar components, as well as search for busy time information. The protocol is a superset of <cite>Publish-Subscribe</cite> and will gracefully degrade to <cite>Publish-Subscribe</cite> for clients that do not support the calendaring extensions defined.</p>
</section2> </section2>
<!-- == How It Works ===================================================== --> <!-- == How It Works ===================================================== -->
<section2 topic='How It Works' anchor='intro-howitworks'> <section2 topic='How It Works' anchor='intro-howitworks'>
@ -135,7 +135,7 @@ END:VCALENDAR
]]></example> ]]></example>
<p>This specification is structured as follows: <link url='#disco'>Discovering Support</link> describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in <link url='#create'>Creating Calendars</link>. The section on <link url='#publish'>Scheduling Calendar Entries</link> provides the transport specific information necessary to convey <cite>iTIP</cite> messages over <cite>Publish-Subscribe</cite> which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections <link url='#retrieve'>Retrieving Calendar Entries</link> and <link url='#freebusy'>Retrieving Free/Busy Time</link> define how to retrieve items from a calendar node, and how to search for busy time information. <link url='#alarm'>Alarm Notifications</link> provide a mechanism for setting up and subscribing to alarm notifications.</p> <p>This specification is structured as follows: <link url='#disco'>Discovering Support</link> describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in <link url='#create'>Creating Calendars</link>. The section on <link url='#publish'>Scheduling Calendar Entries</link> provides the transport specific information necessary to convey <cite>iTIP</cite> messages over <cite>Publish-Subscribe</cite> which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections <link url='#retrieve'>Retrieving Calendar Entries</link> and <link url='#freebusy'>Retrieving Free/Busy Time</link> define how to retrieve items from a calendar node, and how to search for busy time information. <link url='#alarm'>Alarm Notifications</link> provide a mechanism for setting up and subscribing to alarm notifications.</p>
</section2> </section2>
<!-- == Formatting Conventions =========================================== --> <!-- == Formatting Conventions =========================================== -->
<section2 topic='Formatting Conventions' anchor='intro-conventions'> <section2 topic='Formatting Conventions' anchor='intro-conventions'>
@ -145,7 +145,7 @@ END:VCALENDAR
<p>Calendar components defined by <cite>RFC 2445</cite> are referred to with capitalized text. All calendar components start with the letter "V". For example, VEVENT refers to the event calendar component, VTODO refers to the to-do calendar component and VJOURNAL refers to the daily journal calendar component.</p> <p>Calendar components defined by <cite>RFC 2445</cite> are referred to with capitalized text. All calendar components start with the letter "V". For example, VEVENT refers to the event calendar component, VTODO refers to the to-do calendar component and VJOURNAL refers to the daily journal calendar component.</p>
<p>Properties defined by <cite>RFC 2445</cite> are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Values are referred to with quoted-strings of text, either alone or followed by the word "value".</p> <p>Properties defined by <cite>RFC 2445</cite> are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Values are referred to with quoted-strings of text, either alone or followed by the word "value".</p>
</section2> </section2>
<!-- == Related Documents ================================================ --> <!-- == Related Documents ================================================ -->
<section2 topic='Related Documents' anchor='intro-related'> <section2 topic='Related Documents' anchor='intro-related'>
@ -169,7 +169,7 @@ END:VCALENDAR
<p>This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model.</p> <p>This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model.</p>
<p>As a brief overview, a calendar is modeled as a publish-subscribe node with a defined structure; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".</p> <p>As a brief overview, a calendar is modeled as a publish-subscribe node with a defined structure; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".</p>
--> -->
<!-- == Calendar Service ================================================= --> <!-- == Calendar Service ================================================= -->
<section2 topic='Calendar Service' anchor='datamodel-service'> <section2 topic='Calendar Service' anchor='datamodel-service'>
@ -178,7 +178,7 @@ END:VCALENDAR
<p>A publish-subscribe service can advertise itself as a calendar service if it supports the functionality defined in this specification at any of its nodes. That might mean that calendar nodes are spread throughout the service and mixed with non-calendar nodes. Calendaring features are only required in the nodes that are calendar nodes.</p> <p>A publish-subscribe service can advertise itself as a calendar service if it supports the functionality defined in this specification at any of its nodes. That might mean that calendar nodes are spread throughout the service and mixed with non-calendar nodes. Calendaring features are only required in the nodes that are calendar nodes.</p>
<p>The calendar service is the canonical location for calendar data and state information. Entities may submit requests to change data or download data. Entities may store calendar objects offline and attempt to synchronize at a later time. However, entities MUST be prepared for calendar data on the service to change between the time of last synchronization and when attempting an update, as calendar nodes may be shared and accessed by multiple entities.</p> <p>The calendar service is the canonical location for calendar data and state information. Entities may submit requests to change data or download data. Entities may store calendar objects offline and attempt to synchronize at a later time. However, entities MUST be prepared for calendar data on the service to change between the time of last synchronization and when attempting an update, as calendar nodes may be shared and accessed by multiple entities.</p>
</section2> </section2>
<!-- == Calendar Nodes =================================================== --> <!-- == Calendar Nodes =================================================== -->
<section2 topic='Calendar Nodes' anchor='datamodel-nodes'> <section2 topic='Calendar Nodes' anchor='datamodel-nodes'>
@ -186,7 +186,7 @@ END:VCALENDAR
<p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe &lt;create/&gt; request (see section <link url='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn&apos;t define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.</p> <p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe &lt;create/&gt; request (see section <link url='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn&apos;t define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.</p>
<p>Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.</p> <p>Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.</p>
</section2> </section2>
<!-- == Calendar Items =================================================== --> <!-- == Calendar Items =================================================== -->
<section2 topic='Calendar Items' anchor='datamodel-items'> <section2 topic='Calendar Items' anchor='datamodel-items'>
@ -265,7 +265,7 @@ END:VCALENDAR
--> -->
<p>&TODO;</p> <p>&TODO;</p>
</section2> </section2>
<!-- == Calendar Entry State ============================================= --> <!-- == Calendar Entry State ============================================= -->
<section2 topic='Calendar Entry State' anchor='entrystate'> <section2 topic='Calendar Entry State' anchor='entrystate'>
@ -273,7 +273,7 @@ END:VCALENDAR
<p>The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.</p> <p>The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.</p>
<p>The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value.</p> <p>The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value.</p>
</section2> </section2>
<!-- == Calendar Item Revisions ========================================== --> <!-- == Calendar Item Revisions ========================================== -->
<section2 topic='Calendar Item Revisions' anchor='itemrevisions'> <section2 topic='Calendar Item Revisions' anchor='itemrevisions'>
@ -284,9 +284,9 @@ END:VCALENDAR
<li>The "SEQUENCE" property value MUST NOT be incremented when an "Attendee" modifies the "ATTENDEE" property "partstat" parameter, when an "Attendee" submits a counter proposal to negotiate a change in a calendar item, or when an "Attendee" grants another CU (or several CUs) the right to attend on their behalf.</li> <li>The "SEQUENCE" property value MUST NOT be incremented when an "Attendee" modifies the "ATTENDEE" property "partstat" parameter, when an "Attendee" submits a counter proposal to negotiate a change in a calendar item, or when an "Attendee" grants another CU (or several CUs) the right to attend on their behalf.</li>
<li>The "SEQUENCE" property value MUST NOT be incremented when retrieving calendar objects from a calendar node or sending pubsub notifications to subscribers.</li> <li>The "SEQUENCE" property value MUST NOT be incremented when retrieving calendar objects from a calendar node or sending pubsub notifications to subscribers.</li>
</ul> </ul>
<p>The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.</p> <p>The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.</p>
</section2> </section2>
<!-- == Request Sequencing =============================================== --> <!-- == Request Sequencing =============================================== -->
<section2 topic='Request Sequencing' anchor='requestsequencing'> <section2 topic='Request Sequencing' anchor='requestsequencing'>
@ -300,9 +300,9 @@ END:VCALENDAR
======================================================================= --> ======================================================================= -->
<section1 topic='Discovering Support' anchor='disco'> <section1 topic='Discovering Support' anchor='disco'>
<!-- == Service Features ================================================= --> <!-- == Service Features ================================================= -->
<section2 topic='Service Features' anchor='disco-service'> <section2 topic='Service Features' anchor='disco-service'>
<p>A calendar service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a calendar service MUST indicate the identity of a pubsub service and indicate which pubsub features are supported. A calendar service supporting the features described in this specification MUST also include "&NS;" as a feature in the "disco#info" result. A feature of "&NS;" &VNOTE; in the result MUST indicate that the service supports all MUST level requirements in this specification.</p> <p>A calendar service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a calendar service MUST indicate the identity of a pubsub service and indicate which pubsub features are supported. A calendar service supporting the features described in this specification MUST also include "&NS;" as a feature in the "disco#info" result. A feature of "&NS;" &VNOTE; in the result MUST indicate that the service supports all MUST level requirements in this specification.</p>
<example caption='Entity queries calendar service regarding supported features'><![CDATA[ <example caption='Entity queries calendar service regarding supported features'><![CDATA[
@ -327,9 +327,9 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Node Information ================================================= --> <!-- == Node Information ================================================= -->
<section2 topic='Node Information' anchor='disco-node'> <section2 topic='Node Information' anchor='disco-node'>
<p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p> <p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p>
<example caption='Entity queries a node for information'><![CDATA[ <example caption='Entity queries a node for information'><![CDATA[
@ -437,7 +437,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Success Case ===================================================== --> <!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='create-success'> <section2 topic='Success Case' anchor='create-success'>
@ -459,7 +459,7 @@ END:VCALENDAR
<li>The requesting entity does not have sufficient privileges to create calendar nodes.</li> <li>The requesting entity does not have sufficient privileges to create calendar nodes.</li>
</ol> </ol>
<p>These error cases are described more fully in the following sections.</p> <p>These error cases are described more fully in the following sections.</p>
<section3 topic='Calendar Node Creation Not Supported' anchor='create-error-notallowed'> <section3 topic='Calendar Node Creation Not Supported' anchor='create-error-notallowed'>
<p>If the calendar service does not allow new calendar nodes to be created, it MUST respond with a &notallowed; error.</p> <p>If the calendar service does not allow new calendar nodes to be created, it MUST respond with a &notallowed; error.</p>
<example caption='Service does not allow creation of calendar nodes'><![CDATA[ <example caption='Service does not allow creation of calendar nodes'><![CDATA[
@ -476,7 +476,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Insufficient Privileges' anchor='create-error-forbidden'> <section3 topic='Insufficient Privileges' anchor='create-error-forbidden'>
<p>If the requesting entity has insufficient privileges to create new calendar nodes, the service MUST respond with a &forbidden; error.</p> <p>If the requesting entity has insufficient privileges to create new calendar nodes, the service MUST respond with a &forbidden; error.</p>
<example caption='Requesting entity has insufficient privileges to create calendar nodes'><![CDATA[ <example caption='Requesting entity has insufficient privileges to create calendar nodes'><![CDATA[
@ -628,7 +628,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Success Case ===================================================== --> <!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='publish-success'> <section2 topic='Success Case' anchor='publish-success'>
@ -642,7 +642,7 @@ END:VCALENDAR
<p class='box'>Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST proceed as described in <cite>RFC 2446</cite> for the calendaring-specific method used. This usually means that the service MUST overwrite the old calendar entry with a modified entry and then proceed as follows.</p> <p class='box'>Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST proceed as described in <cite>RFC 2446</cite> for the calendaring-specific method used. This usually means that the service MUST overwrite the old calendar entry with a modified entry and then proceed as follows.</p>
<p>The calendar service MUST then send one &MESSAGE; stanza containing a pubsub event notification to each entity that meets the criteria for receiving a notification, as described in section 7.1.2 of <cite>XEP-0060</cite>. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.</p> <p>The calendar service MUST then send one &MESSAGE; stanza containing a pubsub event notification to each entity that meets the criteria for receiving a notification, as described in section 7.1.2 of <cite>XEP-0060</cite>. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.</p>
</section2> </section2>
<!-- == Error Cases ====================================================== --> <!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='publish-error'> <section2 topic='Error Cases' anchor='publish-error'>
@ -654,7 +654,7 @@ END:VCALENDAR
<li>The calendar component submitted in the request does not conform to the configuration.</li> <li>The calendar component submitted in the request does not conform to the configuration.</li>
</ol> </ol>
<p>These error cases are described more fully in the following sections.</p> <p>These error cases are described more fully in the following sections.</p>
<section3 topic='Bad Payload' anchor='publish-error-badpayload'> <section3 topic='Bad Payload' anchor='publish-error-badpayload'>
<p>If the namespace of the root payload element submitted in the request does not match the configured namespace for the node (i.e., the 'urn:ietf:params:xml:ns:xcal' namespace) or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p> <p>If the namespace of the root payload element submitted in the request does not match the configured namespace for the node (i.e., the 'urn:ietf:params:xml:ns:xcal' namespace) or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p>
<example caption='Entity attempts to publish item with invalid payload'><![CDATA[ <example caption='Entity attempts to publish item with invalid payload'><![CDATA[
@ -676,15 +676,15 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic='Unsupported Calendar Component' anchor='publish-error-unsupported'> <section3 topic='Unsupported Calendar Component' anchor='publish-error-unsupported'>
<p>If the calendar component submitted in the request does not contain a type of calendar component that is supported in the calendar node (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;item-forbidden/&gt;.</p> <p>If the calendar component submitted in the request does not contain a type of calendar component that is supported in the calendar node (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;item-forbidden/&gt;.</p>
</section3> </section3>
<section3 topic='Invalid Calendar Item' anchor='publish-error-invalid'> <section3 topic='Invalid Calendar Item' anchor='publish-error-invalid'>
<p>If the calendar component submitted in the request does not obey all restrictions specified in section <link url='#datamodel-items'>Calendar Items</link> (e.g., calendar items MUST NOT contain more than one type of calendar component), in section <link url='#publish-request'>Request</link> (e.g., the request MUST specify an iCalendar "METHOD" property, etc.), and/or those defined for the specified iCalendar method, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p> <p>If the calendar component submitted in the request does not obey all restrictions specified in section <link url='#datamodel-items'>Calendar Items</link> (e.g., calendar items MUST NOT contain more than one type of calendar component), in section <link url='#publish-request'>Request</link> (e.g., the request MUST specify an iCalendar "METHOD" property, etc.), and/or those defined for the specified iCalendar method, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of &lt;invalid-payload/&gt;.</p>
</section3> </section3>
<section3 topic='Request Does Not Match Configuration' anchor='publish-error-forbidden'> <section3 topic='Request Does Not Match Configuration' anchor='publish-error-forbidden'>
<p>If the calendar component submitted in the request does not conform to the configuration of the calendar node where the component will be stored (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:</p> <p>If the calendar component submitted in the request does not conform to the configuration of the calendar node where the component will be stored (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:</p>
<ul> <ul>
@ -737,7 +737,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Success Case ===================================================== --> <!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='retrieve-success'> <section2 topic='Success Case' anchor='retrieve-success'>
@ -763,7 +763,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Error Cases ====================================================== --> <!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='retrieve-error'> <section2 topic='Error Cases' anchor='retrieve-error'>
@ -779,11 +779,11 @@ END:VCALENDAR
<section3 topic='Invalid Filter' anchor='retrieve-error-invalid'> <section3 topic='Invalid Filter' anchor='retrieve-error-invalid'>
<p>If the &lt;filter/&gt; element does not conform to the syntax of the 'urn:ietf:params:xml:ns:caldav' namespace, the service MUST respond with a &badrequest; error. For instance, a &lt;filter/&gt; cannot nest a &lt;comp name='VEVENT'/&gt; element in a &lt;comp name='VTODO'/&gt; element, and a &lt;filter/&gt; cannot nest a &lt;time-range start='...' end='...'/&gt; element in a &lt;prop name='SUMMARY'/&gt; element.</p> <p>If the &lt;filter/&gt; element does not conform to the syntax of the 'urn:ietf:params:xml:ns:caldav' namespace, the service MUST respond with a &badrequest; error. For instance, a &lt;filter/&gt; cannot nest a &lt;comp name='VEVENT'/&gt; element in a &lt;comp name='VTODO'/&gt; element, and a &lt;filter/&gt; cannot nest a &lt;time-range start='...' end='...'/&gt; element in a &lt;prop name='SUMMARY'/&gt; element.</p>
</section3> </section3>
<section3 topic='Unsupported Filter' anchor='retrieve-error-unsupported'> <section3 topic='Unsupported Filter' anchor='retrieve-error-unsupported'>
<p>If any &lt;comp-filter/&gt;, &lt;prop-filter/&gt;, or &lt;param-filter/&gt; element used in the &lt;filter/&gt; element in the report request makes a reference to components, properties, or parameters for which queries are not supported by the server (i.e., if the &lt;filter/&gt; element attempts to reference an unsupported component, property, or parameter), the service MUST respond with a &badrequest; error.</p> <p>If any &lt;comp-filter/&gt;, &lt;prop-filter/&gt;, or &lt;param-filter/&gt; element used in the &lt;filter/&gt; element in the report request makes a reference to components, properties, or parameters for which queries are not supported by the server (i.e., if the &lt;filter/&gt; element attempts to reference an unsupported component, property, or parameter), the service MUST respond with a &badrequest; error.</p>
</section3> </section3>
<section3 topic='Request Does Not Match Configuration' anchor='retrieve-error-forbidden'> <section3 topic='Request Does Not Match Configuration' anchor='retrieve-error-forbidden'>
<p>If the reporting request does not conform to the configuration of the calendar node being queried (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error<!--, which SHOULD also include a pubsub-specific error condition-->. The following rules apply:</p> <p>If the reporting request does not conform to the configuration of the calendar node being queried (see section <link url='#config'>Calendar Node Configuration</link>), the service MUST respond with a &badrequest; error<!--, which SHOULD also include a pubsub-specific error condition-->. The following rules apply:</p>
<ul> <ul>
@ -791,7 +791,7 @@ END:VCALENDAR
<li>If any XML element specifying a range of time has its start or end DATE or DATE-TIME values greater than the value of the "&SN;#max_date_time" configuration option, the service MUST respond with a &badrequest; error.</li> <li>If any XML element specifying a range of time has its start or end DATE or DATE-TIME values greater than the value of the "&SN;#max_date_time" configuration option, the service MUST respond with a &badrequest; error.</li>
</ul> </ul>
</section3> </section3>
<section3 topic='Unsupported Collation' anchor='retrieve-error-collation'> <section3 topic='Unsupported Collation' anchor='retrieve-error-collation'>
<p>If any XML attribute specifying a collation does not specify a collation supported by the calendar service as described in section 7.5 of <cite>RFC 4791</cite>, the service MUST respond with a &badrequest; error.</p> <p>If any XML attribute specifying a collation does not specify a collation supported by the calendar service as described in section 7.5 of <cite>RFC 4791</cite>, the service MUST respond with a &badrequest; error.</p>
</section3> </section3>
@ -834,7 +834,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Success Case ===================================================== --> <!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='freebusy-success'> <section2 topic='Success Case' anchor='freebusy-success'>
@ -860,7 +860,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Error Cases ====================================================== --> <!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='freebusy-error'> <section2 topic='Error Cases' anchor='freebusy-error'>
@ -919,7 +919,7 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Subscribing to Alarm Notifications =============================== --> <!-- == Subscribing to Alarm Notifications =============================== -->
<section2 topic='Subscribing to Alarm Notifications' anchor='alarm-subscribe'> <section2 topic='Subscribing to Alarm Notifications' anchor='alarm-subscribe'>
@ -946,9 +946,9 @@ END:VCALENDAR
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<!-- == Receiving Alarm Notifications ==================================== --> <!-- == Receiving Alarm Notifications ==================================== -->
<section2 topic='Receiving Alarm Notifications' anchor='alarm-notify'> <section2 topic='Receiving Alarm Notifications' anchor='alarm-notify'>
<p>When an alarm is triggered, the calendar service MUST send one &MESSAGE; stanza containing a alarm notification to each entity that meets the criteria for receiving a alarm notification (typically to each approved subscriber who configured its subscription to have the "calendar#notify_alarm" configuration option set to "true"). Depending on the node configuration, the alarm notification either will or will not contain the payload, as shown below.</p> <p>When an alarm is triggered, the calendar service MUST send one &MESSAGE; stanza containing a alarm notification to each entity that meets the criteria for receiving a alarm notification (typically to each approved subscriber who configured its subscription to have the "calendar#notify_alarm" configuration option set to "true"). Depending on the node configuration, the alarm notification either will or will not contain the payload, as shown below.</p>
<section3 topic='Notification With Payload' anchor='alarm-notify-withpayload'> <section3 topic='Notification With Payload' anchor='alarm-notify-withpayload'>
@ -1002,10 +1002,10 @@ END:VCALENDAR
</section1> </section1>
<section1 topic='Examples' anchor='examples'> <section1 topic='Examples' anchor='examples'>
<section2 topic='Published Event Examples' anchor='examples-event'> <section2 topic='Published Event Examples' anchor='examples-event'>
<p>&TODO;</p> <p>&TODO;</p>
<section3 topic='A Minimal Published Event'></section3> <section3 topic='A Minimal Published Event'></section3>
<section3 topic='Changing A Published Event'></section3> <section3 topic='Changing A Published Event'></section3>
<section3 topic='Canceling A Published Event'></section3> <section3 topic='Canceling A Published Event'></section3>
@ -1019,7 +1019,7 @@ END:VCALENDAR
<section2 topic='Group Event Examples' anchor='examples-groupevent'> <section2 topic='Group Event Examples' anchor='examples-groupevent'>
<p>&TODO;</p> <p>&TODO;</p>
<section3 topic='A Group Event Request'></section3> <section3 topic='A Group Event Request'></section3>
<section3 topic='Reply To A Group Event Request'></section3> <section3 topic='Reply To A Group Event Request'></section3>
<section3 topic='Update An Event'></section3> <section3 topic='Update An Event'></section3>
@ -1037,7 +1037,7 @@ END:VCALENDAR
<section2 topic='Busy Time Examples' anchor='examples-freebusy'> <section2 topic='Busy Time Examples' anchor='examples-freebusy'>
<p>&TODO;</p> <p>&TODO;</p>
<!-- <section3 topic='Request Busy Time'></section3> --> <!-- <section3 topic='Request Busy Time'></section3> -->
<!-- <section3 topic='Reply To A Busy Time Request'></section3> --> <!-- <section3 topic='Reply To A Busy Time Request'></section3> -->
@ -1047,7 +1047,7 @@ END:VCALENDAR
<section2 topic='Recurring Event and Time Zone Examples' anchor='examples-recurringevent'> <section2 topic='Recurring Event and Time Zone Examples' anchor='examples-recurringevent'>
<p>&TODO;</p> <p>&TODO;</p>
<section3 topic='A Recurring Event Spanning Time Zones'></section3> <section3 topic='A Recurring Event Spanning Time Zones'></section3>
<section3 topic='Modify A Recurring Instance'></section3> <section3 topic='Modify A Recurring Instance'></section3>
<section3 topic='Cancel an Instance'></section3> <section3 topic='Cancel an Instance'></section3>
@ -1084,7 +1084,7 @@ END:VCALENDAR
<section2 topic='Journal Examples' anchor='examples-journal'> <section2 topic='Journal Examples' anchor='examples-journal'>
<p>&TODO;</p> <p>&TODO;</p>
</section2> </section2>
<section2 topic='Notification Examples' anchor='examples-notification'> <section2 topic='Notification Examples' anchor='examples-notification'>
<p>&TODO;</p> <p>&TODO;</p>
</section2> </section2>

10
inbox/carbons.xml
View File

@ -66,7 +66,7 @@
<p>This XEP defines an approach for ensuring that all of my devices <p>This XEP defines an approach for ensuring that all of my devices
get both sides of all conversations in order to avoid user get both sides of all conversations in order to avoid user
confusion. As a pleasant side-effect, information about the current confusion. As a pleasant side-effect, information about the current
state of a conversation is shared between all of a user's clients state of a conversation is shared between all of a user's clients
that implement this protocol.</p> that implement this protocol.</p>
</section1> </section1>
@ -110,7 +110,7 @@
<feature var='urn:xmpp:carbons:0'/> <feature var='urn:xmpp:carbons:0'/>
... ...
</query> </query>
</iq>]]></example> </iq>]]></example>
</section2> </section2>
<section2 topic='Enabling Carbons' anchor='enabling'> <section2 topic='Enabling Carbons' anchor='enabling'>
@ -236,7 +236,7 @@
RECOMMENDED. (Note: another XEP might be written to document RECOMMENDED. (Note: another XEP might be written to document
traditional resource locking, if the documentation in &rfc3921bis; traditional resource locking, if the documentation in &rfc3921bis;
is not sufficient.)</p> is not sufficient.)</p>
<p>Also note that &xep0085; recommends sending chat state <p>Also note that &xep0085; recommends sending chat state
notifications as chat type messages, which means that they will be notifications as chat type messages, which means that they will be
subject to Carbon-copying. This is intentional.</p> subject to Carbon-copying. This is intentional.</p>
@ -328,7 +328,7 @@
copied client had terminated the conversation. In order to copied client had terminated the conversation. In order to
prevent unwanted termination of conversations on other resources, prevent unwanted termination of conversations on other resources,
clients SHOULD NOT send <em>gone</em> chat states on logout, but clients SHOULD NOT send <em>gone</em> chat states on logout, but
instead SHOULD count on the unavailable presence to convey the change instead SHOULD count on the unavailable presence to convey the change
in attention.</p> in attention.</p>
<p>Upon receiving an outbound notification of any chat state other <p>Upon receiving an outbound notification of any chat state other
than <em>gone</em>, the copied client MAY conclude that the than <em>gone</em>, the copied client MAY conclude that the
@ -372,7 +372,7 @@
encryption mechanism is adjusted to have knowledge of Carbons.</p> encryption mechanism is adjusted to have knowledge of Carbons.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'> <section1 topic='XMPP Registrar Considerations' anchor='reg'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

12
inbox/client-state-notification.xml
View File

@ -49,10 +49,10 @@
<p>Juliet has an XMPP client on her phone, which is available to receive messages. However most of the time <p>Juliet has an XMPP client on her phone, which is available to receive messages. However most of the time
Juliet has her phone screen turned off and is not interested in the status of her contacts unless they are Juliet has her phone screen turned off and is not interested in the status of her contacts unless they are
communicating with her.</p> communicating with her.</p>
<p>Juliet's client informs the server when Juliet is not interacting with it. The server uses this information to <p>Juliet's client informs the server when Juliet is not interacting with it. The server uses this information to
suppress or reduce stanzas that are unimportant, such as status updates.</p> suppress or reduce stanzas that are unimportant, such as status updates.</p>
<p>When Juliet returns to her IM client, the client again informs the server, this time to report that it is active <p>When Juliet returns to her IM client, the client again informs the server, this time to report that it is active
again. The server then disables its traffic optimisations and restores the stream to its normal state.</p> again. The server then disables its traffic optimisations and restores the stream to its normal state.</p>
</section2> </section2>
@ -90,12 +90,12 @@
<example caption='Client indicates it is inactive'><![CDATA[ <example caption='Client indicates it is inactive'><![CDATA[
<inactive xmlns='urn:xmpp:csi'/> <inactive xmlns='urn:xmpp:csi'/>
]]></example> ]]></example>
<p>As might be anticipated, when the client is active again it sends an &lt;active/&gt; element:</p> <p>As might be anticipated, when the client is active again it sends an &lt;active/&gt; element:</p>
<example caption='Client indicates it is active'><![CDATA[ <example caption='Client indicates it is active'><![CDATA[
<active xmlns='urn:xmpp:csi'/> <active xmlns='urn:xmpp:csi'/>
]]></example> ]]></example>
<p>There is no reply from the server to either of these elements (though they may indirectly cause the server to <p>There is no reply from the server to either of these elements (though they may indirectly cause the server to
send stanzas, e.g. to update presence information when the client becomes active after a period of inactivity).</p> send stanzas, e.g. to update presence information when the client becomes active after a period of inactivity).</p>
</section2> </section2>
@ -103,10 +103,10 @@
<section1 topic='Business Rules' anchor='rules'> <section1 topic='Business Rules' anchor='rules'>
<p>As this protocol is for indication only, clients MUST NOT make assumptions about how the server <p>As this protocol is for indication only, clients MUST NOT make assumptions about how the server
will use the active/inactive state information.</p> will use the active/inactive state information.</p>
<p>The server MUST assume all clients to be in the 'active' state until the client indicates otherwise. Also the <p>The server MUST assume all clients to be in the 'active' state until the client indicates otherwise. Also the
CSI active/inactive state is unrelated to the user's presence, the server MUST treat the two independently.</p> CSI active/inactive state is unrelated to the user's presence, the server MUST treat the two independently.</p>
<p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of <p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of
the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the
fully standard behaviour of XMPP is required.</p> fully standard behaviour of XMPP is required.</p>

24
inbox/content-types.xml
View File

@ -4,9 +4,9 @@
%ents; %ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!-- <!--
© XMPP Standards Foundation, 2016 © XMPP Standards Foundation, 2016
Author: Peter Waher Author: Peter Waher
--> -->
<xep> <xep>
<header> <header>
@ -57,7 +57,7 @@ Author: Peter Waher
</p> </p>
<example caption='Hinting at a content type'> <example caption='Hinting at a content type'>
<![CDATA[ <![CDATA[
<message <message
from='person1@example.org/34892374' from='person1@example.org/34892374'
to='person2@example.org/938089023' to='person2@example.org/938089023'
type='chat'> type='chat'>
@ -76,7 +76,7 @@ Author: Peter Waher
</p> </p>
<example caption='Alternate encoding'> <example caption='Alternate encoding'>
<![CDATA[ <![CDATA[
<message <message
from='person1@example.org/34892374' from='person1@example.org/34892374'
to='person2@example.org/938089023' to='person2@example.org/938089023'
type='chat'> type='chat'>
@ -96,7 +96,7 @@ Author: Peter Waher
</p> </p>
<example caption='Alternate encodings'> <example caption='Alternate encodings'>
<![CDATA[ <![CDATA[
<message <message
from='person1@example.org/34892374' from='person1@example.org/34892374'
to='person2@example.org/938089023' to='person2@example.org/938089023'
type='chat'> type='chat'>
@ -156,20 +156,20 @@ Author: Peter Waher
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Content Types' anchor='contentTypes'> <section2 topic='Content Types' anchor='contentTypes'>
<p> <p>
This document does not specify how content types are to be interpreted, or if content types are valid or well defined. This document does not specify how content types are to be interpreted, or if content types are valid or well defined.
It does not specify which content types are to be understood, or when. It only provides a means to hint or include different It does not specify which content types are to be understood, or when. It only provides a means to hint or include different
encodings in the same message. encodings in the same message.
</p> </p>
</section2> </section2>
<section2 topic='Custom Content Types' anchor='customTypes'> <section2 topic='Custom Content Types' anchor='customTypes'>
<p> <p>
It is possible to use custom or vendor-specific content types. These types are marked by prefixing the subtype with It is possible to use custom or vendor-specific content types. These types are marked by prefixing the subtype with
<strong>x.</strong> for custom unregistered types, and with <strong>vnd.</strong> for registered vendor specific types. <strong>x.</strong> for custom unregistered types, and with <strong>vnd.</strong> for registered vendor specific types.
</p> </p>
</section2> </section2>
<section2 topic='Stanza size' anchor='stanzaSize'> <section2 topic='Stanza size' anchor='stanzaSize'>
<p> <p>
Care has to be taken when sending multiple encodings of the same message, as to not reach the smallest allowed Care has to be taken when sending multiple encodings of the same message, as to not reach the smallest allowed
maximum stanza size used by client and server software. maximum stanza size used by client and server software.
</p> </p>
</section2> </section2>
@ -186,9 +186,9 @@ Author: Peter Waher
<code> <code>
<![CDATA[ <![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- <!--
© XMPP Standards Foundation, 2016 © XMPP Standards Foundation, 2016
Author: Peter Waher Author: Peter Waher
--> -->
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'

2
inbox/decloak.xml
View File

@ -167,7 +167,7 @@
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
<p>To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:</p> <p>To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:</p>
<ol> <ol>
<li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li> <li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li>
<li><p>Set up of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to delay call setup). As a result, it may be advantageous to have a way to configure unconditional decloaking in certain deployments, at least within the same trust domain.</p></li> <li><p>Set up of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to delay call setup). As a result, it may be advantageous to have a way to configure unconditional decloaking in certain deployments, at least within the same trust domain.</p></li>

8
inbox/distributedmuc.xml
View File

@ -322,7 +322,7 @@
</x> </x>
</presence> </presence>
]]></example> ]]></example>
<p>The source then delivers that presence stanza to its local users. (Note: The shadow needs to send only one presence stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p> <p>The source then delivers that presence stanza to its local users. (Note: The shadow needs to send only one presence stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
</section2> </section2>
<section2 topic='Sending a Message' anchor='send'> <section2 topic='Sending a Message' anchor='send'>
<p>When a user sends a message to an instance, the instance sends the message to its local occupants and to other instances.</p> <p>When a user sends a message to an instance, the instance sends the message to its local occupants and to other instances.</p>
@ -349,7 +349,7 @@
<body>Message 4.</body> <body>Message 4.</body>
</message> </message>
]]></example> ]]></example>
<p>The source then delivers that message stanza to its local users. (Note: The shadow needs to send only one message stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p> <p>The source then delivers that message stanza to its local users. (Note: The shadow needs to send only one message stanza to the source, thus reducing the number of stanzas sent over the server-to-server link between the peerhost and the firsthost.)</p>
</section2> </section2>
<section2 topic='sync' anchor='Re-Syncing after Connectivity Loss'> <section2 topic='sync' anchor='Re-Syncing after Connectivity Loss'>
<p>To follow.</p> <p>To follow.</p>
@ -365,11 +365,11 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'> <section1 topic='XMPP Registrar Considerations' anchor='reg'>
<p>This document requires no interaction with the &REGISTRAR;.</p> <p>This document requires no interaction with the &REGISTRAR;.</p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>

34
inbox/dmuc3.xml
View File

@ -51,7 +51,7 @@
<p> <p>
MUC uses lots of bandwidth. Sometimes the network link that S2S traffic is carried on is heavily constrained. This protocol reduces the amount of traffic going across S2S through local mirrors of remote MUC rooms. MUC uses lots of bandwidth. Sometimes the network link that S2S traffic is carried on is heavily constrained. This protocol reduces the amount of traffic going across S2S through local mirrors of remote MUC rooms.
It needs no bandwidth for remote rooms without local occupants. It needs no bandwidth for remote rooms without local occupants.
</p> </p>
</section2> </section2>
<section2 topic='Requirements' anchor='reqs'> <section2 topic='Requirements' anchor='reqs'>
<p>The following is a list of goals for the design of this extension: <p>The following is a list of goals for the design of this extension:
@ -153,7 +153,7 @@ To determine if a server or service supports Distributed MUC, the requesting ent
</presence> </presence>
]]></example> ]]></example>
<p>chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it, <p>chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it,
and performs the usual ACL checks as if wayne@tridsys.com/TransVerse had joined directly, and performs the usual ACL checks as if wayne@tridsys.com/TransVerse had joined directly,
sending presence to all occupants. The master MUC will be able to take advantage of the fact that the sending presence to all occupants. The master MUC will be able to take advantage of the fact that the
rosters are being maintained by the distributed MUC services and send one presence with no rosters are being maintained by the distributed MUC services and send one presence with no
@ -191,13 +191,13 @@ will contain information like if the room is moderated, how much history, who is
id='roster1' id='roster1'
type='set'> type='set'>
<roster xmlns='urn:xmpp:dmuc:0'> <roster xmlns='urn:xmpp:dmuc:0'>
<item affiliation='owner' <item affiliation='owner'
jid='scott@fairfax.tridsys.com' name='Scott'/> jid='scott@fairfax.tridsys.com' name='Scott'/>
<item affiliation='admin' <item affiliation='admin'
jid='kevin@fairfax.tridsys.com' name='Kevin'/> jid='kevin@fairfax.tridsys.com' name='Kevin'/>
<item affiliation='none' <item affiliation='none'
jid='wayne@raleigh.tridsys.com' name='Wayne'/> jid='wayne@raleigh.tridsys.com' name='Wayne'/>
<item affiliation='none' <item affiliation='none'
jid='keith@raleigh.tridsys.com' name='Keith'/> jid='keith@raleigh.tridsys.com' name='Keith'/>
</roster> </roster>
</iq> </iq>
@ -214,7 +214,7 @@ will contain information like if the room is moderated, how much history, who is
to='chatroom@conference.fairfax.tridsys.com/Wayne' to='chatroom@conference.fairfax.tridsys.com/Wayne'
id='history' id='history'
type='get'> type='get'>
<room xmlns='urn:xmpp:dmuc:0' <room xmlns='urn:xmpp:dmuc:0'
id='chatroom@conference.fairfax.tridsys.com'> id='chatroom@conference.fairfax.tridsys.com'>
<history xmlns='http://jabber.org/protocol/muc'/> <history xmlns='http://jabber.org/protocol/muc'/>
</room> </room>
@ -227,20 +227,20 @@ will contain information like if the room is moderated, how much history, who is
id='history1' id='history1'
type='result'> type='result'>
<history xmlns='http://jabber.org/protocol/muc'> <history xmlns='http://jabber.org/protocol/muc'>
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Wayne' type='groupchat'> from='chatroom@conference.fairfax.tridsys.com/Wayne' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body> <body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay' <delay xmlns='urn:xmpp:delay'
from='wayne@raleigh.tridsys.com/TransVerse' from='wayne@raleigh.tridsys.com/TransVerse'
stamp='2011-01-19T08:02:43Z'/> stamp='2011-01-19T08:02:43Z'/>
</message> </message>
... ...
</message> </message>
<message xmlns='jabber:client' <message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Scott' type='groupchat'> from='chatroom@conference.fairfax.tridsys.com/Scott' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body> <body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay' <delay xmlns='urn:xmpp:delay'
from='scott@fairfax.tridsys.com/TransVerse' from='scott@fairfax.tridsys.com/TransVerse'
stamp='2011-01-19T08:23:10Z'/> stamp='2011-01-19T08:23:10Z'/>
<body>All work and no play makes Jack a dull boy</body> <body>All work and no play makes Jack a dull boy</body>
</message> </message>
@ -293,7 +293,7 @@ will contain information like if the room is moderated, how much history, who is
</section3> </section3>
<section3 topic='Failure case' anchor='joinfail'> <section3 topic='Failure case' anchor='joinfail'>
<p>If the master doesn't allow the user to join, it sends the standard MUC error to the mirror. <p>If the master doesn't allow the user to join, it sends the standard MUC error to the mirror.
The mirror SHOULD only send the rejection to the user that failed to join. Other users don't The mirror SHOULD only send the rejection to the user that failed to join. Other users don't
need to know. need to know.
</p> </p>
@ -310,7 +310,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
type='error'> type='error'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'> <error type='auth'>
<registration-required <registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
@ -325,7 +325,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
type='error'> type='error'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'> <error type='auth'>
<registration-required <registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
@ -368,7 +368,7 @@ the \40 to an @ and the \2f to a / to get the target user's JID and then forward
</x> </x>
</presence> </presence>
]]></example> ]]></example>
<example caption='Mirror delivers join to its occupants'><![CDATA[ <example caption='Mirror delivers join to its occupants'><![CDATA[
<presence <presence
from='chatroom@conference.fairfax.tridsys.com/Kevin' from='chatroom@conference.fairfax.tridsys.com/Kevin'

12
inbox/dna.xml
View File

@ -56,7 +56,7 @@
<di> <di>
<dt>Self-hosted domain</dt> <dt>Self-hosted domain</dt>
<dd>A domain whose owner acts as its hosting provider.</dd> <dd>A domain whose owner acts as its hosting provider.</dd>
</di> </di>
<di> <di>
<dt>Delegation</dt> <dt>Delegation</dt>
<dd>A ceremony that acts as proof of the intent of the owner of a hosted domain to cede control to a hosting provider for a given protocol.</dd> <dd>A ceremony that acts as proof of the intent of the owner of a hosted domain to cede control to a hosting provider for a given protocol.</dd>
@ -115,7 +115,7 @@
<section1 topic='Generic Use Cases' anchor='genericusecases'> <section1 topic='Generic Use Cases' anchor='genericusecases'>
<p>The DNA mechanism can be used for multiple different protocols. In particular, client-to-server XMPP and server-to-server XMPP are discussed herein, but the general approach could be used for non-XMPP protocols such as SMTP. As such, the protocol syntax offered here is normative for XMPP, but merely illustrative for other protocols, which will need their own protocol bindings.</p> <p>The DNA mechanism can be used for multiple different protocols. In particular, client-to-server XMPP and server-to-server XMPP are discussed herein, but the general approach could be used for non-XMPP protocols such as SMTP. As such, the protocol syntax offered here is normative for XMPP, but merely illustrative for other protocols, which will need their own protocol bindings.</p>
<p>The following domain names are used in the examples:</p> <p>The following domain names are used in the examples:</p>
<dl> <dl>
<di> <di>
<dt>asserted.tld</dt> <dt>asserted.tld</dt>
<dd>The domain name being asserted.</dd> <dd>The domain name being asserted.</dd>
@ -180,7 +180,7 @@
<section1 topic='DNA for XMPP Federation' anchor='federation'> <section1 topic='DNA for XMPP Federation' anchor='federation'>
<p>Two XMPP servers, each of which hosts multiple domains that they do not directly control, desire to connect in order to exchange traffic for at least two of those domains, one on either side (we call this a "dimain pair").</p> <p>Two XMPP servers, each of which hosts multiple domains that they do not directly control, desire to connect in order to exchange traffic for at least two of those domains, one on either side (we call this a "dimain pair").</p>
<p>The following domain names are used in the examples:</p> <p>The following domain names are used in the examples:</p>
<dl> <dl>
<di> <di>
<dt>target.tld</dt> <dt>target.tld</dt>
<dd>The domain portion of the JID in the <strong>"to"</strong> address of the stanza that caused this connection to be initiated.</dd> <dd>The domain portion of the JID in the <strong>"to"</strong> address of the stanza that caused this connection to be initiated.</dd>
@ -232,7 +232,7 @@ CN=server.originatingprovider.tld
<p>The <strong>"to"</strong> and <strong>"from"</strong> addresses are REQUIRED on the stream:stream tag. These represent the first domain pair associated with this stream, and are the domain names from the stanza that caused this connection to be established.</p> <p>The <strong>"to"</strong> and <strong>"from"</strong> addresses are REQUIRED on the stream:stream tag. These represent the first domain pair associated with this stream, and are the domain names from the stanza that caused this connection to be established.</p>
<p>To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation. </p> <p>To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation. </p>
<example caption='Domain name assertion in stream features'><![CDATA[<stream:features> <example caption='Domain name assertion in stream features'><![CDATA[<stream:features>
<assert xmlns='urn:xmpp:dna:0' from='target.tld'/> <assert xmlns='urn:xmpp:dna:0' from='target.tld'/>
</stream:features> </stream:features>
]]></example> ]]></example>
@ -296,7 +296,7 @@ CN=server.originatingprovider.tld
<section2 topic='Announcing Support' anchor='announce'> <section2 topic='Announcing Support' anchor='announce'>
<p>To announce its support for DNA, the server asserts its identity in the stream features following TLS negotiation. The server MUST offer the identity of the domain specified in the client's stream header <strong>"to"</strong> attribute.</p> <p>To announce its support for DNA, the server asserts its identity in the stream features following TLS negotiation. The server MUST offer the identity of the domain specified in the client's stream header <strong>"to"</strong> attribute.</p>
<example caption='Server assertion'><![CDATA[<stream:features> <example caption='Server assertion'><![CDATA[<stream:features>
<assert xmlns='urn:xmpp:dna:0' from='target.tld'/> <assert xmlns='urn:xmpp:dna:0' from='target.tld'/>
</stream:features> </stream:features>
]]></example> ]]></example>
@ -315,7 +315,7 @@ CN=server.originatingprovider.tld
<p>The domains offered are International Domain Names, as specified in <strong>rfc3920bis</strong>.</p> <p>The domains offered are International Domain Names, as specified in <strong>rfc3920bis</strong>.</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.</p> <p>For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.</p>
<p>All proof types SHALL have a mechanism to limit the period of availability.</p> <p>All proof types SHALL have a mechanism to limit the period of availability.</p>
<p>All proof types SHALL include a mechanism for revocation.</p> <p>All proof types SHALL include a mechanism for revocation.</p>
</section1> </section1>

4
inbox/dsig.xml
View File

@ -196,7 +196,7 @@
application-specific error condition element of &lt;bad-timestamp/&gt; as shown below:</p> application-specific error condition element of &lt;bad-timestamp/&gt; as shown below:</p>
<example><![CDATA[ <example><![CDATA[
<message from='romeo@example.net/orchard' <message from='romeo@example.net/orchard'
id='6410ed123' id='6410ed123'
to='juliet@capulet.net/balcony' to='juliet@capulet.net/balcony'
type='error'> type='error'>
<signed xmlns='urn:xmpp:signed:0'> <signed xmlns='urn:xmpp:signed:0'>
@ -213,7 +213,7 @@
error condition element of &lt;bad-signature/&gt; as shown below:</p> error condition element of &lt;bad-signature/&gt; as shown below:</p>
<example><![CDATA[ <example><![CDATA[
<message from='romeo@example.net/orchard' <message from='romeo@example.net/orchard'
id='6410ed123' id='6410ed123'
to='juliet@capulet.net/balcony' to='juliet@capulet.net/balcony'
type='error'> type='error'>
<e2e xmlns='urn:xmpp:signed:0'> <e2e xmlns='urn:xmpp:signed:0'>

4
inbox/fmuc.xml
View File

@ -169,7 +169,7 @@
</x> </x>
</presence> </presence>
]]></example> ]]></example>
<example caption='Proxy delivers join to its occupants'><![CDATA[ <example caption='Proxy delivers join to its occupants'><![CDATA[
<presence <presence
from='jabberchat\40talk.example.com@mirror.remote.example.com/Curtis' from='jabberchat\40talk.example.com@mirror.remote.example.com/Curtis'
@ -332,7 +332,7 @@
</message> </message>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Administration Use Cases' anchor='admin'> <section2 topic='Administration Use Cases' anchor='admin'>

22
inbox/instant-gaming.xml
View File

@ -132,7 +132,7 @@
</query> </query>
</iq>]]></example> </iq>]]></example>
</section2> </section2>
<section2 topic='Invitation' anchor='1to1-invite'> <section2 topic='Invitation' anchor='1to1-invite'>
<p> <p>
In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element, In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element,
@ -166,7 +166,7 @@
<game var='http://jabber.org/protocol/games/checkers'/> <game var='http://jabber.org/protocol/games/checkers'/>
</invite> </invite>
</message>]]></example> </message>]]></example>
<table caption='Invitation types'> <table caption='Invitation types'>
<tr> <tr>
<th>Invitation Type</th> <th>Invitation Type</th>
@ -198,7 +198,7 @@
<td>A previous invitation with the same match ID in the &THREAD; element is no longer valid.</td> <td>A previous invitation with the same match ID in the &THREAD; element is no longer valid.</td>
</tr> </tr>
--> </table> --> </table>
<p> <p>
An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation. An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation.
It MUST only be send when the previous match with the same match ID has been terminated. It MUST only be send when the previous match with the same match ID has been terminated.
@ -260,7 +260,7 @@
<thread>romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234</thread> <thread>romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234</thread>
<join xmlns='http://jabber.org/protocol/games'/> <join xmlns='http://jabber.org/protocol/games'/>
</message>]]></example> </message>]]></example>
<p> <p>
A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent. A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.
</p> </p>
@ -281,9 +281,9 @@
</error> </error>
</message>]]></example> </message>]]></example>
</section2> </section2>
<section2 topic='Game Play' anchor='1to1-play'> <section2 topic='Game Play' anchor='1to1-play'>
<p> <p>
A turn in a game is sent in a message (of type "chat") to the other player's full JID. A turn in a game is sent in a message (of type "chat") to the other player's full JID.
The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game. The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game.
The action itself can be further described by attributes or child elements (see corresponding game protocol). The action itself can be further described by attributes or child elements (see corresponding game protocol).
@ -324,13 +324,13 @@
<saved xmlns='http://jabber.org/protocol/games'/> <saved xmlns='http://jabber.org/protocol/games'/>
</message>]]></example> </message>]]></example>
<p>After receiving such an notification, an implementation MAY decide to save the game, too.</p> <p>After receiving such an notification, an implementation MAY decide to save the game, too.</p>
<p> <p>
When playing games with incomplete knowledge, When playing games with incomplete knowledge,
it is desirable that both players save the game at the same time in order to save a clean game state. it is desirable that both players save the game at the same time in order to save a clean game state.
The game protocol MUST define whether its game has to be saved independently or mutually. The game protocol MUST define whether its game has to be saved independently or mutually.
</p> </p>
<p> <p>
If a game needs to be saved mutually by both players, If a game needs to be saved mutually by both players,
one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows. one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows.
@ -373,7 +373,7 @@
</section2> </section2>
<section2 topic='Game Loading' anchor='1to1-load'> <section2 topic='Game Loading' anchor='1to1-load'>
<p> <p>
An XMPP entity that wishes to resume a saved game has to send an invitation An XMPP entity that wishes to resume a saved game has to send an invitation
of "type" 'adjourned' to the same opponent it began playing with. of "type" 'adjourned' to the same opponent it began playing with.
It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID. It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID.
@ -475,7 +475,7 @@
A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received. A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received.
If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it. If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it.
</p> </p>
<table caption='Termination reasons'> <table caption='Termination reasons'>
<tr> <tr>
<th>Reason</th> <th>Reason</th>
@ -550,7 +550,7 @@
xmlns='http://jabber.org/protocol/games' xmlns='http://jabber.org/protocol/games'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:import <xs:import
namespace='jabber:x:data' namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/> schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>

20
inbox/iot-events.xml
View File

@ -48,10 +48,10 @@
informs the device or application of desired sensor data, when certain conditions have been met, defined by the device or application. informs the device or application of desired sensor data, when certain conditions have been met, defined by the device or application.
</p> </p>
<p> <p>
The architecture defined in this document, permits the specification of conditions individually, something that would not be possible, or very difficult to achieve, if a centralized The architecture defined in this document, permits the specification of conditions individually, something that would not be possible, or very difficult to achieve, if a centralized
publish/subscribe or multi-cast pattern would have been used. By allowing individual conditions to be specified, devices or applications can be informed of information that best suit them, publish/subscribe or multi-cast pattern would have been used. By allowing individual conditions to be specified, devices or applications can be informed of information that best suit them,
and when it suits them, instead of having to figure out, from the Thing perspective, a common denominator, sufficiently good for all intended devices or applications. Furthermore, and when it suits them, instead of having to figure out, from the Thing perspective, a common denominator, sufficiently good for all intended devices or applications. Furthermore,
by aligning itself with XEP-0323 and the request/response pattern, the Thing can easily integrate with a provisioning server, as defined in XEP-0324: &xep0324;, to allow for delegation by aligning itself with XEP-0323 and the request/response pattern, the Thing can easily integrate with a provisioning server, as defined in XEP-0324: &xep0324;, to allow for delegation
of trust and allowing detailed provisioning of who is allowed to receive what information. Through the use of attributes defined in XEP-0326: &xep0326; subscriptions can be extended of trust and allowing detailed provisioning of who is allowed to receive what information. Through the use of attributes defined in XEP-0326: &xep0326; subscriptions can be extended
to underlying nodes controlled by the Thing as well. to underlying nodes controlled by the Thing as well.
</p> </p>
@ -267,7 +267,7 @@
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Use Cases' anchor='usecases'>
<p> <p>
Subscribing to events is performed much the same way as requesting sensor data from a device, as defined in <link url='http://xmpp.org/extensions/xep-0323.html#usecases'>XEP-0323</link>. Subscribing to events is performed much the same way as requesting sensor data from a device, as defined in <link url='http://xmpp.org/extensions/xep-0323.html#usecases'>XEP-0323</link>.
Instead of requesting the data using the <strong>req</strong> element of the <strong>urn:xmpp:iot:sensordata</strong> namespace, it is done using the <strong>subscribe</strong> element Instead of requesting the data using the <strong>req</strong> element of the <strong>urn:xmpp:iot:sensordata</strong> namespace, it is done using the <strong>subscribe</strong> element
of the <strong>urn:xmpp:iot:events</strong> namespace. Much of the syntax of this <strong>subscribe</strong> element coincides with that of the <strong>req</strong> element, of the <strong>urn:xmpp:iot:events</strong> namespace. Much of the syntax of this <strong>subscribe</strong> element coincides with that of the <strong>req</strong> element,
with some differences, as will be described in this document. with some differences, as will be described in this document.
</p> </p>
@ -285,7 +285,7 @@
<section2 topic='Request Subscription of momentary values' anchor='subscribemomentary'> <section2 topic='Request Subscription of momentary values' anchor='subscribemomentary'>
<p> <p>
The client that wishes to receive momentary values regularly from the sensor initiates the request using the <strong>subscribe</strong> element sent to the device. The client that wishes to receive momentary values regularly from the sensor initiates the request using the <strong>subscribe</strong> element sent to the device.
In the following example, a subscription is made to receive momentary values every five minutes (specified by the <strong>maxInterval</strong> attribute), with no In the following example, a subscription is made to receive momentary values every five minutes (specified by the <strong>maxInterval</strong> attribute), with no
field-specific conditions attached. field-specific conditions attached.
</p> </p>
<example caption='Subscription request of momentary values from a device'> <example caption='Subscription request of momentary values from a device'>
@ -325,7 +325,7 @@
id='S0002'> id='S0002'>
<subscribe xmlns='urn:xmpp:iot:events' seqnr='1' momentary='true' maxInterval='PT5M'/> <subscribe xmlns='urn:xmpp:iot:events' seqnr='1' momentary='true' maxInterval='PT5M'/>
</iq> </iq>
<iq type='error' <iq type='error'
from='device@clayster.com' from='device@clayster.com'
to='client@clayster.com/amr' to='client@clayster.com/amr'
@ -380,7 +380,7 @@
id='S0003'> id='S0003'>
<unsubscribe xmlns='urn:xmpp:iot:events' seqnr='1'/> <unsubscribe xmlns='urn:xmpp:iot:events' seqnr='1'/>
</iq> </iq>
<iq type='result' <iq type='result'
from='device@clayster.com' from='device@clayster.com'
to='client@clayster.com/amr' to='client@clayster.com/amr'
@ -610,7 +610,7 @@
</section2> </section2>
<section2 topic='Overriding subscriptions' anchor='overriding'> <section2 topic='Overriding subscriptions' anchor='overriding'>
<p> <p>
A subscriber can only have one active subscription per node on a Thing. If a Thing does not support nodes, each subscriber can only have one active subscription A subscriber can only have one active subscription per node on a Thing. If a Thing does not support nodes, each subscriber can only have one active subscription
per corresponding Thing. This means, that a new event subscription automatically overrides (or unsubscribes) any existing subscription on the corresponding node or Thing. per corresponding Thing. This means, that a new event subscription automatically overrides (or unsubscribes) any existing subscription on the corresponding node or Thing.
This in turn makes it easier for subscribers to handle restarts and avoids multiplicity problems due to lack of synchronization between subscriber and Thing. This in turn makes it easier for subscribers to handle restarts and avoids multiplicity problems due to lack of synchronization between subscriber and Thing.
</p> </p>
@ -652,7 +652,7 @@
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:import namespace='urn:xmpp:iot:sensordata'/> <xs:import namespace='urn:xmpp:iot:sensordata'/>
<xs:element name='subscribe'> <xs:element name='subscribe'>
<xs:complexType> <xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'> <xs:choice minOccurs='0' maxOccurs='unbounded'>

2
inbox/jid-mention.xml
View File

@ -26,7 +26,7 @@
<email>goffi@goffi.org</email> <email>goffi@goffi.org</email>
<jid>goffi@jabber.fr</jid> <jid>goffi@jabber.fr</jid>
</author> </author>
<revision> <revision>
<version>0.0.1</version> <version>0.0.1</version>
<date>2016-01-16</date> <date>2016-01-16</date>

8
inbox/jingle-ibb.xml
View File

@ -114,9 +114,9 @@ Initiator Responder
]]></example> ]]></example>
<p>The initiator then immediately begins sending IBB packets using an IQ-set for each chunk as described in XEP-0047, and the responder acknowledges each IQ-set.</p> <p>The initiator then immediately begins sending IBB packets using an IQ-set for each chunk as described in XEP-0047, and the responder acknowledges each IQ-set.</p>
<example caption='An IBB packet'><![CDATA[ <example caption='An IBB packet'><![CDATA[
<iq from='romeo@montague.net/orchard' <iq from='romeo@montague.net/orchard'
id='ls72b58f' id='ls72b58f'
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
type='set'> type='set'>
<data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='ch3d9s71'> <data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='ch3d9s71'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
@ -128,9 +128,9 @@ Initiator Responder
</iq> </iq>
]]></example> ]]></example>
<example caption='An IBB ack'><![CDATA[ <example caption='An IBB ack'><![CDATA[
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
id='ls72b58f' id='ls72b58f'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
type='result'/> type='result'/>
]]></example> ]]></example>
<p>Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.</p> <p>Once the parties have finished using the bytestream (e.g., because a complete file has been sent), either party can send a Jingle session-terminate action.</p>

38
inbox/jingle-nodes.xml
View File

@ -121,7 +121,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</services> </services>
</iq> ]]></example> </iq> ]]></example>
<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em> <em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
</section2> </section2>
<section2 topic="Jingle Client Searches for Services on a Retrieved Tracker Service" anchor="clientcheckownserver"> <section2 topic="Jingle Client Searches for Services on a Retrieved Tracker Service" anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p> <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p>
<example caption="Service List Request"><![CDATA[ <example caption="Service List Request"><![CDATA[
@ -140,7 +140,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<services xmlns='http://jabber.org/protocol/jinglenodes'/> <services xmlns='http://jabber.org/protocol/jinglenodes'/>
</iq> ]]></example> </iq> ]]></example>
<em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em> <em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em>
</section2> </section2>
<section2 topic="Jingle Client Searches for Services on online Roster Entries" anchor="clientcheckownserver"> <section2 topic="Jingle Client Searches for Services on online Roster Entries" anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p> <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p>
<example caption="Service List Request"><![CDATA[ <example caption="Service List Request"><![CDATA[
@ -162,7 +162,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</iq> ]]></example> </iq> ]]></example>
<p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p> <p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p>
<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em> <em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
</section2> </section2>
<section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay"> <section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay">
<p>A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p> <p>A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
<p> <p>
@ -236,35 +236,35 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<td>id</td> <td>id</td>
<td>A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production <note>See &lt;<link url='http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken'>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken</link>&gt;</note> so that XML character escaping is not needed for characters such as '&amp;'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness.</td> <td>A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production <note>See &lt;<link url='http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken'>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken</link>&gt;</note> so that XML character escaping is not needed for characters such as '&amp;'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness.</td>
<td>REQUIRED on response, NOT RECOMMENDED on requests</td> <td>REQUIRED on response, NOT RECOMMENDED on requests</td>
</tr> </tr>
<tr> <tr>
<td>host</td> <td>host</td>
<td>The IP address or Host address of the Relay Channel.</td> <td>The IP address or Host address of the Relay Channel.</td>
<td>REQUIRED on response</td> <td>REQUIRED on response</td>
</tr> </tr>
<tr> <tr>
<td>localport</td> <td>localport</td>
<td>The port number to be used by the channel requester.</td> <td>The port number to be used by the channel requester.</td>
<td>REQUIRED on response</td> <td>REQUIRED on response</td>
</tr> </tr>
<tr> <tr>
<td>remoteport</td> <td>remoteport</td>
<td>The port number to be offered to the remote party.</td> <td>The port number to be offered to the remote party.</td>
<td>REQUIRED on response</td> <td>REQUIRED on response</td>
</tr> </tr>
<tr> <tr>
<td>protocol</td> <td>protocol</td>
<td>The protocol supported by the retrieved channel.</td> <td>The protocol supported by the retrieved channel.</td>
<td>REQUIRED on response</td> <td>REQUIRED on response</td>
</tr> </tr>
<tr> <tr>
<td>maxkbps</td> <td>maxkbps</td>
<td>The maximum bandwidth supported by the channel.</td> <td>The maximum bandwidth supported by the channel.</td>
<td>OPTIONAL on response, NOT RECOMMENDED on requests.</td> <td>OPTIONAL on response, NOT RECOMMENDED on requests.</td>
</tr> </tr>
<tr> <tr>
<td>expire</td> <td>expire</td>
<td>The maximum amount of seconds that the channel can stay without receiving packets, without being deactivated and closed.</td> <td>The maximum amount of seconds that the channel can stay without receiving packets, without being deactivated and closed.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
</table> </table>
@ -279,10 +279,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<section3 topic='Remoteport Attribute' anchor='def-remoteport'> <section3 topic='Remoteport Attribute' anchor='def-remoteport'>
<p>The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.</p> <p>The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.</p>
<p>For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)</p> <p>For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)</p>
</section3> </section3>
<section3 topic='Protocol Attribute' anchor='def-protocol'> <section3 topic='Protocol Attribute' anchor='def-protocol'>
<p>The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the <link url='#schema'>XML Schema</link></p> <p>The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the <link url='#schema'>XML Schema</link></p>
</section3> </section3>
<section3 topic='Maxkbps Attribute' anchor='def-maxkbps'> <section3 topic='Maxkbps Attribute' anchor='def-maxkbps'>
<p>The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.</p> <p>The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.</p>
</section3> </section3>
@ -303,19 +303,19 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<td>policy</td> <td>policy</td>
<td>The policy of the service. If the service is public, MUST be 'public' if it is restricted to roster, MUST be 'roster'.</td> <td>The policy of the service. If the service is public, MUST be 'public' if it is restricted to roster, MUST be 'roster'.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
<tr> <tr>
<td>address</td> <td>address</td>
<td>The IP address or Host address of the Relay Channel.</td> <td>The IP address or Host address of the Relay Channel.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
<tr> <tr>
<td>protocol</td> <td>protocol</td>
<td>The protocol supported by the retrieved service.</td> <td>The protocol supported by the retrieved service.</td>
<td>REQUIRED</td> <td>REQUIRED</td>
</tr> </tr>
</table> </table>
</section2> </section2>
</section1> </section1>
<section1 topic="Determining Support" anchor="support"> <section1 topic="Determining Support" anchor="support">
<p>To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.</p> <p>To advertise its support for the Jingle Nodes support, when replying to &xep0030; information requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., "http://jabber.org/protocol/jinglenodes" for this version&VNOTE;.</p>
@ -429,14 +429,14 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:element name='services'> <xs:element name='services'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='relay' <xs:element name='relay'
type='serviceElementType' type='serviceElementType'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
<xs:element name='tracker' <xs:element name='tracker'
type='serviceElementType' type='serviceElementType'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>

14
inbox/jingle-s5b.xml
View File

@ -256,15 +256,15 @@ Romeo Juliet
<content creator='initiator' name='a-file-offer'> <content creator='initiator' name='a-file-offer'>
<description xmlns='urn:xmpp:jingle:apps:stub:0'/> <description xmlns='urn:xmpp:jingle:apps:stub:0'/>
<transport xmlns='urn:xmpp:jingle:transports:s5b:0' <transport xmlns='urn:xmpp:jingle:transports:s5b:0'
sid='vj3hs98y' sid='vj3hs98y'
mode='tcp'> mode='tcp'>
<streamhost <streamhost
jid='romeo@montague.lit/orchard' jid='romeo@montague.lit/orchard'
host='192.168.4.1' host='192.168.4.1'
port='5086'/> port='5086'/>
<streamhost <streamhost
jid='streamer.shakespeare.lit' jid='streamer.shakespeare.lit'
host='24.24.24.1' host='24.24.24.1'
zeroconf='_jabber.bytestreams'/> zeroconf='_jabber.bytestreams'/>
</transport> </transport>
</content> </content>

2
inbox/jingle-sdp.xml
View File

@ -242,7 +242,7 @@ a=ssrc:2358488720 label:QoHel4kmL4ZFaJuTwmz3VpyxzMRCcNDEmcClv0
o=- 8065558698633182641 2 IN IP4 127.0.0.1 o=- 8065558698633182641 2 IN IP4 127.0.0.1
s=- s=-
t=0 0 t=0 0
a=group:BUNDLE audio a=group:BUNDLE audio
a=msid-semantic: WMS QoHel4kmL4ZFaJuTwmz3VpyxzMRCcNDEmcCl a=msid-semantic: WMS QoHel4kmL4ZFaJuTwmz3VpyxzMRCcNDEmcCl
</session> </session>
<content creator='initiator' name='audio'> <content creator='initiator' name='audio'>

10
inbox/jingle-xtls.xml
View File

@ -315,11 +315,11 @@ Initiator Responder
A B A B
| | | |
| challengeSaltA | | challengeSaltA |
|=========================>| |=========================>|
| challengeSaltB + hashB | | challengeSaltB + hashB |
|<=========================| |<=========================|
| hashA | | hashA |
|=========================>| |=========================>|
hashB = sha1(publicKeyB + password + challengeSaltA + respondSaltB) hashB = sha1(publicKeyB + password + challengeSaltA + respondSaltB)
hashA = sha1(publicKeyA + password + challengeSaltB + respondSaltA) hashA = sha1(publicKeyA + password + challengeSaltB + respondSaltA)
@ -330,9 +330,9 @@ hashA = sha1(publicKeyA + password + challengeSaltB + respondSaltA)
A B A B
| | | |
| respondSaltB | | respondSaltB |
|<=========================| |<=========================|
| respondSaltA | | respondSaltA |
|=========================>| |=========================>|
]]></code> ]]></code>
<p>The man-in-the-middle can get the password using brute-force. Both public keys and the four salt strings are now known. To keep hidden as man-in-the-middle, the attacker needs to create a respondSalt for both peers that matches its public key, the password, the challengeSalt, and the hash sum it send. The problem for the attacking client is that it had to send out a hash sum at a point where it is not possible to get the shared key (the respondSalt is missing). If the hash sum is secure against creating collisions this is not possible. The man-in-the-middle has to use brute force and create two collisions in a very short time frame.</p> <p>The man-in-the-middle can get the password using brute-force. Both public keys and the four salt strings are now known. To keep hidden as man-in-the-middle, the attacker needs to create a respondSalt for both peers that matches its public key, the password, the challengeSalt, and the hash sum it send. The problem for the attacking client is that it had to send out a hash sum at a point where it is not possible to get the shared key (the respondSalt is missing). If the hash sum is secure against creating collisions this is not possible. The man-in-the-middle has to use brute force and create two collisions in a very short time frame.</p>
<ul> <ul>

4
inbox/jingle-zrtp.xml
View File

@ -90,7 +90,7 @@ a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46d
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports the zrtp-hash session-info message, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:jingle:apps:rtp:zrtp:0":</p> <p>If an entity supports the zrtp-hash session-info message, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:jingle:apps:rtp:zrtp:0":</p>
<example caption='A disco#info query'><![CDATA[ <example caption='A disco#info query'><![CDATA[
<iq type='get' <iq type='get'
from='calvin@usrobots.lit/lab' from='calvin@usrobots.lit/lab'
to='herbie@usrobots.lit/home' to='herbie@usrobots.lit/home'
id='disco1'> id='disco1'>
@ -98,7 +98,7 @@ a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46d
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq type='result' <iq type='result'
from='herbie@usrobots.lit/home' from='herbie@usrobots.lit/home'
to='calvin@usrobots.lit/lab' to='calvin@usrobots.lit/lab'
id='disco1'> id='disco1'>

2
inbox/json.xml
View File

@ -203,7 +203,7 @@ Content-Length: 513
</pre> </pre>
<em>JSON:</em><pre> <em>JSON:</em><pre>
{ "tag" : { { "tag" : {
"tag2" : [ "tag2" : [
{ "attr" : "attr-value1" }, { "attr" : "attr-value1" },
{ "attr" : "attr-value2" } ] { "attr" : "attr-value2" } ]
} }

178
inbox/lop.xml
View File

@ -104,17 +104,17 @@
</p> </p>
<ul> <ul>
<li><strong>Countryside</strong>: an XMPP account that is identified by a bare JID. While the term "account" or "bare JID" could have been used, in order to follow the rural theme, the term countryside was adopted.</li> <li><strong>Countryside</strong>: an XMPP account that is identified by a bare JID. While the term "account" or "bare JID" could have been used, in order to follow the rural theme, the term countryside was adopted.</li>
<li><strong>Farm</strong>: an XMPP client that is identified by a fully-qualified JID. The bare JID of the farm is known as the farm's countryside. Any device running a farm will have an account with an XMPP server. A countryside can host many farms (this facilitates the "clustering" of devices). In general, there exists one farm for every physical device providing computing resources to a cloud<note>Note that this is not required as in some cases, it is useful to run multiple farms on a single device. For example, two farms can have different permissions to resources.</note> The purpose of a farm is to wait for resource consumers to communicate with it in order to spawn/create and compute with virtual machines. A farm also specifies the permissions that a villein has with respect to its provided computing resources</li> <li><strong>Farm</strong>: an XMPP client that is identified by a fully-qualified JID. The bare JID of the farm is known as the farm's countryside. Any device running a farm will have an account with an XMPP server. A countryside can host many farms (this facilitates the "clustering" of devices). In general, there exists one farm for every physical device providing computing resources to a cloud<note>Note that this is not required as in some cases, it is useful to run multiple farms on a single device. For example, two farms can have different permissions to resources.</note> The purpose of a farm is to wait for resource consumers to communicate with it in order to spawn/create and compute with virtual machines. A farm also specifies the permissions that a villein has with respect to its provided computing resources</li>
<li><strong>Virtual machine</strong>: a computing sandbox/environment that is denoted by an identifier that is internally unique to a farm. A virtual machine is spawned from a farm and can be of any "species" (i.e. computer language). A virtual machine, like a farm, exists on the resource provider's device. Example virtual machine species include JavaScript, Python, Ruby, Groovy, etc. A virtual machine is the means by which a client (known as a "villein") is able to access the computing resources of the device running the virtual machine. In short, a virtual machine is the gateway to the computing resources of the resource provider.</li> <li><strong>Virtual machine</strong>: a computing sandbox/environment that is denoted by an identifier that is internally unique to a farm. A virtual machine is spawned from a farm and can be of any "species" (i.e. computer language). A virtual machine, like a farm, exists on the resource provider's device. Example virtual machine species include JavaScript, Python, Ruby, Groovy, etc. A virtual machine is the means by which a client (known as a "villein") is able to access the computing resources of the device running the virtual machine. In short, a virtual machine is the gateway to the computing resources of the resource provider.</li>
<li><strong>Registry</strong>: an XMPP client that is identified by a fully-qualified JID. A registry maintains a list of countrysides (i.e. bare JIDs) that have active farms running on them. The purpose of a registry is to allow countryside owners to advertise themselves. A registry monitors all the presence stanzas coming out of a countryside. When there is at least one active farm on the countryside, the registry records the countryside and makes that information available upon a <tt>disco#items</tt> request.</li> <li><strong>Registry</strong>: an XMPP client that is identified by a fully-qualified JID. A registry maintains a list of countrysides (i.e. bare JIDs) that have active farms running on them. The purpose of a registry is to allow countryside owners to advertise themselves. A registry monitors all the presence stanzas coming out of a countryside. When there is at least one active farm on the countryside, the registry records the countryside and makes that information available upon a <tt>disco#items</tt> request.</li>
<li><strong>Villein</strong>: an XMPP client that is identified by a fully-qualified JID. A villein is a software application that is executed by a resource consumer. The purpose of a villein is to communicate with farms to spawn and compute with virtual machines. A villein communicates with virtual machines to perform some type of distributed computation by leveraging remote computing resources. "Chunks" of computation submitted to a virtual machine from a villein are known as <strong>jobs</strong>. The term "villein" comes from the medival jargon where "villeins generally rented small homes, with or without land. As part of the contract with their landlord, they were expected to use some of their time to farm the lord's fields"<note>This quote was taken from the <link url="http://en.wikipedia.org/wiki/Serfdom">surfdom</link> Wikipedia entry on 06-06-2009.</note>.</li> <li><strong>Villein</strong>: an XMPP client that is identified by a fully-qualified JID. A villein is a software application that is executed by a resource consumer. The purpose of a villein is to communicate with farms to spawn and compute with virtual machines. A villein communicates with virtual machines to perform some type of distributed computation by leveraging remote computing resources. "Chunks" of computation submitted to a virtual machine from a villein are known as <strong>jobs</strong>. The term "villein" comes from the medival jargon where "villeins generally rented small homes, with or without land. As part of the contract with their landlord, they were expected to use some of their time to farm the lord's fields"<note>This quote was taken from the <link url="http://en.wikipedia.org/wiki/Serfdom">surfdom</link> Wikipedia entry on 06-06-2009.</note>.</li>
</ul> </ul>
<p> <p>
In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider. In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider.
</p> </p>
</section1> </section1>
@ -136,7 +136,7 @@
<li><tt>&lt;terminate_vm/&gt;</tt>: for halting/quitting/closing a virtual machine.</li> <li><tt>&lt;terminate_vm/&gt;</tt>: for halting/quitting/closing a virtual machine.</li>
<li><tt>disco#info</tt>: for discovering the permissions, configurations, and statistics of a farm and its spawned virtual machines.</li> <li><tt>disco#info</tt>: for discovering the permissions, configurations, and statistics of a farm and its spawned virtual machines.</li>
</ul> </ul>
<section3 topic="Rules Regarding Farm Presence"> <section3 topic="Rules Regarding Farm Presence">
<p> <p>
The farm specification for <tt>&lt;presence/&gt;</tt> is built on the specification as defined by the <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link> XMPP specification<note>Please refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.</note>. What follows is a collection of guidelines regarding the use of <tt>&lt;presence/&gt;</tt> by a farm. The farm specification for <tt>&lt;presence/&gt;</tt> is built on the specification as defined by the <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link> XMPP specification<note>Please refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.</note>. What follows is a collection of guidelines regarding the use of <tt>&lt;presence/&gt;</tt> by a farm.
@ -155,14 +155,14 @@
<li><tt>type="unavailable"</tt>: an unavailable presence denotes that the farm is inactive and is not accepting any stanzas.</li> <li><tt>type="unavailable"</tt>: an unavailable presence denotes that the farm is inactive and is not accepting any stanzas.</li>
</ul> </ul>
</section3> </section3>
<section3 topic="Spawning a Virtual Machine"> <section3 topic="Spawning a Virtual Machine">
<p> <p>
A <tt>&lt;spawn_vm/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;spawn_vm/&gt;</tt> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindings<note>This is an important concept to understand. During the life of a virtual machine, the virtual machine has a state that changes as jobs are submitted and bindings are managed. In other words, a virtual machine is not a "one-job" machine.</note>. A <tt>&lt;spawn_vm/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;spawn_vm/&gt;</tt> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindings<note>This is an important concept to understand. During the life of a virtual machine, the virtual machine has a state that changes as jobs are submitted and bindings are managed. In other words, a virtual machine is not a "one-job" machine.</note>.
</p> </p>
<ul> <ul>
<li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;spawn_vm/&gt;</tt>:</li> <li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;spawn_vm/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_species</tt> attribute: the language of the virtual machine to be spawned (values are implementation dependent).</li> <li><tt>vm_species</tt> attribute: the language of the virtual machine to be spawned (values are implementation dependent).</li>
<li><tt>farm_password</tt> attribute: the password of the farm<note>This is an OPTIONAL attribute. Farm passwords are useful for creating private farms in order, for example, to allow "looser" permissions with known villeins. If no password is required (e.g. a public farm), then no <tt>farm_password</tt> attribute SHOULD be provided.</note>.</li> <li><tt>farm_password</tt> attribute: the password of the farm<note>This is an OPTIONAL attribute. Farm passwords are useful for creating private farms in order, for example, to allow "looser" permissions with known villeins. If no password is required (e.g. a public farm), then no <tt>farm_password</tt> attribute SHOULD be provided.</note>.</li>
@ -170,8 +170,8 @@
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;spawn_vm/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;spawn_vm/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: a farm-internal unique identifier for the newly created virtual machine. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li> <li><tt>vm_id</tt> attribute: a farm-internal unique identifier for the newly created virtual machine. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li>
<li><tt>vm_species</tt> attribute: the species of the newly created virtual machine. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li> <li><tt>vm_species</tt> attribute: the species of the newly created virtual machine. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li>
<li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li> <li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul> <ul>
<li><tt>&lt;species_not_supported/&gt;</tt></li> <li><tt>&lt;species_not_supported/&gt;</tt></li>
@ -179,72 +179,72 @@
<li><tt>&lt;malformed_packet/&gt;</tt></li> <li><tt>&lt;malformed_packet/&gt;</tt></li>
<li><tt>&lt;internal_error/&gt;</tt></li> <li><tt>&lt;internal_error/&gt;</tt></li>
<li><tt>&lt;wrong_farm_password/&gt;</tt></li> <li><tt>&lt;wrong_farm_password/&gt;</tt></li>
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li> <li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;spawn_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;spawn_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascript"/> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascript"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" vm_species="javascript"/> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" vm_species="javascript"/>
</iq> </iq>
]]></example> ]]></example>
<example caption="An unsuccessful &lt;spawn_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="An unsuccessful &lt;spawn_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy"> to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascr"/> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascr"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="error" id="yyyy"> to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#"/> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<error code="503" type="cancel"> <error code="503" type="cancel">
<service_unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> <service_unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<species_not_supported xmlns="http://linkedprocess.org/2009/06/Farm#"/> <species_not_supported xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en"> <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
'javascr' is not a supported virtual machine species 'javascr' is not a supported virtual machine species
</text> </text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Submitting a Job to a Virtual Machine"> <section3 topic="Submitting a Job to a Virtual Machine">
<p> <p>
A <tt>&lt;submit_job/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;submit_job/&gt;</tt> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <tt>&lt;submit_job/&gt;</tt> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a <strong>job</strong> in Linked Process and is assigned a <tt>job_id</tt> as specified by the <tt>&lt;iq/&gt;</tt> <tt>id</tt> attribute value. That is, the staza id of the <tt>&lt;submit_job/&gt;</tt> is the job's id. A <tt>&lt;submit_job/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;submit_job/&gt;</tt> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <tt>&lt;submit_job/&gt;</tt> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a <strong>job</strong> in Linked Process and is assigned a <tt>job_id</tt> as specified by the <tt>&lt;iq/&gt;</tt> <tt>id</tt> attribute value. That is, the staza id of the <tt>&lt;submit_job/&gt;</tt> is the job's id.
</p> </p>
<ul> <ul>
<li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;submit_job/&gt;</tt>:</li> <li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;submit_job/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li><tt>&lt;submit_job/&gt;</tt> text body: the expression for the virtual machine to evaluate. If no text body is provided, the expression to be evaluated can be interpreted as a blank string or a null expression. The behavior of such an evaluation is up to the virtual machine implementation.</li> <li><tt>&lt;submit_job/&gt;</tt> text body: the expression for the virtual machine to evaluate. If no text body is provided, the expression to be evaluated can be interpreted as a blank string or a null expression. The behavior of such an evaluation is up to the virtual machine implementation.</li>
</ul> </ul>
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;submit_job/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;submit_job/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li><tt>&lt;submit_job/&gt;</tt> text body: the result of the expression evaluated.</li> <li><tt>&lt;submit_job/&gt;</tt> text body: the result of the expression evaluated.</li>
<li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt><note>Note that, according to XMPP Core, it is RECOMMENDED that an <tt>&lt;iq type="error"/&gt;</tt> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <tt>&lt;submit_job/&gt;</tt>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <tt>&lt;submit_job/&gt;</tt> stanza in the error response could lead to excessive communication overhead.</note>.</li> <li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt><note>Note that, according to XMPP Core, it is RECOMMENDED that an <tt>&lt;iq type="error"/&gt;</tt> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <tt>&lt;submit_job/&gt;</tt>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <tt>&lt;submit_job/&gt;</tt> stanza in the error response could lead to excessive communication overhead.</note>.</li>
<ul> <ul>
<li><tt>&lt;malformed_packet/&gt;</tt></li> <li><tt>&lt;malformed_packet/&gt;</tt></li>
<li><tt>&lt;internal_error/&gt;</tt></li> <li><tt>&lt;internal_error/&gt;</tt></li>
<li><tt>&lt;evaluation_error/&gt;</tt></li> <li><tt>&lt;evaluation_error/&gt;</tt></li>
<li><tt>&lt;permission_denied/&gt;</tt></li> <li><tt>&lt;permission_denied/&gt;</tt></li>
<li><tt>&lt;job_already_exists/&gt;</tt></li> <li><tt>&lt;job_already_exists/&gt;</tt></li>
<li><tt>&lt;vm_is_busy/&gt;</tt></li> <li><tt>&lt;vm_is_busy/&gt;</tt></li>
<li><tt>&lt;vm_not_found/&gt;</tt></li> <li><tt>&lt;vm_not_found/&gt;</tt></li>
<li><tt>&lt;job_timed_out/&gt;</tt></li> <li><tt>&lt;job_timed_out/&gt;</tt></li>
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li> <li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;submit_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;submit_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
var temp=0; var temp=0;
@ -255,7 +255,7 @@
</submit_job> </submit_job>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464"> <submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
10 10
@ -265,14 +265,14 @@
<p> <p>
The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <tt>&lt;submit_job/&gt;</tt>. The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <tt>&lt;submit_job/&gt;</tt>.
</p> </p>
<example caption="A successful &lt;submit_job/&gt; request demonstrating the consistency of a virtual machine's state between &lt;submit_job/&gt; requests."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;submit_job/&gt; request demonstrating the consistency of a virtual machine's state between &lt;submit_job/&gt; requests."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy"> to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
temp + 1; temp + 1;
</submit_job> </submit_job>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy"> to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464"> <submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
11 11
@ -295,12 +295,12 @@
<evaluation_error xmlns="http://linkedprocess.org/2009/06/Farm#"/> <evaluation_error xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en"> <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
ReferenceError: "bad_variable" is not defined at line number 1 ReferenceError: "bad_variable" is not defined at line number 1
</text> </text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Determining the Status of a Virtual Machine Job"> <section3 topic="Determining the Status of a Virtual Machine Job">
<p> <p>
A <tt>&lt;ping_job/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;ping_job/&gt;</tt> is to determine the status (i.e. progress, state) of a previously submitted <tt>&lt;submit_job/&gt;</tt> stanza (i.e. job) that has yet to complete. A <tt>&lt;ping_job/&gt;</tt> element is wrapped by an <tt>&lt;iq/&gt;</tt> element. The purpose of <tt>&lt;ping_job/&gt;</tt> is to determine the status (i.e. progress, state) of a previously submitted <tt>&lt;submit_job/&gt;</tt> stanza (i.e. job) that has yet to complete.
@ -314,7 +314,7 @@
</ul> </ul>
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;ping_job/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;ping_job/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li><tt>status</tt> attribute: the job's status. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li> <li><tt>status</tt> attribute: the job's status. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li>
<ul> <ul>
@ -331,17 +331,17 @@
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;ping_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;ping_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/> <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" status="in_progress"/> <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" status="in_progress"/>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Aborting a Virtual Machine Job"> <section3 topic="Aborting a Virtual Machine Job">
<p> <p>
@ -354,10 +354,10 @@
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li><tt>job_id</tt> attribute: the job identifier (the job identifier is the stanza identifier of the respective <tt>&lt;submit_job/&gt;</tt>).</li> <li><tt>job_id</tt> attribute: the job identifier (the job identifier is the stanza identifier of the respective <tt>&lt;submit_job/&gt;</tt>).</li>
</ul> </ul>
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;abort_job/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;abort_job/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li> <li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul> <ul>
@ -369,32 +369,32 @@
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;abort_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;abort_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq> </iq>
]]></example> ]]></example>
<example caption="An unsuccessful &lt;abort_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="An unsuccessful &lt;abort_job/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy"> to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="zzzz"/> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="zzzz"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="error" id="yyyy"> to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#"/> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<error code="404" type="cancel"> <error code="404" type="cancel">
<item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> <item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<job_not_found xmlns="http://linkedprocess.org/2009/06/Farm#"/> <job_not_found xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en"> <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
Job 'zzzz' was not found in the virtual machine. Job 'zzzz' was not found in the virtual machine.
</text> </text>
</error> </error>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
@ -420,7 +420,7 @@
</ul> </ul>
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;manage_bindings/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;manage_bindings/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li><tt>&lt;binding/&gt;</tt> child tag of <tt>&lt;manage_bindings/&gt;</tt> for <tt>&lt;iq type="get"/&gt;</tt></li> <li><tt>&lt;binding/&gt;</tt> child tag of <tt>&lt;manage_bindings/&gt;</tt> for <tt>&lt;iq type="get"/&gt;</tt></li>
<ul> <ul>
@ -437,7 +437,7 @@
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li> <li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt>&lt;text/&gt;</tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;manage_bindings/&gt; set request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;manage_bindings/&gt; set request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="set" id="xxxx"> to="lp2@linkedprocess.org/farm" type="set" id="xxxx">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
@ -446,12 +446,12 @@
</manage_bindings> </manage_bindings>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq> </iq>
]]></example> ]]></example>
<example caption="A successful &lt;manage_bindings/&gt; get request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;manage_bindings/&gt; get request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy"> to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age"/> <binding name="age"/>
@ -459,7 +459,7 @@
</manage_bindings> </manage_bindings>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy"> to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/> <binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/>
@ -469,22 +469,22 @@
]]></example> ]]></example>
<p> <p>
After the previous <tt>&lt;manage_bindings/&gt;</tt> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript After the previous <tt>&lt;manage_bindings/&gt;</tt> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript
<code>var fact = name + " knows josh and peter";</code> <code>var fact = name + " knows josh and peter";</code>
will set <tt>fact</tt> to the value "marko knows josh and peter" as well as make it an accessible binding. will set <tt>fact</tt> to the value "marko knows josh and peter" as well as make it an accessible binding.
</p> </p>
<example caption="A successful &lt;manage_bindings/&gt; get request."><![CDATA[<iq from="lp1@linkedprocess.org/villein" <example caption="A successful &lt;manage_bindings/&gt; get request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="zzzz"> to="lp2@linkedprocess.org/farm" type="get" id="zzzz">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="fact"/> <binding name="fact"/>
</manage_bindings> </manage_bindings>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="zzzz"> to="lp1@linkedprocess.org/villein" type="result" id="zzzz">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"> <manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="fact" value="marko knows josh and peter" <binding name="fact" value="marko knows josh and peter"
datatype="http://www.w3.org/2001/XMLSchema#string"/> datatype="http://www.w3.org/2001/XMLSchema#string"/>
</manage_bindings> </manage_bindings>
</iq> </iq>
@ -494,7 +494,7 @@
while(true) { while(true) {
x = x + 0.0001; x = x + 0.0001;
}</code> }</code>
This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of <tt>x</tt> using <tt>&lt;manage_bindings/&gt;</tt>. Each get-based <tt>&lt;manage_bindings/&gt;</tt> call should return a larger <tt>x</tt> value. This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of <tt>x</tt> using <tt>&lt;manage_bindings/&gt;</tt>. Each get-based <tt>&lt;manage_bindings/&gt;</tt> call should return a larger <tt>x</tt> value.
</p> </p>
</section3> </section3>
<section3 topic="Terminating a Virtual Machine"> <section3 topic="Terminating a Virtual Machine">
@ -504,12 +504,12 @@ while(true) {
<ul> <ul>
<li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;terminate_vm/&gt;</tt>:</li> <li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;terminate_vm/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
</ul> </ul>
<li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;terminate_vm/&gt;</tt>:</li> <li>Farm generated <tt>&lt;iq type="result"&gt;</tt> or <tt>&lt;iq type="error"&gt;</tt> <tt>&lt;terminate_vm/&gt;</tt>:</li>
<ul> <ul>
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li> <li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li> <li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
<li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li> <li>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul> <ul>
@ -520,12 +520,12 @@ while(true) {
</ul> </ul>
</ul> </ul>
</ul> </ul>
<example caption="A successful &lt;terminate_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/LoPVillein/EFGH" <example caption="A successful &lt;terminate_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/LoPVillein/EFGH"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm" <![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq> </iq>
@ -546,13 +546,13 @@ while(true) {
</p> </p>
<ul> <ul>
<li><tt>&lt;feature var="http://jabber.org/protocol/disco#info"/&gt;</tt></li> <li><tt>&lt;feature var="http://jabber.org/protocol/disco#info"/&gt;</tt></li>
<li><tt>&lt;feature var="http://linkedprocess.org/2009/06/Farm#"/&gt;</tt></li> <li><tt>&lt;feature var="http://linkedprocess.org/2009/06/Farm#"/&gt;</tt></li>
</ul> </ul>
<p> <p>
The <tt>http://linkedprocess.org/2009/06/Farm#</tt> <tt>&lt;feature/&gt;</tt> denotes that the XMPP client is in fact a farm. The <tt>http://linkedprocess.org/2009/06/Farm#</tt> <tt>&lt;feature/&gt;</tt> denotes that the XMPP client is in fact a farm.
</p> </p>
<p> <p>
For presenting permissions, configurations, and statistics, a farm uses the data forms <link url="http://xmpp.org/extensions/xep-0004.html">XEP-0004</link> XMPP extension in its <tt>disco#info</tt> response. The following list of <tt>&lt;field/&gt;</tt> variables (<tt>var</tt>) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machines<note>What is provided is not an exhaustive list as there may be other permissions that are desired that can not be known <em>apriori</em> by the developers of this specification. For example, there may be computing resources such as hardware (e.g. video cards, FPGA components) that can have specialized requirements and parameters. Moreover, particular implementations of a Linked Process farm may have specific permissions that are not general to all implementaitons (e.g. Java-specific permissions). The data forms specification provided here can be extended to support such farm specific resources.</note>. For presenting permissions, configurations, and statistics, a farm uses the data forms <link url="http://xmpp.org/extensions/xep-0004.html">XEP-0004</link> XMPP extension in its <tt>disco#info</tt> response. The following list of <tt>&lt;field/&gt;</tt> variables (<tt>var</tt>) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machines<note>What is provided is not an exhaustive list as there may be other permissions that are desired that can not be known <em>apriori</em> by the developers of this specification. For example, there may be computing resources such as hardware (e.g. video cards, FPGA components) that can have specialized requirements and parameters. Moreover, particular implementations of a Linked Process farm may have specific permissions that are not general to all implementaitons (e.g. Java-specific permissions). The data forms specification provided here can be extended to support such farm specific resources.</note>.
</p> </p>
<table caption='Fields of the data forms for the disco#info of a farm.'> <table caption='Fields of the data forms for the disco#info of a farm.'>
<tr> <tr>
@ -687,7 +687,7 @@ while(true) {
<li><strong>Simulated remote procedure call</strong> [consuming software API resources]: Linked Process allows for lower-level control of the resources provided by a resource provider. However, with software APIs being a computing resource, it is possible for resource providers to support high-level functions/methods for manipulating resources in the way of accessible APIs/packages/libraries. In this way, RPC-based models of distributed computing can be simulated.</li> <li><strong>Simulated remote procedure call</strong> [consuming software API resources]: Linked Process allows for lower-level control of the resources provided by a resource provider. However, with software APIs being a computing resource, it is possible for resource providers to support high-level functions/methods for manipulating resources in the way of accessible APIs/packages/libraries. In this way, RPC-based models of distributed computing can be simulated.</li>
</ul> </ul>
</section3> </section3>
</section2> </section2>
<section2 topic="Registry Use Cases"> <section2 topic="Registry Use Cases">
<p> <p>
@ -703,16 +703,16 @@ while(true) {
A registry makes use of <tt>&lt;presence/&gt;</tt> stanzas for determining the availability of farms on a countryside. In order to monitor <tt>&lt;presence/&gt;</tt> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link>, this is handled using this sequence of <tt>&lt;presence/&gt;</tt> communication. A registry makes use of <tt>&lt;presence/&gt;</tt> stanzas for determining the availability of farms on a countryside. In order to monitor <tt>&lt;presence/&gt;</tt> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link>, this is handled using this sequence of <tt>&lt;presence/&gt;</tt> communication.
</p> </p>
<example caption="A successful subscription with a registry"><![CDATA[ <example caption="A successful subscription with a registry"><![CDATA[
<presence from="lp2@linkedprocess.org/farm" <presence from="lp2@linkedprocess.org/farm"
to="lp3@linkedprocess.org/registry" type="subscribe"/> to="lp3@linkedprocess.org/registry" type="subscribe"/>
<presence to="lp2@linkedprocess.org/farm" <presence to="lp2@linkedprocess.org/farm"
from="lp3@linkedprocess.org/registry" type="subscribed"/> from="lp3@linkedprocess.org/registry" type="subscribed"/>
<presence to="lp2@linkedprocess.org/farm" <presence to="lp2@linkedprocess.org/farm"
from="lp3@linkedprocess.org/registry" type="subscribe"/> from="lp3@linkedprocess.org/registry" type="subscribe"/>
<presence from="lp2@linkedprocess.org/farm" <presence from="lp2@linkedprocess.org/farm"
to="lp3@linkedprocess.org/registry" type="subscribed"/> to="lp3@linkedprocess.org/registry" type="subscribed"/>
]]> ]]>
</example> </example>
@ -724,12 +724,12 @@ while(true) {
<p> <p>
A registry uses the <link url="http://xmpp.org/extensions/xep-0030.html">XEP-0030</link> XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a <tt>disco#info</tt> query. The <tt>&lt;item/&gt;</tt> elements denote countrysides. For example, <tt>&lt;item jid="lanl_countryside@lanl.linkedprocess.org"/&gt;</tt> denotes that there is at least one active farm at <tt> lanl_countryside@lanl.linkedprocess.org</tt>. A registry uses the <link url="http://xmpp.org/extensions/xep-0030.html">XEP-0030</link> XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a <tt>disco#info</tt> query. The <tt>&lt;item/&gt;</tt> elements denote countrysides. For example, <tt>&lt;item jid="lanl_countryside@lanl.linkedprocess.org"/&gt;</tt> denotes that there is at least one active farm at <tt> lanl_countryside@lanl.linkedprocess.org</tt>.
</p> </p>
<example caption="A successful query for countrysides registered with a registry."><![CDATA[<iq id="xxxx" to="lp3@linkedprocess.org/registry" <example caption="A successful query for countrysides registered with a registry."><![CDATA[<iq id="xxxx" to="lp3@linkedprocess.org/registry"
from="lp1@linkedprocess.org/villein" type="get"> from="lp1@linkedprocess.org/villein" type="get">
<query xmlns="http://jabber.org/protocol/disco#items"/> <query xmlns="http://jabber.org/protocol/disco#items"/>
</iq> </iq>
]]> ]]>
<![CDATA[<iq id="xxxx" from="lp3@linkedprocess.org/registry" <![CDATA[<iq id="xxxx" from="lp3@linkedprocess.org/registry"
to="lp1@linkedprocess.org/villein" type="result"> to="lp1@linkedprocess.org/villein" type="result">
<query xmlns="http://jabber.org/protocol/disco#items"> <query xmlns="http://jabber.org/protocol/disco#items">
<item jid="lanl_countryside@lanl.linkedprocess.org"/> <item jid="lanl_countryside@lanl.linkedprocess.org"/>
@ -748,7 +748,7 @@ while(true) {
The <tt>&lt;identity/&gt;</tt> of a registry MUST be of <tt>category="client"</tt> and <tt>type="bot"</tt>. The <tt>name</tt> attribute is up to the implementation. The <tt>&lt;identity/&gt;</tt> of a registry MUST be of <tt>category="client"</tt> and <tt>type="bot"</tt>. The <tt>name</tt> attribute is up to the implementation.
</p> </p>
<ul> <ul>
<li><tt>&lt;identity category="client" name="LoPRegistry" type="bot"/&gt;</tt></li> <li><tt>&lt;identity category="client" name="LoPRegistry" type="bot"/&gt;</tt></li>
</ul> </ul>
<p> <p>
The following <tt>&lt;feature/&gt;</tt>s MUST be supported by a registry: The following <tt>&lt;feature/&gt;</tt>s MUST be supported by a registry:
@ -914,7 +914,7 @@ while(true) {
<ul> <ul>
<li><strong>file system corruption</strong>: if the disk I/O permissions are not implelemented correctly or not strongly specified, then the disk of the device can be compromised.</li> <li><strong>file system corruption</strong>: if the disk I/O permissions are not implelemented correctly or not strongly specified, then the disk of the device can be compromised.</li>
<li><strong>private files access</strong>: if the disco I/O permissions are not implemented correctly or not strongly specified, then potentially private information on the disk of the device can be accessed.</li> <li><strong>private files access</strong>: if the disco I/O permissions are not implemented correctly or not strongly specified, then potentially private information on the disk of the device can be accessed.</li>
<li><strong>inappropriate access to resources</strong>: if the permissions are not implemented correctly or not strongly specified, it is possible for villeins to gain access to undesired devices such as printers, windowing toolkits, cameras, etc.</li> <li><strong>inappropriate access to resources</strong>: if the permissions are not implemented correctly or not strongly specified, it is possible for villeins to gain access to undesired devices such as printers, windowing toolkits, cameras, etc.</li>
<li><strong>denial of service attacks</strong>: if the network I/O permissions are not implemented or strongly specified, then the device can be harvested for a denial of service (DoS) attack on other devices on the Internet.</li> <li><strong>denial of service attacks</strong>: if the network I/O permissions are not implemented or strongly specified, then the device can be harvested for a denial of service (DoS) attack on other devices on the Internet.</li>
<li><strong>Linked Process denial of service attacks</strong>: if the scheduler (i.e. thread operating system) of the farm is not implemented correctly, then it is possible for a farm to be overloaded by a single virtual machine rendering the farm useless to the creation of new virtual machines.</li> <li><strong>Linked Process denial of service attacks</strong>: if the scheduler (i.e. thread operating system) of the farm is not implemented correctly, then it is possible for a farm to be overloaded by a single virtual machine rendering the farm useless to the creation of new virtual machines.</li>
</ul> </ul>
@ -933,7 +933,7 @@ while(true) {
<li><tt>http://linkedprocess.org/2006/06/Farm#</tt></li> <li><tt>http://linkedprocess.org/2006/06/Farm#</tt></li>
<li><tt>http://linkedprocess.org/2006/06/Registry#</tt></li> <li><tt>http://linkedprocess.org/2006/06/Registry#</tt></li>
</ul> </ul>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[<?xml version='1.0' encoding='UTF-8'?> <code><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
@ -958,13 +958,13 @@ while(true) {
<xs:attribute name='vm_id' type='xs:string' use='optional'/> <xs:attribute name='vm_id' type='xs:string' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='submit_job'> <xs:element name='submit_job'>
<xs:complexType> <xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/> <xs:attribute name='vm_id' type='xs:string' use='required'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='ping_job'> <xs:element name='ping_job'>
<xs:complexType> <xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/> <xs:attribute name='vm_id' type='xs:string' use='required'/>
@ -978,21 +978,21 @@ while(true) {
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='abort_job'> <xs:element name='abort_job'>
<xs:complexType> <xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/> <xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:attribute name='job_id' type='xs:string' use='optional'/> <xs:attribute name='job_id' type='xs:string' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='manage_bindings'> <xs:element name='manage_bindings'>
<xs:complexType> <xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/> <xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:element ref='binding'/> <xs:element ref='binding'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='binding'> <xs:element name='binding'>
<xs:complexType> <xs:complexType>
<xs:attribute name='name' type='xs:string' use='required'/> <xs:attribute name='name' type='xs:string' use='required'/>
@ -1006,7 +1006,7 @@ while(true) {
<xs:attribute name='vm_id' type='xs:string' use='required'/> <xs:attribute name='vm_id' type='xs:string' use='required'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='malformed_packet' type='empty'/> <xs:element name='malformed_packet' type='empty'/>
<xs:element name='wrong_farm_password' type='empty'/> <xs:element name='wrong_farm_password' type='empty'/>
<xs:element name='internal_error' type='empty'/> <xs:element name='internal_error' type='empty'/>

2
inbox/message-retraction.xml
View File

@ -41,7 +41,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>Occasionally, a &xep0045; room moderator or admin might wish to retract certain chat messages from the room history as part of an effort to address and remedy issues such as message spam, indecent language for the venue, exposing private third-party personal information, etc. However, as with any content moderation tool, the retraction request can <strong>only be considered as a hint</strong> and by itself can not prevent or undo any potential damage caused by the offending message, as clients which don't support message deletion are not obligated to enforce the deletion request and people could have seen or copied the message content already.</p> <p>Occasionally, a &xep0045; room moderator or admin might wish to retract certain chat messages from the room history as part of an effort to address and remedy issues such as message spam, indecent language for the venue, exposing private third-party personal information, etc. However, as with any content moderation tool, the retraction request can <strong>only be considered as a hint</strong> and by itself can not prevent or undo any potential damage caused by the offending message, as clients which don't support message deletion are not obligated to enforce the deletion request and people could have seen or copied the message content already.</p>
</section1> </section1>
<section1 topic='Discovering support' anchor='disco'> <section1 topic='Discovering support' anchor='disco'>
<p>If a client or service implements message deletion, it MUST specify the 'urn:xmpp:message-retract:0' feature in its service discovery information features as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.</p> <p>If a client or service implements message deletion, it MUST specify the 'urn:xmpp:message-retract:0' feature in its service discovery information features as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.</p>

150
inbox/moved.xml
View File

@ -86,28 +86,28 @@
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>There are a variety of reasons why a user may wish to change <p>There are a variety of reasons why a user may wish to change
their JID. For example, a surname change because of marriage or simply their JID. For example, a surname change because of marriage or simply
an easier JID to remember. an easier JID to remember.
</p> </p>
<p>This XEP defines an approach for communicating that your JID has <p>This XEP defines an approach for communicating that your JID has
moved to a new JID, extending the existing subscription protocol documented moved to a new JID, extending the existing subscription protocol documented
in &rfc3921;. The steps outlined here may be done either through a client in &rfc3921;. The steps outlined here may be done either through a client
or automated by a server. or automated by a server.
</p> </p>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<ul> <ul>
<li>The methods described here maintain compatibility with &rfc3920; and <li>The methods described here maintain compatibility with &rfc3920; and
&rfc3921;</li> &rfc3921;</li>
</ul> </ul>
</section1> </section1>
<section1 topic='The Move'> <section1 topic='The Move'>
<p>In this scenario user@example.com moves to user2@example2.com. <p>In this scenario user@example.com moves to user2@example2.com.
Both the user@example.com and user2@example2.com accounts have been Both the user@example.com and user2@example2.com accounts have been
created and still exist. The roster for user@example2.com is empty created and still exist. The roster for user@example2.com is empty
and the user wants to populate it with their entries from and the user wants to populate it with their entries from
user@example.com.</p> user@example.com.</p>
<dl> <dl>
@ -116,23 +116,23 @@
<dt><strong>new JID</strong></dt> <dt><strong>new JID</strong></dt>
<dd>user2@example2.com</dd> <dd>user2@example2.com</dd>
</dl> </dl>
<section2 topic='Unsubscribing the original JID from outbound subscriptions' <section2 topic='Unsubscribing the original JID from outbound subscriptions'
anchor='unsubscribe'> anchor='unsubscribe'>
<p>Because the original JID is no longer going to be used, the user SHOULD <p>Because the original JID is no longer going to be used, the user SHOULD
unsubscribe from all the outbound subscriptions user@example.com had. unsubscribe from all the outbound subscriptions user@example.com had.
These can be identified as those in the 'to' or 'ask' states as These can be identified as those in the 'to' or 'ask' states as
defined in the 'jabber:iq:roster' protocol in &rfc3921;.</p> defined in the 'jabber:iq:roster' protocol in &rfc3921;.</p>
<p>To unsubscribe all outbound subscriptions for the original JID send an <p>To unsubscribe all outbound subscriptions for the original JID send an
unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED; unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED;
element containing the new JID.</p> element containing the new JID.</p>
<p>There is the potential for other users to send a malicious unsubscribe <p>There is the potential for other users to send a malicious unsubscribe
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza when automatically subscribe to the JID contained in the &MOVED; stanza when
receiving a subscribe &PRESENCE; stanza without displaying the &MOVED; receiving a subscribe &PRESENCE; stanza without displaying the &MOVED;
JID to the user. See the Security Considerations section for JID to the user. See the Security Considerations section for
details.</p> details.</p>
<example caption='Client unsubscribes outbound subscriptions from original JID'> <example caption='Client unsubscribes outbound subscriptions from original JID'>
@ -148,20 +148,20 @@
<section2 topic='Unsubscribing the original JID from inbound subscriptions' <section2 topic='Unsubscribing the original JID from inbound subscriptions'
anchor='unsubscribed'> anchor='unsubscribed'>
<p>Because the original JID is no longer going to be used, the user SHOULD <p>Because the original JID is no longer going to be used, the user SHOULD
unsubscribe from all contacts the user@example.com had an inbound unsubscribe from all contacts the user@example.com had an inbound
subscription from. These can be identified as those in the 'from' subscription from. These can be identified as those in the 'from'
subscription state as defined in in the 'jabber:iq:roster' protocol subscription state as defined in in the 'jabber:iq:roster' protocol
in &rfc3921;.</p> in &rfc3921;.</p>
<p>To unsubscribe all inbound subscriptions send an unsubscribed <p>To unsubscribe all inbound subscriptions send an unsubscribed
&PRESENCE; stanza to all the old contacts with a &MOVED; element &PRESENCE; stanza to all the old contacts with a &MOVED; element
containing the new JID.</p> containing the new JID.</p>
<p>There is the potential for other users to send a malicious unsubscribed <p>There is the potential for other users to send a malicious unsubscribed
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza automatically subscribe to the JID contained in the &MOVED; stanza
without displaying the &MOVED; JID to the user. See the Security without displaying the &MOVED; JID to the user. See the Security
Considerations section for details.</p> Considerations section for details.</p>
<example caption='Client unsubscribes inbound subscriptions from original JID'> <example caption='Client unsubscribes inbound subscriptions from original JID'>
@ -174,27 +174,27 @@
</example> </example>
</section2> </section2>
<section2 topic='Subscribing the new JID to all your existing contacts' <section2 topic='Subscribing the new JID to all your existing contacts'
anchor='subscribe'> anchor='subscribe'>
<p>Once the new JID has been created on a server it is possible for the <p>Once the new JID has been created on a server it is possible for the
new JID to subscribe to the contacts they had on the original JID's new JID to subscribe to the contacts they had on the original JID's
roster. This is done by sending a new subscription request with a roster. This is done by sending a new subscription request with a
&MOVED; element containing the new JID. &MOVED; element containing the new JID.
</p> </p>
<p>The new subscription MUST come from the new JID's server.</p> <p>The new subscription MUST come from the new JID's server.</p>
<p>There is the potential for other users to send a malicious subscribe <p>There is the potential for other users to send a malicious subscribe
request and spoof the content of the &MOVED; element identifying an request and spoof the content of the &MOVED; element identifying an
original JID. Therefore, clients SHOULD NOT automatically unsubscribe original JID. Therefore, clients SHOULD NOT automatically unsubscribe
an existing roster entry if is listed as the target in the &MOVED; an existing roster entry if is listed as the target in the &MOVED;
element when a subscribe is received. See the Security element when a subscribe is received. See the Security
Consideration section for details.</p> Consideration section for details.</p>
<p>Clients accepting the moved subscription SHOULD indicate to the <p>Clients accepting the moved subscription SHOULD indicate to the
user that that this subscription request was the result of a move user that that this subscription request was the result of a move
operation and because of potential malicious behavior SHOULD NOT operation and because of potential malicious behavior SHOULD NOT
auto-accept the subscription without displaying the &MOVED; JID to the auto-accept the subscription without displaying the &MOVED; JID to the
user.</p> user.</p>
@ -208,44 +208,44 @@
</example> </example>
</section2> </section2>
<section2 topic='Contacts Offline at the Time the Rename Occurs' <section2 topic='Contacts Offline at the Time the Rename Occurs'
anchor='offline'> anchor='offline'>
<p>&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza <p>&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza
MUST be preserved by the server and &PRESENCE; stanzas of type MUST be preserved by the server and &PRESENCE; stanzas of type
unsubscribe and unsubscribed are not preserved on the server. unsubscribe and unsubscribed are not preserved on the server.
Therefore, for a contact who is offline, their servers MAY have Therefore, for a contact who is offline, their servers MAY have
automatically removed the original roster entry when seeing the automatically removed the original roster entry when seeing the
unsubscribe and unsubscribed stanzas. At the time of writing this XEP, unsubscribe and unsubscribed stanzas. At the time of writing this XEP,
NOT saving and forwarding the presence stanzas will be the default NOT saving and forwarding the presence stanzas will be the default
behavior of most servers. behavior of most servers.
</p> </p>
<p>What this means is that a contact coming online after the rename <p>What this means is that a contact coming online after the rename
outlined above MAY only see the &PRESENCE; of type 'subscribe' with outlined above MAY only see the &PRESENCE; of type 'subscribe' with
the &MOVED; element. Clients should be aware of this behavior. the &MOVED; element. Clients should be aware of this behavior.
</p> </p>
</section2> </section2>
<section2 topic='Presence Ordering' anchor='ordering'> <section2 topic='Presence Ordering' anchor='ordering'>
<p>In following the principle of least surprise, it is considered good <p>In following the principle of least surprise, it is considered good
practice to send the subscribe stanza after the unsubscribe and unsubscribed practice to send the subscribe stanza after the unsubscribe and unsubscribed
stanzas. stanzas.
</p> </p>
</section2> </section2>
<section2 topic='Preservation of Groups' anchor='grouping'> <section2 topic='Preservation of Groups' anchor='grouping'>
<p>One of the side effects of this scheme is the potential for a contact <p>One of the side effects of this scheme is the potential for a contact
to lose the groups to which it had organized the original JID. Clients to lose the groups to which it had organized the original JID. Clients
aware of the &MOVED; element can mitigate this with the following rules. aware of the &MOVED; element can mitigate this with the following rules.
</p> </p>
<ul> <ul>
<li>If the contacts client receives an unsubscribed with a &MOVED; <li>If the contacts client receives an unsubscribed with a &MOVED;
element, remove the subscription but initiate a roster push for the element, remove the subscription but initiate a roster push for the
original JID with the subscription set to 'none'. When the new original JID with the subscription set to 'none'. When the new
subscription is received the new JID MAY be placed into the roster subscription is received the new JID MAY be placed into the roster
in the same groups as the original JID and the original JID can then be in the same groups as the original JID and the original JID can then be
removed from the roster. removed from the roster.
</li> </li>
@ -254,7 +254,7 @@
</li> </li>
</ul> </ul>
<p>As discussed in 'Contacts Offline at the Time the Rename Occurs', a <p>As discussed in 'Contacts Offline at the Time the Rename Occurs', a
server MAY automatically handle the unsubscribe and unsubscribed stanzas. server MAY automatically handle the unsubscribe and unsubscribed stanzas.
If this occurs it will be impossible to preserve the original groups. If this occurs it will be impossible to preserve the original groups.
</p> </p>
@ -264,10 +264,10 @@
<section2 topic='One-way subcriptions and full roster state' anchor='one-way'> <section2 topic='One-way subcriptions and full roster state' anchor='one-way'>
<section3 topic='One-way Inbound subscription' anchor='from_subs'> <section3 topic='One-way Inbound subscription' anchor='from_subs'>
<p>If the original JID, user@example.com, had only an inbound subscription <p>If the original JID, user@example.com, had only an inbound subscription
(from or pending in), then the contact will only receive an (from or pending in), then the contact will only receive an
unsubscribed &PRESENCE; stanza. The contact's client, knowing the unsubscribed &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'to' or 'none' with 'ask='subscribe' state of the subscription (which is 'to' or 'none' with 'ask='subscribe'
from the contact's perspective), at that point MAY choose to prompt the from the contact's perspective), at that point MAY choose to prompt the
user to subscribe to the new JID listed in the &MOVED; element.</p> user to subscribe to the new JID listed in the &MOVED; element.</p>
<p>Because of the ability to spoof the &MOVED; element, the client SHOULD <p>Because of the ability to spoof the &MOVED; element, the client SHOULD
@ -277,11 +277,11 @@
</section3> </section3>
<section3 topic='One-way Outbound subscription' anchor='to_subs'> <section3 topic='One-way Outbound subscription' anchor='to_subs'>
<p>If the original JID, user@example.com, had only an outbound <p>If the original JID, user@example.com, had only an outbound
subscription (to or ask), then the contact SHOULD only receive an subscription (to or ask), then the contact SHOULD only receive an
unsubscribe &PRESENCE; stanza. The contact's client, knowing the unsubscribe &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'from' from the contact's perspective), state of the subscription (which is 'from' from the contact's perspective),
at that point MAY choose to prompt at that point MAY choose to prompt
the user to subscribe to the new JID listed in the &MOVED; element.</p> the user to subscribe to the new JID listed in the &MOVED; element.</p>
<p>Because of the ability to spoof the &MOVED; element, the client SHOULD <p>Because of the ability to spoof the &MOVED; element, the client SHOULD
@ -289,7 +289,7 @@
</section3> </section3>
<section3 topic='Roster state and action table' anchor='actions'> <section3 topic='Roster state and action table' anchor='actions'>
<table caption="Roster states and actios from the renamed user's perspective"> <table caption="Roster states and actios from the renamed user's perspective">
<tr> <tr>
<td>Server state</td> <td>Server state</td>
<td>Client state (jabber:iq:roster)</td> <td>Client state (jabber:iq:roster)</td>
@ -369,9 +369,9 @@
<p>It is not intended for servers to strip any &MOVED; elements from <p>It is not intended for servers to strip any &MOVED; elements from
&PRESENCE; stanzas sent in from a client. This allows clients as well as &PRESENCE; stanzas sent in from a client. This allows clients as well as
servers to implement these same procedures.</p> servers to implement these same procedures.</p>
<p>In order to prevent other users from maliciously altering contacts <p>In order to prevent other users from maliciously altering contacts
the client SHOULD NOT automatically subscribe to a &MOVED; JID when it the client SHOULD NOT automatically subscribe to a &MOVED; JID when it
receives an unsubscribe and SHOULD NOT automatically unsubscribe to receives an unsubscribe and SHOULD NOT automatically unsubscribe to
a &MOVED; JID when it receives a subscribe.</p> a &MOVED; JID when it receives a subscribe.</p>
@ -379,10 +379,10 @@
<ol> <ol>
<li>userA@example.com subscribes to userB@example.com</li> <li>userA@example.com subscribes to userB@example.com</li>
<li>The userB@example.com automatically accepts the subscription from <li>The userB@example.com automatically accepts the subscription from
userA@example.com. (Automatically done by the client using a simple userA@example.com. (Automatically done by the client using a simple
domain trust).</li> domain trust).</li>
<li>userA@example.com unsubscribes with the &MOVED; 'new' JID set to <li>userA@example.com unsubscribes with the &MOVED; 'new' JID set to
companyCEO@example.com.</li> companyCEO@example.com.</li>
<li>The previous steps can be repeated and have userB@example.com subscribe <li>The previous steps can be repeated and have userB@example.com subscribe
to a large number of people.</li> to a large number of people.</li>
@ -399,19 +399,19 @@
<status>Subscribe to me!</status> <status>Subscribe to me!</status>
<moved xmlns='urn:xmpp:moved:0' old='userA@example.com'/> <moved xmlns='urn:xmpp:moved:0' old='userA@example.com'/>
</presence> </presence>
]]> ]]>
</li> </li>
<li>If userB's client automatically accepted the subscription without <li>If userB's client automatically accepted the subscription without
displaying at prompt to userB showing the new JID to be hacker@example.com, displaying at prompt to userB showing the new JID to be hacker@example.com,
then the user has no idea that hacker@example.com was just added to then the user has no idea that hacker@example.com was just added to
the roster. the roster.
</li> </li>
</ol> </ol>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'> <section1 topic='XMPP Registrar Considerations' anchor='reg'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
@ -419,8 +419,8 @@
<ul> <ul>
<li>urn:xmpp:moved:0</li> <li>urn:xmpp:moved:0</li>
</ul> </ul>
<p>Upon advancement of this specification from a status of Experimental <p>Upon advancement of this specification from a status of Experimental
to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to a status of Draft, the &REGISTRAR; shall add the foregoing namespace
to the registry located at &NAMESPACES;, as described in Section 4 of to the registry located at &NAMESPACES;, as described in Section 4 of
&xep0053;. &xep0053;.
</p> </p>
@ -454,6 +454,6 @@
]]></code> ]]></code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.</p> <p>The author wishes to thank Doug Abbink, Mikhail Belov, Peter Saint-Andre, and Peter Sheu for their feedback.</p>
</section1> </section1>
</xep> </xep>

46
inbox/muc-admin.xml
View File

@ -72,7 +72,7 @@
to='coven@chat.shakespeare.lit' to='coven@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:modify-room-subject'/> node='urn:xmpp:muc-admin:modify-room-subject'/>
</iq> </iq>
@ -84,7 +84,7 @@
to='wiccarocks@shakespeare.lit/laptop' to='wiccarocks@shakespeare.lit/laptop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-room-subject'/> node='urn:xmpp:muc-admin:modify-room-subject'/>
sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05' sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'
status='executing'> status='executing'>
@ -112,7 +112,7 @@
to='coven@chat.shakespeare.lit' to='coven@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-room-subject' node='urn:xmpp:muc-admin:modify-room-subject'
sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'> sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -135,7 +135,7 @@
to='wiccarocks@shakespeare.lit/laptop' to='wiccarocks@shakespeare.lit/laptop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-room-subject' node='urn:xmpp:muc-admin:modify-room-subject'
sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05' sessionid='5981DC80-AF4E-445E-9FF6-0F4067FDCD05'
status='completed'/> status='completed'/>
@ -152,7 +152,7 @@
to='harfleur@chat.shakespeare.lit' to='harfleur@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:modify-occupant-role'/> node='urn:xmpp:muc-admin:modify-occupant-role'/>
</iq> </iq>
@ -164,7 +164,7 @@
to='fluellen@shakespeare.lit/pda' to='fluellen@shakespeare.lit/pda'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-occupant-role'/> node='urn:xmpp:muc-admin:modify-occupant-role'/>
sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE' sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'
status='executing'> status='executing'>
@ -201,7 +201,7 @@
to='harfleur@chat.shakespeare.lit' to='harfleur@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-occupant-role' node='urn:xmpp:muc-admin:modify-occupant-role'
sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'> sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -227,7 +227,7 @@
to='fluellen@shakespeare.lit/pda' to='fluellen@shakespeare.lit/pda'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-occupant-role' node='urn:xmpp:muc-admin:modify-occupant-role'
sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE' sessionid='F4CC8121-DA42-4FDD-8668-17900310D8BE'
status='completed'/> status='completed'/>
@ -243,7 +243,7 @@
to='coven@chat.shakespeare.lit' to='coven@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:modify-user-affiliation'/> node='urn:xmpp:muc-admin:modify-user-affiliation'/>
</iq> </iq>
@ -255,7 +255,7 @@
to='crone1@shakespeare.lit/desktop' to='crone1@shakespeare.lit/desktop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-user-affiliation'/> node='urn:xmpp:muc-admin:modify-user-affiliation'/>
sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2' sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'
status='executing'> status='executing'>
@ -293,7 +293,7 @@
to='coven@chat.shakespeare.lit' to='coven@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-user-affiliation' node='urn:xmpp:muc-admin:modify-user-affiliation'
sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'> sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -319,7 +319,7 @@
to='crone1@shakespeare.lit/desktop' to='crone1@shakespeare.lit/desktop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-user-affiliation' node='urn:xmpp:muc-admin:modify-user-affiliation'
sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2' sessionid='3C5229C9-CD08-46F0-80BF-3BAB604363A2'
status='completed'/> status='completed'/>
@ -335,7 +335,7 @@
to='heath@chat.shakespeare.lit' to='heath@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:assign-occupant-nickname'/> node='urn:xmpp:muc-admin:assign-occupant-nickname'/>
</iq> </iq>
@ -347,7 +347,7 @@
to='crone1@shakespeare.lit/desktop' to='crone1@shakespeare.lit/desktop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:assign-occupant-nickname'/> node='urn:xmpp:muc-admin:assign-occupant-nickname'/>
sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D' sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
status='executing'> status='executing'>
@ -377,7 +377,7 @@
to='coven@chat.shakespeare.lit' to='coven@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:assign-occupant-nickname' node='urn:xmpp:muc-admin:assign-occupant-nickname'
sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D' sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -400,7 +400,7 @@
to='crone1@shakespeare.lit/desktop' to='crone1@shakespeare.lit/desktop'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:assign-occupant-nickname' node='urn:xmpp:muc-admin:assign-occupant-nickname'
sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D' sessionid='53E9C396-64DD-4652-97CF-42E21E857A2D'
status='completed'/> status='completed'/>
@ -416,7 +416,7 @@
to='heath@chat.shakespeare.lit' to='heath@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:clear-room-history'/> node='urn:xmpp:muc-admin:clear-room-history'/>
</iq> </iq>
@ -428,7 +428,7 @@
to='bard@shakespeare.lit/globe' to='bard@shakespeare.lit/globe'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:clear-room-history' node='urn:xmpp:muc-admin:clear-room-history'
status='completed'/> status='completed'/>
</iq> </iq>
@ -443,7 +443,7 @@
to='harfleur@chat.shakespeare.lit' to='harfleur@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='urn:xmpp:muc-admin:spamreport'/> node='urn:xmpp:muc-admin:spamreport'/>
</iq> </iq>
@ -455,7 +455,7 @@
to='fluellen@shakespeare.lit/pda' to='fluellen@shakespeare.lit/pda'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:spamreport'/> node='urn:xmpp:muc-admin:spamreport'/>
sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD' sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'
status='executing'> status='executing'>
@ -480,7 +480,7 @@
to='harfleur@chat.shakespeare.lit' to='harfleur@chat.shakespeare.lit'
type='set' type='set'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:spamreport' node='urn:xmpp:muc-admin:spamreport'
sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'> sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -500,7 +500,7 @@
to='fluellen@shakespeare.lit/pda' to='fluellen@shakespeare.lit/pda'
type='result' type='result'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='urn:xmpp:muc-admin:modify-occupant-role' node='urn:xmpp:muc-admin:modify-occupant-role'
sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD' sessionid='E244DA21-E081-430C-B030-6886FDBCF0CD'
status='completed'/> status='completed'/>
@ -538,7 +538,7 @@
<td>The ad-hoc commands protocol is not supported.</td> <td>The ad-hoc commands protocol is not supported.</td>
</tr> </tr>
</table> </table>
<p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p> <p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>

6
inbox/muc-light.xml
View File

@ -785,7 +785,7 @@
<user affiliation='none'>hag88@shakespeare.lit</user> <user affiliation='none'>hag88@shakespeare.lit</user>
</query> </query>
</iq> </iq>
<message from='coven@muclight.shakespeare.lit' <message from='coven@muclight.shakespeare.lit'
to='crone1@shakespeare.lit' to='crone1@shakespeare.lit'
type='groupchat' type='groupchat'
@ -1215,7 +1215,7 @@
<p>Blocking functionality uses small subset of Privacy Lists protocol. Stanzas MUST be addressed to the server JID and.</p> <p>Blocking functionality uses small subset of Privacy Lists protocol. Stanzas MUST be addressed to the server JID and.</p>
<p>The privacy list name MUST be equal to "urn:xmpp:muclight:0"</p> <p>The privacy list name MUST be equal to "urn:xmpp:muclight:0"</p>
<p>Obviously, this method won't work properly in XMPP Server Federation.</p> <p>Obviously, this method won't work properly in XMPP Server Federation.</p>
<p>As opposed to XEP-0016, it is allowed to send "delta" privacy lists.</p> <p>As opposed to XEP-0016, it is allowed to send "delta" privacy lists.</p>
<section4 topic='Request blocking list' anchor='comp-get-blocking'> <section4 topic='Request blocking list' anchor='comp-get-blocking'>
<example caption='Retrieving blocking list'><![CDATA[ <example caption='Retrieving blocking list'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop' type='get' id='comp-getlist'> <iq from='crone1@shakespeare.lit/desktop' type='get' id='comp-getlist'>
@ -1533,7 +1533,7 @@
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='query'> <xs:element name='query'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>

354
inbox/multi-user_gaming.xml
View File

@ -148,21 +148,21 @@
The owner has limited rights. The match cannot be saved; antonym: Moderated Room.</p> The owner has limited rights. The match cannot be saved; antonym: Moderated Room.</p>
<p>Moderated Room -- <p>Moderated Room --
The owner is allowed to kick users, revoke roles and save the match; antonym: Unmoderated Room.</p> The owner is allowed to kick users, revoke roles and save the match; antonym: Unmoderated Room.</p>
<p>Hidden Room -- <p>Hidden Room --
a room that cannot be found by any user through normal means such as searching and service discovery; a room that cannot be found by any user through normal means such as searching and service discovery;
antonym: Public Room.</p> antonym: Public Room.</p>
<p>Public Room -- <p>Public Room --
a room that can be found by any user through normal means such as searching and service discovery; a room that can be found by any user through normal means such as searching and service discovery;
antonym: Hidden Room.</p> antonym: Hidden Room.</p>
<p>Members-Only Room -- <p>Members-Only Room --
a room that a user cannot enter without being on the member list; a room that a user cannot enter without being on the member list;
antonym: Open Room.</p> antonym: Open Room.</p>
<p>Open Room -- <p>Open Room --
a room that anyone may enter without being on the member list; a room that anyone may enter without being on the member list;
antonym: Members-Only Room.</p> antonym: Members-Only Room.</p>
<p>Password-Protected Room -- <p>Password-Protected Room --
a room that a user cannot enter without first providing the correct password; a room that a user cannot enter without first providing the correct password;
antonym: Unsecured Room.</p> antonym: Unsecured Room.</p>
@ -170,14 +170,14 @@
a room that anyone is allowed to enter without first providing the correct password; a room that anyone is allowed to enter without first providing the correct password;
antonym: Password-Protected Room.</p> antonym: Password-Protected Room.</p>
<p>Fully-Anonymous Room -- <p>Fully-Anonymous Room --
a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone,
including the room owner; contrast with Non-Anonymous Room and Semi-Anonymous Room.</p> including the room owner; contrast with Non-Anonymous Room and Semi-Anonymous Room.</p>
<p>Semi-Anonymous Room -- <p>Semi-Anonymous Room --
a room in which an occupant's full JID can be discovered by the room owner only; a room in which an occupant's full JID can be discovered by the room owner only;
contrast with Fully-Anonymous Room and Non-Anonymous Room.</p> contrast with Fully-Anonymous Room and Non-Anonymous Room.</p>
<p>Non-Anonymous Room -- <p>Non-Anonymous Room --
a room in which an occupant's full JID is exposed to all other occupants; a room in which an occupant's full JID is exposed to all other occupants;
contrast with Semi-Anonymous Room and Fully-Anonymous Room.</p> contrast with Semi-Anonymous Room and Fully-Anonymous Room.</p>
</section2> </section2>
@ -195,7 +195,7 @@
<p>active -- within a match, turns are possible, options cannot be changed</p> <p>active -- within a match, turns are possible, options cannot be changed</p>
<p>paused -- halted within a match, turns are not possible, options cannot be changed</p> <p>paused -- halted within a match, turns are not possible, options cannot be changed</p>
</section2> </section2>
<section2 topic='Dramatis Personae' anchor='terms-personae'> <section2 topic='Dramatis Personae' anchor='terms-personae'>
Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest, Most of the examples in this document use the scenario of Miranda and Ferdinand playing chess in Act V, Scene I of Shakespeare's The Tempest,
represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows: represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows:
@ -237,7 +237,7 @@
<p> <p>
Information about affiliations MUST be sent in all presence stanzas generated or reflected by the match and sent to occupants. Information about affiliations MUST be sent in all presence stanzas generated or reflected by the match and sent to occupants.
</p> </p>
<section2 topic='Privileges' anchor='privileges'> <section2 topic='Privileges' anchor='privileges'>
Owners are allowed to do what they like (saving/loading, change match options, etc.) Owners are allowed to do what they like (saving/loading, change match options, etc.)
except in unmoderated matches. This match type restricts the use of owner privileges to specific room statuses. except in unmoderated matches. This match type restricts the use of owner privileges to specific room statuses.
@ -289,8 +289,8 @@
</p> </p>
<section2 topic='Discovering MUG Component Support' anchor='disco-component'> <section2 topic='Discovering MUG Component Support' anchor='disco-component'>
<p> <p>
A Jabber entity may wish to discover if a service implements the A Jabber entity may wish to discover if a service implements the
Multi-User Game protocol; in order to do so, it sends a service Multi-User Game protocol; in order to do so, it sends a service
discovery information ("disco#info") query to the service's JID: discovery information ("disco#info") query to the service's JID:
</p> </p>
<example caption="Client Queries Gaming Service for MUG Support via Disco"><![CDATA[ <example caption="Client Queries Gaming Service for MUG Support via Disco"><![CDATA[
@ -323,11 +323,11 @@
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Discovering Active Rooms' anchor='disco-matches'> <section2 topic='Discovering Active Rooms' anchor='disco-matches'>
<p> <p>
The service discovery items ("disco#items") protocol enables a user to query a The service discovery items ("disco#items") protocol enables a user to query a
service for a list of associated items, which in the case of a game service would service for a list of associated items, which in the case of a game service would
consist of the active game rooms hosted by the service. consist of the active game rooms hosted by the service.
</p> </p>
<example caption="User Queries for Active Rooms"><![CDATA[ <example caption="User Queries for Active Rooms"><![CDATA[
@ -359,9 +359,9 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
If the full list of rooms is large (see &xep0030; for details), If the full list of rooms is large (see &xep0030; for details),
the service MAY return only a partial list of rooms. the service MAY return only a partial list of rooms.
If it does so, it SHOULD include a &lt;set/&gt; element (as defined in &xep0059;) If it does so, it SHOULD include a &lt;set/&gt; element (as defined in &xep0059;)
to indicate that the list is not the full result set. to indicate that the list is not the full result set.
</p> </p>
</section2> </section2>
@ -512,9 +512,9 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
If the full list of rooms is large, If the full list of rooms is large,
the service MAY return only a partial list of rooms. the service MAY return only a partial list of rooms.
If it does so, it SHOULD include a &lt;set/&gt; element (as defined in &xep0059;) If it does so, it SHOULD include a &lt;set/&gt; element (as defined in &xep0059;)
to indicate that the list is not the full result set. to indicate that the list is not the full result set.
</p> </p>
@ -523,8 +523,8 @@
<section2 topic='Querying for Room Information' anchor='disco-matchinfo'> <section2 topic='Querying for Room Information' anchor='disco-matchinfo'>
<p> <p>
Using the disco#info protocol, a user may also query a specific room for Using the disco#info protocol, a user may also query a specific room for
more detailed information about the room. A user MAY do so before entering a more detailed information about the room. A user MAY do so before entering a
room in order to discover the room configuration. room in order to discover the room configuration.
</p> </p>
<example caption="Discovering Game Options of an Active Room"><![CDATA[ <example caption="Discovering Game Options of an Active Room"><![CDATA[
@ -578,8 +578,8 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
A room MUST also return more detailed information in its disco#info response A room MUST also return more detailed information in its disco#info response
using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose
value is "http://jabber.org/protocol/mug#matchinfo". value is "http://jabber.org/protocol/mug#matchinfo".
It MUST include a 'mug#game' field specifiying the namespace of the It MUST include a 'mug#game' field specifiying the namespace of the
game. game.
@ -606,8 +606,8 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
An implementation MAY return a list of existing occupants if that An implementation MAY return a list of existing occupants if that
information is publicly available, or return no list at all if this information is publicly available, or return no list at all if this
information is kept private. information is kept private.
</p> </p>
<example caption='Room Returns Disco Item Results (Items are Public)'><![CDATA[ <example caption='Room Returns Disco Item Results (Items are Public)'><![CDATA[
@ -622,8 +622,8 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
Note: These &lt;item/&gt; elements are qualified by the disco#items namespace, Note: These &lt;item/&gt; elements are qualified by the disco#items namespace,
not the mug namespace; this means that they cannot possess 'role' attributes, not the mug namespace; this means that they cannot possess 'role' attributes,
for example. for example.
</p> </p>
<example caption='Room Returns Empty Disco Item Results (Items are Private)'><![CDATA[ <example caption='Room Returns Empty Disco Item Results (Items are Private)'><![CDATA[
@ -638,16 +638,16 @@
<section2 topic='Querying a Room Occupant' anchor='disco-occupant'> <section2 topic='Querying a Room Occupant' anchor='disco-occupant'>
<p> <p>
If a non-occupant attempts to send a disco request to an address of the form If a non-occupant attempts to send a disco request to an address of the form
&ROOMJID;, a MUG service SHOULD return the request to the entity and specify a &ROOMJID;, a MUG service SHOULD return the request to the entity and specify a
&badrequest; error condition. If an occupant sends such a request, the service &badrequest; error condition. If an occupant sends such a request, the service
MAY pass it through the intended recipient. MAY pass it through the intended recipient.
</p> </p>
</section2> </section2>
<section2 topic='Discovering Client Support for MUG' anchor='disco-client'> <section2 topic='Discovering Client Support for MUG' anchor='disco-client'>
<p> <p>
A Jabber user may want to discover if one of the user's contacts supports the A Jabber user may want to discover if one of the user's contacts supports the
Multi-User Game protocol. This is done using Service Discovery. Multi-User Game protocol. This is done using Service Discovery.
</p> </p>
<example caption='User Queries Contact Regarding MUG Support'><![CDATA[ <example caption='User Queries Contact Regarding MUG Support'><![CDATA[
@ -678,9 +678,9 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
A user may also query a contact regarding which room the contact is in. A user may also query a contact regarding which room the contact is in.
This is done by querying the contact's full JID (&lt;user@host/resource&gt;) This is done by querying the contact's full JID (&lt;user@host/resource&gt;)
while specifying the Service Discovery node while specifying the Service Discovery node
'http://jabber.org/protocol/mug#matches': 'http://jabber.org/protocol/mug#matches':
</p> </p>
<example caption='User Queries Contact for Current Rooms'><![CDATA[ <example caption='User Queries Contact for Current Rooms'><![CDATA[
@ -836,7 +836,7 @@
]]></example> ]]></example>
<p> <p>
Invitations MAY be based on room JIDs rather than bare JIDs Invitations MAY be based on room JIDs rather than bare JIDs
(so that, for example, an occupant could invite someone from one match to (so that, for example, an occupant could invite someone from one match to
another without knowing that person's bare JID). another without knowing that person's bare JID).
Thus the service MUST handle both the invites and declines. Thus the service MUST handle both the invites and declines.
</p> </p>
@ -887,7 +887,7 @@
from='island-chess@games.shakespeare.lit/damsel' from='island-chess@games.shakespeare.lit/damsel'
to='alonso@shakespeare.lit/pda'> to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='owner' role='White'/> <item affiliation='owner' role='White'/>
</game> </game>
</presence> </presence>
@ -895,7 +895,7 @@
from='island-chess@games.shakespeare.lit/lad' from='island-chess@games.shakespeare.lit/lad'
to='alonso@shakespeare.lit/pda'> to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/> <item affiliation='none' role='Black'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
@ -910,7 +910,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples' from='island-chess@games.shakespeare.lit/KingOfNaples'
to='miranda@shakespeare.lit/desktop'> to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/> <item affiliation='none'/>
</game> </game>
</presence> </presence>
@ -918,7 +918,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples' from='island-chess@games.shakespeare.lit/KingOfNaples'
to='ferdinand@shakespeare.lit/laptop'> to='ferdinand@shakespeare.lit/laptop'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/> <item affiliation='none'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
@ -928,23 +928,23 @@
from='island-chess@games.shakespeare.lit/KingOfNaples' from='island-chess@games.shakespeare.lit/KingOfNaples'
to='alonso@shakespeare.lit/pda'> to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/> <item affiliation='none'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
<p> <p>
Note: The order of the presence stanzas sent to the new occupant is important. Note: The order of the presence stanzas sent to the new occupant is important.
The service MUST first send the complete list of the existing occupants to the The service MUST first send the complete list of the existing occupants to the
new occupant and only then send the new occupant's own presence to the new new occupant and only then send the new occupant's own presence to the new
occupant. This helps the client know when it has received the complete occupant. This helps the client know when it has received the complete
"room roster". "room roster".
</p> </p>
</section3> </section3>
<section3 topic="Non-Anonymous Rooms" anchor='enter-nonanon'> <section3 topic="Non-Anonymous Rooms" anchor='enter-nonanon'>
<p> <p>
If the room is non-anonymous, the service MUST send the new occupant's full JID If the room is non-anonymous, the service MUST send the new occupant's full JID
to all occupants using extended presence information in an &GAME; element qualified to all occupants using extended presence information in an &GAME; element qualified
by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child
with a 'jid' attribute specifying the occupant's full JID: with a 'jid' attribute specifying the occupant's full JID:
</p> </p>
<example caption="Service Sends Full JID to all Occupants"><![CDATA[ <example caption="Service Sends Full JID to all Occupants"><![CDATA[
@ -952,7 +952,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples' from='island-chess@games.shakespeare.lit/KingOfNaples'
to='miranda@shakespeare.lit/desktop' to='miranda@shakespeare.lit/desktop'
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item jid='alonso@shakespeare.lit/pda' affiliation='none'/> <item jid='alonso@shakespeare.lit/pda' affiliation='none'/>
</game> </game>
</presence> </presence>
@ -961,24 +961,24 @@
</section3> </section3>
<section3 topic="Semi-Anonymous Rooms" anchor='enter-semianon'> <section3 topic="Semi-Anonymous Rooms" anchor='enter-semianon'>
<p> <p>
If the room is semi-anonymous, the service MUST send presence from the new occupant If the room is semi-anonymous, the service MUST send presence from the new occupant
to all occupants as specified above, but MUST include the new occupant's full JID to all occupants as specified above, but MUST include the new occupant's full JID
only in the presence notifications it sends to the room owner and not to any other only in the presence notifications it sends to the room owner and not to any other
occupant. occupant.
</p> </p>
</section3> </section3>
<section3 topic="Fully-Anonymous Rooms" anchor='enter-fullyanon'> <section3 topic="Fully-Anonymous Rooms" anchor='enter-fullyanon'>
<p> <p>
If the room is fully-anonymous, the service MUST send presence from the new occupant If the room is fully-anonymous, the service MUST send presence from the new occupant
to all occupants as specified above, but MUST NOT include the new occupant's full JID to all occupants as specified above, but MUST NOT include the new occupant's full JID
to any other occupant. to any other occupant.
</p> </p>
</section3> </section3>
<section3 topic='Password-Protected Rooms' anchor='enter-pw'> <section3 topic='Password-Protected Rooms' anchor='enter-pw'>
<p> <p>
If the room requires a password and the user did not supply one (or the password If the room requires a password and the user did not supply one (or the password
provided is incorrect), the service MUST deny access to the room and inform the provided is incorrect), the service MUST deny access to the room and inform the
user that they are unauthorized; this is done by returning a presence stanza of user that they are unauthorized; this is done by returning a presence stanza of
type "error" specifying a &notauthorized; error: type "error" specifying a &notauthorized; error:
</p> </p>
<example caption='Service Denies Access Because No Password Provided'><![CDATA[ <example caption='Service Denies Access Because No Password Provided'><![CDATA[
@ -994,11 +994,11 @@
]]></example> ]]></example>
<p> <p>
Passwords SHOULD be supplied with the presence stanza sent when entering the room, Passwords SHOULD be supplied with the presence stanza sent when entering the room,
contained within an &lt;game/&gt; element qualified by the contained within an &lt;game/&gt; element qualified by the
'http://jabber.org/protocol/mug' namespace and containing a &lt;password/&gt; child. 'http://jabber.org/protocol/mug' namespace and containing a &lt;password/&gt; child.
Passwords are to be sent as cleartext; no other authentication methods are supported Passwords are to be sent as cleartext; no other authentication methods are supported
at this time, and any such authentication or authorization methods shall be defined at this time, and any such authentication or authorization methods shall be defined
in a separate specification (see the <link url='#security'>Security Considerations</link> in a separate specification (see the <link url='#security'>Security Considerations</link>
section of this document). section of this document).
</p> </p>
<example caption='User Provides Password On Entering a Room'><![CDATA[ <example caption='User Provides Password On Entering a Room'><![CDATA[
@ -1015,9 +1015,9 @@
</section3> </section3>
<section3 topic='Members-Only Rooms' anchor='enter-members'> <section3 topic='Members-Only Rooms' anchor='enter-members'>
<p> <p>
If the room is members-only but the user is not on the member list, the service MUST If the room is members-only but the user is not on the member list, the service MUST
deny access to the room and inform the user that they are not allowed to enter the deny access to the room and inform the user that they are not allowed to enter the
room; this is done by returning a presence stanza of type "error" specifying a room; this is done by returning a presence stanza of type "error" specifying a
&registration; error condition: &registration; error condition:
</p> </p>
<example caption='Service Denies Access Because User Is Not on Member List'><![CDATA[ <example caption='Service Denies Access Because User Is Not on Member List'><![CDATA[
@ -1034,10 +1034,10 @@
</section3> </section3>
<section3 topic='Nickname Conflict' anchor='enter-conflict'> <section3 topic='Nickname Conflict' anchor='enter-conflict'>
<p> <p>
If the room already contains another user with the nickname desired by the user If the room already contains another user with the nickname desired by the user
seeking to enter the room (or if the nickname is reserved by another user on the seeking to enter the room (or if the nickname is reserved by another user on the
member list), the service MUST deny access to the room and inform the user of the member list), the service MUST deny access to the room and inform the user of the
conflict; this is done by returning a presence stanza of type "error" specifying a conflict; this is done by returning a presence stanza of type "error" specifying a
&conflict; error condition: &conflict; error condition:
</p> </p>
<example caption='Service Denies Access Because of Nick Conflict'><![CDATA[ <example caption='Service Denies Access Because of Nick Conflict'><![CDATA[
@ -1065,9 +1065,9 @@
</section3> </section3>
<section3 topic='Max Users' anchor='enter-maxusers'> <section3 topic='Max Users' anchor='enter-maxusers'>
<p> <p>
If the room has reached its maximum number of occupants, the service SHOULD If the room has reached its maximum number of occupants, the service SHOULD
deny access to the room and inform the user of the restriction; this is done deny access to the room and inform the user of the restriction; this is done
by returning a presence stanza of type "error" specifying a &unavailable; by returning a presence stanza of type "error" specifying a &unavailable;
error condition: error condition:
</p> </p>
<example caption='Service Informs User that Room Occupant Limit Has Been Reached'><![CDATA[ <example caption='Service Informs User that Room Occupant Limit Has Been Reached'><![CDATA[
@ -1088,7 +1088,7 @@
<section3 topic='Locked Room' anchor='enter-locked'> <section3 topic='Locked Room' anchor='enter-locked'>
<p> <p>
If a user attempts to enter a room while it is "locked" (i.e., before the room creator If a user attempts to enter a room while it is "locked" (i.e., before the room creator
provides an initial configuration and therefore before the room officially exists), the provides an initial configuration and therefore before the room officially exists), the
service MUST refuse entry and return an &notfound; error to the user: service MUST refuse entry and return an &notfound; error to the user:
</p> </p>
<example caption='Service Denies Access Because Room Does Not Exist'><![CDATA[ <example caption='Service Denies Access Because Room Does Not Exist'><![CDATA[
@ -1106,8 +1106,8 @@
<section3 topic='Nonexistent Room' anchor='enter-nonexistent'> <section3 topic='Nonexistent Room' anchor='enter-nonexistent'>
<p> <p>
If the room does not already exist when the user seeks to enter it, the service SHOULD If the room does not already exist when the user seeks to enter it, the service SHOULD
create it; however, this is not required, since an implementation or deployment MAY create it; however, this is not required, since an implementation or deployment MAY
choose to restrict the privilege of creating rooms. For details, see the choose to restrict the privilege of creating rooms. For details, see the
<link url='#creatematch'>Creating a Room</link> section of this document. <link url='#creatematch'>Creating a Room</link> section of this document.
</p> </p>
</section3> </section3>
@ -1123,7 +1123,7 @@
from='ferdinand@shakespeare.lit/laptop' from='ferdinand@shakespeare.lit/laptop'
to='island-chess@games.shakespeare.lit'> to='island-chess@games.shakespeare.lit'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item role='Black'/> <item role='Black'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
@ -1136,7 +1136,7 @@
from='island-chess@games.shakespeare.lit/lad' from='island-chess@games.shakespeare.lit/lad'
to='miranda@shakespeare.lit/desktop'> to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/> <item affiliation='none' role='Black'/>
</game> </game>
</presence> </presence>
@ -1144,7 +1144,7 @@
from='island-chess@games.shakespeare.lit/lad' from='island-chess@games.shakespeare.lit/lad'
to='ferdinand@shakespeare.lit/laptop'> to='ferdinand@shakespeare.lit/laptop'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/> <item affiliation='none' role='Black'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
@ -1154,11 +1154,11 @@
from='island-chess@games.shakespeare.lit/lad' from='island-chess@games.shakespeare.lit/lad'
to='alonso@shakespeare.lit/pda'> to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/> <item affiliation='none' role='Black'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
<p>If the role is already taken, the service must return the following error.</p> <p>If the role is already taken, the service must return the following error.</p>
<example caption="Service Informs User About Role Conflict"><![CDATA[ <example caption="Service Informs User About Role Conflict"><![CDATA[
@ -1170,7 +1170,7 @@
<error type='cancel'> <error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
]]></example> ]]></example>
<p> <p>
If the requested role doesn't exist in the match, the service MUST return a not-acceptable error. If the requested role doesn't exist in the match, the service MUST return a not-acceptable error.
@ -1193,7 +1193,7 @@
]]></example> ]]></example>
<p> <p>
In order to see what players are ready to start, the service MUST reflect In order to see what players are ready to start, the service MUST reflect
the start message from each player to all players. the start message from each player to all players.
</p> </p>
@ -1232,7 +1232,7 @@
it MUST update the match status from inactive to active by a it MUST update the match status from inactive to active by a
presence broadcast to all occupants. presence broadcast to all occupants.
If the owner changes the configuration or roles change after a player sent his message If the owner changes the configuration or roles change after a player sent his message
and before the service sends presence broadcast indicating the game status active, and before the service sends presence broadcast indicating the game status active,
the player MUST send the message again. the player MUST send the message again.
</p> </p>
@ -1420,7 +1420,7 @@
</message> </message>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Resignation' anchor='mug-resign'> <section2 topic='Resignation' anchor='mug-resign'>
<p> <p>
If a client wants to resign, he sends the following. If a client wants to resign, he sends the following.
@ -1440,7 +1440,7 @@
based on the game specification. based on the game specification.
</p> </p>
</section2> </section2>
<section2 topic='Termination' anchor='mug-term'> <section2 topic='Termination' anchor='mug-term'>
<p> <p>
The game protocol respectively the game protocol implementation decides when a match is over. The game protocol respectively the game protocol implementation decides when a match is over.
@ -1478,9 +1478,9 @@
<state xmlns='http://jabber.org/protocol/mug/chess'> <state xmlns='http://jabber.org/protocol/mug/chess'>
<won>Black</won> <won>Black</won>
</state> </state>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
<section2 topic="Changing Nickname"> <section2 topic="Changing Nickname">
@ -1538,9 +1538,9 @@
<section2 topic='Sending a Private Message' anchor='privatemessage'> <section2 topic='Sending a Private Message' anchor='privatemessage'>
<p> <p>
Since each occupant has a unique room JID, an occupant MAY send a "private message" to a Since each occupant has a unique room JID, an occupant MAY send a "private message" to a
selected occupant via the service by sending a message to the occupant's match JID. The message selected occupant via the service by sending a message to the occupant's match JID. The message
type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege
SHOULD be allowed to any occupant (even a spectator in a moderated room). SHOULD be allowed to any occupant (even a spectator in a moderated room).
</p> </p>
<example caption='Occupant Sends Private Message'><![CDATA[ <example caption='Occupant Sends Private Message'><![CDATA[
@ -1552,7 +1552,7 @@
</message> </message>
]]></example> ]]></example>
<p> <p>
The service is responsible for changing the 'from' address to the sender's match JID and The service is responsible for changing the 'from' address to the sender's match JID and
delivering the message to the intended recipient's full JID. delivering the message to the intended recipient's full JID.
</p> </p>
<example caption='Recipient Receives the Private Message'><![CDATA[ <example caption='Recipient Receives the Private Message'><![CDATA[
@ -1564,18 +1564,18 @@
</message> </message>
]]></example> ]]></example>
<p> <p>
If the sender attempts to send a private message to a room JID that does not exist, If the sender attempts to send a private message to a room JID that does not exist,
the service MUST return an &notfound; error to the sender. the service MUST return an &notfound; error to the sender.
</p> </p>
<p> <p>
If the sender is not an occupant of the room in which the intended recipient is visiting, If the sender is not an occupant of the room in which the intended recipient is visiting,
the service MUST return a &notacceptable; error to the sender. the service MUST return a &notacceptable; error to the sender.
</p> </p>
</section2> </section2>
<section2 topic='Getting Member List' anchor='getmemberlist'> <section2 topic='Getting Member List' anchor='getmemberlist'>
<p> <p>
If allowed in accordance with room configuration, an occupant MAY be allowed to If allowed in accordance with room configuration, an occupant MAY be allowed to
retrieve the list of room members. For details, see the retrieve the list of room members. For details, see the
<link url='#modifymember'>Modifying the Member List</link> section of this document. <link url='#modifymember'>Modifying the Member List</link> section of this document.
</p> </p>
</section2> </section2>
@ -1662,9 +1662,9 @@
<state xmlns='http://jabber.org/protocol/mug/chess'> <state xmlns='http://jabber.org/protocol/mug/chess'>
<match-canceled /> <match-canceled />
</state> </state>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
@ -1688,7 +1688,7 @@
and the room cannot be created, and the room cannot be created,
the service MUST reply with the following error. the service MUST reply with the following error.
</p> </p>
<example caption='Service Informs User of Inability to Create a Room'><![CDATA[ <example caption='Service Informs User of Inability to Create a Room'><![CDATA[
<presence <presence
from='island-chess@games.shakespeare.lit/damsel' from='island-chess@games.shakespeare.lit/damsel'
@ -1703,8 +1703,8 @@
]]></example> ]]></example>
<p> <p>
If a game element or the var attribute with the game namespace is If a game element or the var attribute with the game namespace is
missing then the service MUST deny creating a room and send a missing then the service MUST deny creating a room and send a
presence with a bad request error back to the user. presence with a bad request error back to the user.
</p> </p>
@ -1733,7 +1733,7 @@
from='island-chess@games.shakespeare.lit/damsel'> from='island-chess@games.shakespeare.lit/damsel'>
to='miranda@shakespeare.lit/desktop'> to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'> <game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='owner' role='White'/> <item affiliation='owner' role='White'/>
</game> </game>
</presence> </presence>
]]></example> ]]></example>
@ -1804,7 +1804,7 @@
type='result'> type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'> <query xmlns='http://jabber.org/protocol/mug#owner'>
<options> <options>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Configuration for "Island Chess" Room</title> <title>Configuration for "Island Chess" Room</title>
<instructions> <instructions>
Your room island-chess@games.shakespeare.lit has been created! Your room island-chess@games.shakespeare.lit has been created!
@ -1907,7 +1907,7 @@
var='mug#roomconfig_chat'/> var='mug#roomconfig_chat'/>
</x> </x>
<options xmlns='http://jabber.org/protocol/mug/chess'> <options xmlns='http://jabber.org/protocol/mug/chess'>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Configuration for Chess Game</title> <title>Configuration for Chess Game</title>
<instructions> <instructions>
The default configuration is as follows: The default configuration is as follows:
@ -1949,7 +1949,7 @@
type='result'> type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'> <query xmlns='http://jabber.org/protocol/mug#owner'>
<options> <options>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'> <field var='FORM_TYPE'>
<value>http://jabber.org/protocol/mug#roomconfig</value> <value>http://jabber.org/protocol/mug#roomconfig</value>
</field> </field>
@ -1986,7 +1986,7 @@
<field var='mug#roomconfig_chat'/> <field var='mug#roomconfig_chat'/>
</x> </x>
<options xmlns='http://jabber.org/protocol/mug/chess'> <options xmlns='http://jabber.org/protocol/mug/chess'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'> <field var='FORM_TYPE'>
<value>http://jabber.org/protocol/mug/chess#chessconfig</value> <value>http://jabber.org/protocol/mug/chess#chessconfig</value>
@ -2052,7 +2052,7 @@
</error> </error>
</iq> </iq>
]]></example> ]]></example>
<p>Alternatively, the room owner MAY cancel the configuration process:</p> <p>Alternatively, the room owner MAY cancel the configuration process:</p>
<example caption='Owner Cancels Initial Configuration'><![CDATA[ <example caption='Owner Cancels Initial Configuration'><![CDATA[
@ -2065,7 +2065,7 @@
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p> <p>
If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details). If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).
</p> </p>
@ -2095,7 +2095,7 @@
type='result'> type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'> <query xmlns='http://jabber.org/protocol/mug#owner'>
<options> <options>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Configuration for "Island Chess" Room</title> <title>Configuration for "Island Chess" Room</title>
<instructions> <instructions>
To select a different configuration, please complete To select a different configuration, please complete
@ -2186,7 +2186,7 @@
</field> </field>
</x> </x>
<options xmlns='http://jabber.org/protocol/mug/chess'> <options xmlns='http://jabber.org/protocol/mug/chess'>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Configuration for Chess Game</title> <title>Configuration for Chess Game</title>
<instructions> <instructions>
The default configuration is as follows: The default configuration is as follows:
@ -2252,7 +2252,7 @@
</section3> </section3>
</section2> </section2>
<section2 topic='Room Saving' anchor='mug-save'> <section2 topic='Room Saving' anchor='mug-save'>
<p> <p>
@ -2326,20 +2326,20 @@
<section2 topic='Modifying the Member List' anchor='modifymember'> <section2 topic='Modifying the Member List' anchor='modifymember'>
<p> <p>
In the context of a members-only match, the member list is essentially a In the context of a members-only match, the member list is essentially a
"whitelist" of people who are allowed to enter the match. Anyone who is not "whitelist" of people who are allowed to enter the match. Anyone who is not
a member is effectively banned from entering the match. a member is effectively banned from entering the match.
</p> </p>
<p> <p>
In the context of an open match, the member list is simply a list of users In the context of an open match, the member list is simply a list of users
(bare JID and reserved nick) who are registered with the match. Such users (bare JID and reserved nick) who are registered with the match. Such users
may appear in a match roster, have their match nickname reserved, be may appear in a match roster, have their match nickname reserved, be
returned in search results, and the like. returned in search results, and the like.
</p> </p>
<p> <p>
It is RECOMMENDED that only the room owner It is RECOMMENDED that only the room owner
has the privilege to modify the member list in members-only rooms. has the privilege to modify the member list in members-only rooms.
To do so, the owner first requests the member list by querying the room To do so, the owner first requests the member list by querying the room
for all users with an affiliation of "member": for all users with an affiliation of "member":
</p> </p>
<example caption='Owner Requests Member List'><![CDATA[ <example caption='Owner Requests Member List'><![CDATA[
@ -2353,18 +2353,18 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
Note: A service SHOULD also return the member list to any occupant in a Note: A service SHOULD also return the member list to any occupant in a
members-only room; i.e., it SHOULD NOT generate a &forbidden; error when members-only room; i.e., it SHOULD NOT generate a &forbidden; error when
a member in the room requests the member list. a member in the room requests the member list.
This functionality may assist clients in showing all the existing members This functionality may assist clients in showing all the existing members
even if some of them are not in the room, e.g. to help a member determine even if some of them are not in the room, e.g. to help a member determine
if another user should be invited. if another user should be invited.
A service SHOULD also allow any member to retrieve the member list even A service SHOULD also allow any member to retrieve the member list even
if not yet an occupant. if not yet an occupant.
</p> </p>
<p> <p>
The service MUST then return the full member list to the owner qualified The service MUST then return the full member list to the owner qualified
by the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST by the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST
include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and
'role' attributes for each members that is currently an occupant. 'role' attributes for each members that is currently an occupant.
</p> </p>
@ -2381,10 +2381,10 @@
</iq> </iq>
]]></example> ]]></example>
<p> <p>
The owner MAY then modify the member list. In order to do so, the owner MUST The owner MAY then modify the member list. In order to do so, the owner MUST
send the changed items (i.e., only the "delta") to the service; each item MUST send the changed items (i.e., only the "delta") to the service; each item MUST
include the 'affiliation' attribute (normally set to a value of "member" or "none") include the 'affiliation' attribute (normally set to a value of "member" or "none")
and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include
the 'role' attribute (which is used to manage game roles in a room): the 'role' attribute (which is used to manage game roles in a room):
</p> </p>
<example caption='Owner Sends Modified Member List to Service'><![CDATA[ <example caption='Owner Sends Modified Member List to Service'><![CDATA[
@ -2410,22 +2410,22 @@
type='result'/> type='result'/>
]]></example> ]]></example>
<p> <p>
The service MUST change the affiliation of any affected user. The service MUST change the affiliation of any affected user.
If the user has been removed from the member list, the service MUST change the user's If the user has been removed from the member list, the service MUST change the user's
affiliation from "member" to "none". affiliation from "member" to "none".
If the user has been added to the member list, the service MUST change the user's affiliation to "member". If the user has been added to the member list, the service MUST change the user's affiliation to "member".
</p> </p>
<p> <p>
If a removed member is currently in a members-only room, the service SHOULD kick If a removed member is currently in a members-only room, the service SHOULD kick
the occupant by changing the removed member's affiliation to "none" and send appropriate the occupant by changing the removed member's affiliation to "none" and send appropriate
presence to the removed member as previously described. presence to the removed member as previously described.
No matter whether the removed member was in or out of a members-only room, the service MUST No matter whether the removed member was in or out of a members-only room, the service MUST
subsequently refuse entry to the user. subsequently refuse entry to the user.
</p> </p>
<p> <p>
For all room types, the service MUST send updated presence from this individual to all occupants, For all room types, the service MUST send updated presence from this individual to all occupants,
indicating the change in affiliation by including an &lt;game/&gt; element qualified by the indicating the change in affiliation by including an &lt;game/&gt; element qualified by the
'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the 'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the
'affiliation' attribute set to a value of "none". 'affiliation' attribute set to a value of "none".
</p> </p>
<example caption="Service Sends Notice of Loss of Membership to All Occupants"><![CDATA[ <example caption="Service Sends Notice of Loss of Membership to All Occupants"><![CDATA[
@ -2437,13 +2437,13 @@
</game> </game>
</presence> </presence>
... ...
]]></example> ]]></example>
<p> <p>
In addition, the service SHOULD send an invitation to any user who has been added to the In addition, the service SHOULD send an invitation to any user who has been added to the
member list of a members-only room if the user is not currently affiliated with the member list of a members-only room if the user is not currently affiliated with the
room, for example as an owner (such a user would by definition not be room, for example as an owner (such a user would by definition not be
in the match; note also that this example includes a password but not a reason -- in the match; note also that this example includes a password but not a reason --
both child elements are OPTIONAL): both child elements are OPTIONAL):
</p> </p>
<example caption='Room Sends Invitation to New Member'><![CDATA[ <example caption='Room Sends Invitation to New Member'><![CDATA[
@ -2458,12 +2458,12 @@
</message> </message>
]]></example> ]]></example>
<p> <p>
While only the owner SHOULD be allowed to modify the member list, While only the owner SHOULD be allowed to modify the member list,
an implementation MAY provide a configuration option that opens invitation privileges an implementation MAY provide a configuration option that opens invitation privileges
to any member of a members-only match. In such a situation, any invitation sent SHOULD to any member of a members-only match. In such a situation, any invitation sent SHOULD
automatically trigger the addition of the invitee to the member list. automatically trigger the addition of the invitee to the member list.
However, if invitation privileges are restricted to the owner and a mere member attempts However, if invitation privileges are restricted to the owner and a mere member attempts
to a send an invitation, the service MUST deny the invitation request and return a to a send an invitation, the service MUST deny the invitation request and return a
&forbidden; error to the sender: &forbidden; error to the sender:
</p> </p>
<example caption='Service Returns Error on Attempt by Mere Member to Invite Others to a Members-Only Match'><![CDATA[ <example caption='Service Returns Error on Attempt by Mere Member to Invite Others to a Members-Only Match'><![CDATA[
@ -2483,14 +2483,14 @@
</message> </message>
]]></example> ]]></example>
<p> <p>
Invitations sent through an open room MUST NOT trigger the addition of the invitee Invitations sent through an open room MUST NOT trigger the addition of the invitee
to the member list. to the member list.
</p> </p>
<p> <p>
If a user is added to the member list of an open room and the user is in the room, If a user is added to the member list of an open room and the user is in the room,
the service MUST send updated presence from this individual to all occupants, the service MUST send updated presence from this individual to all occupants,
indicating the change in affiliation by including an &lt;game/&gt; element qualified by indicating the change in affiliation by including an &lt;game/&gt; element qualified by
the 'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; the 'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt;
child with the 'affiliation' attribute set to a value of "member". child with the 'affiliation' attribute set to a value of "member".
</p> </p>
<example caption="Service Sends Notice of Membership to All Occupants"><![CDATA[ <example caption="Service Sends Notice of Membership to All Occupants"><![CDATA[
@ -2509,7 +2509,7 @@
<section2 topic='Revoke and Assign Roles' anchor='modifyroles'> <section2 topic='Revoke and Assign Roles' anchor='modifyroles'>
<p> <p>
The room owner may decide to modify the assigned game roles in a room. The room owner may decide to modify the assigned game roles in a room.
To do so, the owner first requests a list of the occupants To do so, the owner first requests a list of the occupants
and assigned roles by querying the room: and assigned roles by querying the room:
</p> </p>
<example caption='Owner Requests List of All Occupants and Assigned Roles'><![CDATA[ <example caption='Owner Requests List of All Occupants and Assigned Roles'><![CDATA[
@ -2527,10 +2527,10 @@
active players and MUST NOT be redefined by games for other purposes. active players and MUST NOT be redefined by games for other purposes.
</p> </p>
<p> <p>
The service SHOULD then return the full list of all occupants qualified by The service SHOULD then return the full list of all occupants qualified by
the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST include the the 'http://jabber.org/protocol/mug#owner' namespace; each item MUST include the
'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each 'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each
occupant in the room. occupant in the room.
</p> </p>
<example caption='Service Sends List of Occupants and Assigned Roles to Owner'><![CDATA[ <example caption='Service Sends List of Occupants and Assigned Roles to Owner'><![CDATA[
<iq from='island-chess@games.shakespeare.lit' <iq from='island-chess@games.shakespeare.lit'
@ -2553,9 +2553,9 @@
</p> </p>
<p> <p>
The owner MAY then modify the roles assigned by occupants. The owner MAY then modify the roles assigned by occupants.
In order to do so, the owner MUST send the changed items (i.e., only the "delta") to the service; In order to do so, the owner MUST send the changed items (i.e., only the "delta") to the service;
each item MUST include the 'roles' attribute each item MUST include the 'roles' attribute
and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include
the 'affiliation' attribute: the 'affiliation' attribute:
</p> </p>
<example caption='Owner Sends Modified List of Assigned Roles to Service'><![CDATA[ <example caption='Owner Sends Modified List of Assigned Roles to Service'><![CDATA[
@ -2582,9 +2582,9 @@
]]></example> ]]></example>
<p> <p>
The service MUST change the roles of any affected user and The service MUST change the roles of any affected user and
MUST send updated presence to all occupants, MUST send updated presence to all occupants,
indicating the changed role by including an &lt;game/&gt; element qualified by the indicating the changed role by including an &lt;game/&gt; element qualified by the
'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the 'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the
'role' attribute. 'role' attribute.
</p> </p>
<example caption="Service Sends Notice of Changed Roles to All Occupants"><![CDATA[ <example caption="Service Sends Notice of Changed Roles to All Occupants"><![CDATA[
@ -2596,7 +2596,7 @@
</game> </game>
</presence> </presence>
... ...
]]></example> ]]></example>
</section2> </section2>
@ -2649,7 +2649,7 @@
<p>OPTIONAL.</p> <p>OPTIONAL.</p>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<p>The following guidelines may assist client and component developers in creating MUG implementations.</p> <p>The following guidelines may assist client and component developers in creating MUG implementations.</p>
<section2 topic='Services' anchor='impl-services'> <section2 topic='Services' anchor='impl-services'>
@ -2675,7 +2675,7 @@
<li> <li>
<p> <p>
The game service MAY offer a managed multi-user chatroom. The game service MAY offer a managed multi-user chatroom.
This can be done by creating a new chat room and keep membership This can be done by creating a new chat room and keep membership
synchronized with the game room. synchronized with the game room.
</p> </p>
</li> </li>
@ -2710,7 +2710,7 @@
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p> <p>
If this protocol will be accepted by the XMPP Standards Foundation, the &REGISTRAR; If this protocol will be accepted by the XMPP Standards Foundation, the &REGISTRAR;
should includes the following information in its registries. should includes the following information in its registries.
</p> </p>
<!-- <p> <!-- <p>
@ -2729,17 +2729,17 @@
<section2 topic='Service Discovery Category/Type' anchor='registrar-discocat'> <section2 topic='Service Discovery Category/Type' anchor='registrar-discocat'>
<p> <p>
A Multi-User Game service or match is identified by the "game" category A Multi-User Game service or match is identified by the "game" category
and the "multi-user" type within Service Discovery. and the "multi-user" type within Service Discovery.
</p> </p>
</section2> </section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'> <section2 topic='Service Discovery Features' anchor='registrar-features'>
<p> <p>
There are many features related to a MUG service or match that can be There are many features related to a MUG service or match that can be
discovered by means of Service Discovery. The most fundamental of these discovered by means of Service Discovery. The most fundamental of these
is the 'http://jabber.org/protocol/mug' namespace. In addition, a MUG match is the 'http://jabber.org/protocol/mug' namespace. In addition, a MUG match
SHOULD provide information about the specific match features it implements, SHOULD provide information about the specific match features it implements,
such as password protection and match moderation. such as password protection and match moderation.
</p> </p>
<!-- <p> <!-- <p>
@ -2756,7 +2756,7 @@
xmpp:island-chess@games.shakespeare.lit?play xmpp:island-chess@games.shakespeare.lit?play
]]></example> ]]></example>
<p> <p>
The application MUST either present an interface enabling the user to provide a room nickname The application MUST either present an interface enabling the user to provide a room nickname
or populate the room nickname based on configured preferences or nickname discovery. or populate the room nickname based on configured preferences or nickname discovery.
</p> </p>
<p> <p>
@ -2771,14 +2771,14 @@ xmpp:island-chess@games.shakespeare.lit?play
</presence> </presence>
]]></example> ]]></example>
<p> <p>
In order to avoid sending the service discovery query, In order to avoid sending the service discovery query,
the play action SHOULD include the game namespace for the room. the play action SHOULD include the game namespace for the room.
</p> </p>
<example caption="Play Action with Game: IRI/URI"><![CDATA[ <example caption="Play Action with Game: IRI/URI"><![CDATA[
xmpp:island-chess@games.shakespeare.lit?play;game=http://jabber.org/protocol/mug/chess xmpp:island-chess@games.shakespeare.lit?play;game=http://jabber.org/protocol/mug/chess
]]></example> ]]></example>
<p> <p>
The play action MAY include a password for the room. The play action MAY include a password for the room.
Naturally, access to a URI that includes a room password MUST be appropriately controlled. Naturally, access to a URI that includes a room password MUST be appropriately controlled.
</p> </p>
<example caption="Play Action: IRI/URI"><![CDATA[ <example caption="Play Action: IRI/URI"><![CDATA[

2
inbox/peptzo.xml
View File

@ -108,7 +108,7 @@
<section2 topic='Protocol Versioning' anchor='registrar-versioning'> <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER; &NSVER;
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>

4
inbox/pubsub-since.xml
View File

@ -90,7 +90,7 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
@ -105,7 +105,7 @@
<var> <var>
<name>http://jabber.org/protocol/pubsub#since</name> <name>http://jabber.org/protocol/pubsub#since</name>
<desc> <desc>
The pubsub or PEP service sends interim notifications upon receiving The pubsub or PEP service sends interim notifications upon receiving
initial presence containing the subscriber's last logout time. initial presence containing the subscriber's last logout time.
</desc> </desc>
<doc>XEP-xxxx</doc> <doc>XEP-xxxx</doc>

78
inbox/qos.xml
View File

@ -4,9 +4,9 @@
%ents; %ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!-- <!--
© XMPP Standards Foundation, 2015 © XMPP Standards Foundation, 2015
Author: Peter Waher Author: Peter Waher
--> -->
<xep> <xep>
<header> <header>
@ -89,7 +89,7 @@ Author: Peter Waher
</p> </p>
<p> <p>
Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is
pressed, whenever an event has occurred or a transaction. If counting events, transactions, or accumulating consumption, it is pressed, whenever an event has occurred or a transaction. If counting events, transactions, or accumulating consumption, it is
vital that messages are not processed twice, since it will change the end result. vital that messages are not processed twice, since it will change the end result.
</p> </p>
</dd> </dd>
@ -109,13 +109,13 @@ Author: Peter Waher
</p> </p>
<example caption='Sensor sending a momentary value'> <example caption='Sensor sending a momentary value'>
<![CDATA[ <![CDATA[
<message <message
from='temperaturesensor@example.org/34892374' from='temperaturesensor@example.org/34892374'
to='user@example.org/938089023'> to='user@example.org/938089023'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'> <fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>
<node nodeId='Temp01'> <node nodeId='Temp01'>
<timestamp value='2015-11-11T22:01:30'> <timestamp value='2015-11-11T22:01:30'>
<numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/> <numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/>
</timestamp> </timestamp>
</node> </node>
</fields> </fields>
@ -124,16 +124,16 @@ Author: Peter Waher
</section2> </section2>
<section2 topic='Acknowledged service - At least once' anchor='ack'> <section2 topic='Acknowledged service - At least once' anchor='ack'>
<p> <p>
To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an
acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered. acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered.
The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged
message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response. message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response.
If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off
algorithm. These time frames and number of attempts are implementation specific. algorithm. These time frames and number of attempts are implementation specific.
</p> </p>
<p> <p>
It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more
than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered. than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered.
The At least once QoS level requires twice as many messages to be transported in the network as compared to The At least once QoS level requires twice as many messages to be transported in the network as compared to
the At most once QoS level. the At most once QoS level.
</p> </p>
@ -144,7 +144,7 @@ Author: Peter Waher
</p> </p>
<example caption='Setting light level'> <example caption='Setting light level'>
<![CDATA[ <![CDATA[
<iq id='123' type='set' <iq id='123' type='set'
from='controller@example.org/34892374' from='controller@example.org/34892374'
to='lightswitch@example.org/938089023'> to='lightswitch@example.org/938089023'>
<qos:acknowledged xmlns:qos='urn:xmpp:qos'> <qos:acknowledged xmlns:qos='urn:xmpp:qos'>
@ -155,7 +155,7 @@ Author: Peter Waher
</message> </message>
</qos:acknowledged> </qos:acknowledged>
</iq> </iq>
<iq id='123' type='result' <iq id='123' type='result'
from='lightswitch@example.org/938089023' from='lightswitch@example.org/938089023'
to='controller@example.org/34892374'/> to='controller@example.org/34892374'/>
@ -177,14 +177,14 @@ Author: Peter Waher
memory. Still, the received response is returned as normal. memory. Still, the received response is returned as normal.
</p> </p>
<p> <p>
When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload, When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload,
to tell the receiving end to parse and deliver the message, if in memory, and remove it from memory. The receiver acknowledges the message to tell the receiving end to parse and deliver the message, if in memory, and remove it from memory. The receiver acknowledges the message
by returning an empty iq result stanza. If receiving multiple requests using the same msgId, it will acknowledge each one. But by returning an empty iq result stanza. If receiving multiple requests using the same msgId, it will acknowledge each one. But
only one message will be parsed and delivered, as it will have been removed from the temporary storage on the receiving end. For both the only one message will be parsed and delivered, as it will have been removed from the temporary storage on the receiving end. For both the
assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used. assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used.
</p> </p>
<p> <p>
The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once
QoS level, and four times the number of messages as compared to the At most once QoS level. QoS level, and four times the number of messages as compared to the At most once QoS level.
</p> </p>
<p> <p>
@ -194,7 +194,7 @@ Author: Peter Waher
</p> </p>
<example caption='Counting cars or individuals in a closed space'> <example caption='Counting cars or individuals in a closed space'>
<![CDATA[ <![CDATA[
<iq id='123' type='set' <iq id='123' type='set'
from='entrance@example.org/34892374' from='entrance@example.org/34892374'
to='counter@example.org/938089023'> to='counter@example.org/938089023'>
<qos:assured xmlns:qos='urn:xmpp:qos' msgId='984232334'> <qos:assured xmlns:qos='urn:xmpp:qos' msgId='984232334'>
@ -205,27 +205,27 @@ Author: Peter Waher
</message> </message>
</qos:assured> </qos:assured>
</iq> </iq>
<iq id='123' type='result' <iq id='123' type='result'
from='counter@example.org/938089023'> from='counter@example.org/938089023'>
to='entrance@example.org/34892374'> to='entrance@example.org/34892374'>
<received msgId='984232334'/> <received msgId='984232334'/>
</iq> </iq>
<iq id='124' type='set' <iq id='124' type='set'
from='entrance@example.org/34892374' from='entrance@example.org/34892374'
to='counter@example.org/938089023'> to='counter@example.org/938089023'>
<qos:deliver xmlns:qos='urn:xmpp:qos' msgId='984232334'/> <qos:deliver xmlns:qos='urn:xmpp:qos' msgId='984232334'/>
</iq> </iq>
<iq id='124' type='result' <iq id='124' type='result'
from='counter@example.org/938089023'> from='counter@example.org/938089023'>
to='entrance@example.org/34892374'/> to='entrance@example.org/34892374'/>
</iq> </iq>
... ...
<iq id='456' type='set' <iq id='456' type='set'
from='exit@example.org/34892374' from='exit@example.org/34892374'
to='counter@example.org/938089023'> to='counter@example.org/938089023'>
<qos:assured xmlns:qos='urn:xmpp:qos' msgId='4645623466'> <qos:assured xmlns:qos='urn:xmpp:qos' msgId='4645623466'>
@ -236,19 +236,19 @@ Author: Peter Waher
</message> </message>
</qos:assured> </qos:assured>
</iq> </iq>
<iq id='456' type='result' <iq id='456' type='result'
from='counter@example.org/938089023'> from='counter@example.org/938089023'>
to='exit@example.org/34892374'> to='exit@example.org/34892374'>
<received msgId='4645623466'/> <received msgId='4645623466'/>
</iq> </iq>
<iq id='457' type='set' <iq id='457' type='set'
from='exit@example.org/34892374' from='exit@example.org/34892374'
to='counter@example.org/938089023'> to='counter@example.org/938089023'>
<qos:deliver xmlns:qos='urn:xmpp:qos' msgId='4645623466'/> <qos:deliver xmlns:qos='urn:xmpp:qos' msgId='4645623466'/>
</iq> </iq>
<iq id='457' type='result' <iq id='457' type='result'
from='counter@example.org/938089023'> from='counter@example.org/938089023'>
to='exit@example.org/34892374'/> to='exit@example.org/34892374'/>
@ -296,12 +296,12 @@ Author: Peter Waher
<section2 topic='Offline messages' anchor='offline'> <section2 topic='Offline messages' anchor='offline'>
<p> <p>
When sending messages using unacknowledged service, i.e. using the normal message stanza, it can be subject to offline message When sending messages using unacknowledged service, i.e. using the normal message stanza, it can be subject to offline message
storage if the recipient if offline. This might result in delivery of the message at a later time. storage if the recipient if offline. This might result in delivery of the message at a later time.
</p> </p>
</section2> </section2>
<section2 topic='Resource part' anchor='resource'> <section2 topic='Resource part' anchor='resource'>
<p> <p>
Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service, Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service,
since the first uses the message stanza and the latter two the iq stanza, which require a fill JID in order to reach its destination. since the first uses the message stanza and the latter two the iq stanza, which require a fill JID in order to reach its destination.
For consistency, full JIDs should be used also for unacknowledged messaging service, if possible. For consistency, full JIDs should be used also for unacknowledged messaging service, if possible.
</p> </p>
@ -320,14 +320,14 @@ Author: Peter Waher
or in a database? Such implementation specific concerns are left to the implementor, as this XEP only concerns itself with the communication or in a database? Such implementation specific concerns are left to the implementor, as this XEP only concerns itself with the communication
layer between parties. But the choice of solution might affect to what level a message is ascertained to be delivered: Will delivery be layer between parties. But the choice of solution might affect to what level a message is ascertained to be delivered: Will delivery be
guaranteed, even beyond a system reset at the receiving end? Or a system reset at the sending side? If delivery of the message has to be guaranteed, even beyond a system reset at the receiving end? Or a system reset at the sending side? If delivery of the message has to be
ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side. ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side.
(To some extent, this latter concern even affects acknowledged service.) (To some extent, this latter concern even affects acknowledged service.)
</p> </p>
</section2> </section2>
<section2 topic='Message IDs' anchor='msdId'> <section2 topic='Message IDs' anchor='msdId'>
<p> <p>
Outstanding message IDs used in assured delivery, must be unique for the sender (counting the Full JID as the sender). If running Outstanding message IDs used in assured delivery, must be unique for the sender (counting the Full JID as the sender). If running
short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be
sequence numbers, or hash values of the contents of the message. sequence numbers, or hash values of the contents of the message.
</p> </p>
</section2> </section2>
@ -363,7 +363,7 @@ Author: Peter Waher
<li> <li>
<p> <p>
Set a total limit on the number and size of assured messages that can be simultaneously received from all sources. If anybody Set a total limit on the number and size of assured messages that can be simultaneously received from all sources. If anybody
sends a message that will exceed this amount, the <strong>resource-constraint</strong> error should be returned instead of sends a message that will exceed this amount, the <strong>resource-constraint</strong> error should be returned instead of
accepting the message. accepting the message.
</p> </p>
</li> </li>
@ -392,20 +392,20 @@ Author: Peter Waher
xmlns='urn:xmpp:qos' xmlns='urn:xmpp:qos'
xmlns:jbc='jabber:client' xmlns:jbc='jabber:client'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:import namespace='jabber:client'/> <xs:import namespace='jabber:client'/>
<xs:element name='acknowledged' type='EmbeddedMessage'/> <xs:element name='acknowledged' type='EmbeddedMessage'/>
<xs:element name='assured' type='Assured'/> <xs:element name='assured' type='Assured'/>
<xs:element name='received' type='WithMessageId'/> <xs:element name='received' type='WithMessageId'/>
<xs:element name='deliver' type='WithMessageId'/> <xs:element name='deliver' type='WithMessageId'/>
<xs:complexType name='EmbeddedMessage'> <xs:complexType name='EmbeddedMessage'>
<xs:sequence minOccurs='1' maxOccurs='1'> <xs:sequence minOccurs='1' maxOccurs='1'>
<xs:element ref='jbc:message'/> <xs:element ref='jbc:message'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name='Assured'> <xs:complexType name='Assured'>
<xs:complexContent> <xs:complexContent>
<xs:extension base='EmbeddedMessage'> <xs:extension base='EmbeddedMessage'>
@ -413,13 +413,13 @@ Author: Peter Waher
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:attribute name='msgId' type='xs:string'/> <xs:attribute name='msgId' type='xs:string'/>
<xs:complexType name='WithMessageId'> <xs:complexType name='WithMessageId'>
<xs:attribute ref='msgId' use='required'/> <xs:attribute ref='msgId' use='required'/>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
]]> ]]>
</code> </code>

4
inbox/reputation.xml
View File

@ -188,7 +188,7 @@
to='juliet@capulet.lit/chamber' to='juliet@capulet.lit/chamber'
id='bn4c297j' id='bn4c297j'
type='result'> type='result'>
<score xmlns='urn:xmpp:reputation:0' <score xmlns='urn:xmpp:reputation:0'
jid='romeo@montague.lit' jid='romeo@montague.lit'
num='65'/> num='65'/>
</iq> </iq>
@ -206,7 +206,7 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>

372
inbox/rest.xml
View File

@ -8,8 +8,8 @@
<header> <header>
<title>REST with XMPP</title> <title>REST with XMPP</title>
<abstract>This specification defines how the Representational State Transfer (REST) <abstract>This specification defines how the Representational State Transfer (REST)
architectural style can be applied to an XMPP overlay network. It specifies architectural style can be applied to an XMPP overlay network. It specifies
an XMPP protocol extension for accessing resources and transporting resource metadata and XML-REST encoded an XMPP protocol extension for accessing resources and transporting resource metadata and XML-REST encoded
requests and responses between two XMPP entities.</abstract> requests and responses between two XMPP entities.</abstract>
<legal> <legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF).</copyright> <copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF).</copyright>
@ -45,23 +45,23 @@
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>Representational State Transfer (<cite>REST</cite>) is an architectural style that is a coordinated <p>Representational State Transfer (<cite>REST</cite>) is an architectural style that is a coordinated
set of constraints which also apply to the web. It aims at simplifying component implementations, reducing set of constraints which also apply to the web. It aims at simplifying component implementations, reducing
the complexity of distributed software elements, improving the performance, and increasing the the complexity of distributed software elements, improving the performance, and increasing the
scalability. In relation to the definition of a RESTful application programming interface (API) scalability. In relation to the definition of a RESTful application programming interface (API)
the uniform interface constraint is of high importance. It simplifies and decouples the architecture the uniform interface constraint is of high importance. It simplifies and decouples the architecture
and makes REST components independent. The constraints for a uniform interface can be reduced to: and makes REST components independent. The constraints for a uniform interface can be reduced to:
the identification of resources, the self-descriptive representation of resources, and the the identification of resources, the self-descriptive representation of resources, and the
self-descriptive manipulation of resources.</p> self-descriptive manipulation of resources.</p>
<p>REST systems typically communicate over the Hypertext Transfer Protocol (HTTP) and are gaining <p>REST systems typically communicate over the Hypertext Transfer Protocol (HTTP) and are gaining
large acceptance due to its large acceptance due to its
growing support and its simplicity for implementation. RESTful web services growing support and its simplicity for implementation. RESTful web services
are in this context a simpler alternative to &w3soap; and WSDL-based Web services which are specified are in this context a simpler alternative to &w3soap; and WSDL-based Web services which are specified
for the use with XMPP for the use with XMPP
in &xep0072; and also a more powerful alternative to &xmlrpc; which are specified as XMPP extension in &xep0072; and also a more powerful alternative to &xmlrpc; which are specified as XMPP extension
in &xep0009;.</p> in &xep0009;.</p>
<p>The &xep0332; allows for designing REST services in the context of XMPP, but requires an implementation <p>The &xep0332; allows for designing REST services in the context of XMPP, but requires an implementation
of both protocols: XMPP and HTTP. Furthermore, HTTP was selected in the past because of its of both protocols: XMPP and HTTP. Furthermore, HTTP was selected in the past because of its
degree of popularity, but has some drawbacks like the lack of discoverability of services. degree of popularity, but has some drawbacks like the lack of discoverability of services.
The REST with XMPP extension is a powerful protocol for cloud services that has The REST with XMPP extension is a powerful protocol for cloud services that has
several advantages in contrast to the traditional HTTP-based REST approach:</p> several advantages in contrast to the traditional HTTP-based REST approach:</p>
<ol> <ol>
<li>services are discoverable and explorable,</li> <li>services are discoverable and explorable,</li>
@ -84,127 +84,127 @@
</ul> </ul>
</section1> </section1>
<section1 topic='Resource Exploration' anchor='restdis'> <section1 topic='Resource Exploration' anchor='restdis'>
<p>In order to explore the capabilities of a resource, the &IQ; stanza type "get" have to be used. The returned <p>In order to explore the capabilities of a resource, the &IQ; stanza type "get" have to be used. The returned
&IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be
complied with the xwadl schema of this specification. The xwadl schema has been designed for providing a machine complied with the xwadl schema of this specification. The xwadl schema has been designed for providing a machine
process-able description of a resource. It was inspired by the Web Application Description Language (WADL) process-able description of a resource. It was inspired by the Web Application Description Language (WADL)
standard delivered by the World Wide Web Consortium (W3C).</p> standard delivered by the World Wide Web Consortium (W3C).</p>
<p>An &IQ; stanza of type "get" is returning an &IQ; stanza of type "result" that describes all actions that the <p>An &IQ; stanza of type "get" is returning an &IQ; stanza of type "result" that describes all actions that the
requesting party can perform. The following example shows an exploration of a cloud provider's REST based requesting party can perform. The following example shows an exploration of a cloud provider's REST based
interface for handling compute services.</p> interface for handling compute services.</p>
<!-- computeExplorationRequestIQ.xml --> <!-- computeExplorationRequestIQ.xml -->
<example caption='Exploration of an OpenStack interface for handling compute services'><![CDATA[ <example caption='Exploration of an OpenStack interface for handling compute services'><![CDATA[
<iq type='get' <iq type='get'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='company-a.com/openstack' to='company-a.com/openstack'
id='rest1'> id='rest1'>
<resource_type xmlns="urn:xmpp:rest-xwadl" path="/compute" /> <resource_type xmlns="urn:xmpp:rest-xwadl" path="/compute" />
</iq> </iq>
]]></example> ]]></example>
<p>In order to explore a resource, only the path to a resource is required. The counter party has to <p>In order to explore a resource, only the path to a resource is required. The counter party has to
answer of such a request with a response that exposes all possible actions which can be performed on the answer of such a request with a response that exposes all possible actions which can be performed on the
resource located at the specified path. The following example illustrates a response that exposes all resource located at the specified path. The following example illustrates a response that exposes all
actions for this resource.</p> actions for this resource.</p>
<!-- computeExplorationResponseIQ.xml --> <!-- computeExplorationResponseIQ.xml -->
<example caption='Result of an exploration for handling compute services'><![CDATA[ <example caption='Result of an exploration for handling compute services'><![CDATA[
<iq type="result" <iq type="result"
from="company-a.com/openstack" from="company-a.com/openstack"
to="requester@company-b.com/rest-client" to="requester@company-b.com/rest-client"
id="rest1"> id="rest1">
<resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute"> <resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<doc title="Compute resource management"> <doc title="Compute resource management">
Use one of the following actions to manage your compute instances! Use one of the following actions to manage your compute instances!
</doc> </doc>
<method name="create"> <method name="create">
<request> <request>
<param name="image" required="true" repeating="false"> <param name="image" required="true" repeating="false">
<option link="remote"/> <option link="remote"/>
</param> </param>
<param name="flavors" repeating="false" default="m1.small"> <param name="flavors" repeating="false" default="m1.small">
<option type="xs:string">m1.small</option> <option type="xs:string">m1.small</option>
<option type="xs:string">m2.medium</option> <option type="xs:string">m2.medium</option>
<option type="xs:string">m3.large</option> <option type="xs:string">m3.large</option>
</param> </param>
<param name="number" repeating="false" default="1"> <param name="number" repeating="false" default="1">
<doc title="number of requested virtual machnies"/> <doc title="number of requested virtual machnies"/>
<option type="xs:integer"/> <option type="xs:integer"/>
</param> </param>
</request> </request>
<response> <response>
<param name="newVM"> <param name="newVM">
<option link="list"/> <option link="list"/>
</param> </param>
</response> </response>
</method> </method>
<method name="sla"> <method name="sla">
<response> <response>
<param name="computeSla"> <param name="computeSla">
<option mediaType="text/plain"/> <option mediaType="text/plain"/>
<option mediaType="application/json"/> <option mediaType="application/json"/>
</param> </param>
</response> </response>
</method> </method>
</resource_type> </resource_type>
</iq> </iq>
]]></example> ]]></example>
<p>This response exposes two methods that can be performed on the <p>This response exposes two methods that can be performed on the
resource located at "/compute". The first method "create" can be used to create one or resource located at "/compute". The first method "create" can be used to create one or
more virtual machines (VM). This method has three input parameters in its request and one output more virtual machines (VM). This method has three input parameters in its request and one output
parameter in its response. If a client would like to perform this method, at least only a link to parameter in its response. If a client would like to perform this method, at least only a link to
the location of an image is required. The other two parameters are optional. The server will respond to this the location of an image is required. The other two parameters are optional. The server will respond to this
method with a list of links to the instantiated VMs. A detailed example of how to access this method is method with a list of links to the instantiated VMs. A detailed example of how to access this method is
illustrated in the <link url='#restaccess'>Resource Access</link> section.</p> illustrated in the <link url='#restaccess'>Resource Access</link> section.</p>
<p>The following subsections describe each component of a xwadl document in detail.</p> <p>The following subsections describe each component of a xwadl document in detail.</p>
<section2 topic='Resource Type' anchor='restdis-resourcetype'> <section2 topic='Resource Type' anchor='restdis-resourcetype'>
<p>The "resource_type" element forms the root of a xwadl document and MAY comprises the following <p>The "resource_type" element forms the root of a xwadl document and MAY comprises the following
sub-elements: "doc", "grammars", and "method"</p> sub-elements: "doc", "grammars", and "method"</p>
</section2> </section2>
<section2 topic='Documentation' anchor='restdis-documentation'> <section2 topic='Documentation' anchor='restdis-documentation'>
<p>Each xwadl-defined element down to the "param" can have one or more child "doc" elements that <p>Each xwadl-defined element down to the "param" can have one or more child "doc" elements that
can be used to document that element. The doc element has "title" attributes which is a short plain can be used to document that element. The doc element has "title" attributes which is a short plain
text description of the element being documented. The "doc" element can have mixed content text description of the element being documented. The "doc" element can have mixed content
and may contain text and zero or more child elements.</p> and may contain text and zero or more child elements.</p>
</section2> </section2>
<section2 topic='Grammars' anchor='restdis-grammars'> <section2 topic='Grammars' anchor='restdis-grammars'>
<p>The "grammars" element acts as a container for definitions of the format of data exchanged <p>The "grammars" element acts as a container for definitions of the format of data exchanged
during execution of the protocol described by the xwadl document and SHOULD be according to the during execution of the protocol described by the xwadl document and SHOULD be according to the
XML Schema definition.</p> XML Schema definition.</p>
<!-- grammarsExampleResponseIQ.xml --> <!-- grammarsExampleResponseIQ.xml -->
<example caption='Example xwadl document with a grammars element'><![CDATA[ <example caption='Example xwadl document with a grammars element'><![CDATA[
<iq type="result" <iq type="result"
from="responder@company-a.com" from="responder@company-a.com"
to="requester@company-b.com/rest-client" to="requester@company-b.com/rest-client"
id="rest1"> id="rest1">
<resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/address-book"> <resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/address-book">
<grammars> <grammars>
<doc title="Person List"/> <doc title="Person List"/>
<xs:element name="PersonList" type="MyStructType"/> <xs:element name="PersonList" type="MyStructType"/>
<xs:complexType name="MyStructType"> <xs:complexType name="MyStructType">
<xs:sequence> <xs:sequence>
<xs:element name="Person" type="MyPersonType" maxOccurs="unbounded"/> <xs:element name="Person" type="MyPersonType" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="MyPersonType"> <xs:complexType name="MyPersonType">
<xs:sequence> <xs:sequence>
<xs:element name="name" type="xs:string"/> <xs:element name="name" type="xs:string"/>
<xs:element name="age" type="xs:integer"/> <xs:element name="age" type="xs:integer"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</grammars> </grammars>
<method name="POST"> <method name="POST">
<request> <request>
<param name="persons" required="true" repeating="false"> <param name="persons" required="true" repeating="false">
<option type="MyStructType"/> <option type="MyStructType"/>
</param> </param>
</request> </request>
<response/> <response/>
</method> </method>
</resource_type> </resource_type>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Method' anchor='restdis-method'> <section2 topic='Method' anchor='restdis-method'>
<p>A method element describes the specific actions that can be performed on a resource targeted <p>A method element describes the specific actions that can be performed on a resource targeted
by the "path" attribute of the "resource_type" element. by the "path" attribute of the "resource_type" element.
A method element is a child of a "resource_type" element and has a "name" attribute A method element is a child of a "resource_type" element and has a "name" attribute
that identifies this method.</p> that identifies this method.</p>
@ -212,7 +212,7 @@
which can be empty or be used to expose the optional parameters that this method can execute.</p> which can be empty or be used to expose the optional parameters that this method can execute.</p>
</section2> </section2>
<section2 topic='Request and Response' anchor='restdis-reqeesp'> <section2 topic='Request and Response' anchor='restdis-reqeesp'>
<p>The "request" and the "response" element are according to the xwadl schema of type "call". They are <p>The "request" and the "response" element are according to the xwadl schema of type "call". They are
identical by definition and describe the input and output data for accessing a resource.</p> identical by definition and describe the input and output data for accessing a resource.</p>
<ul> <ul>
<li>A <strong>request</strong> describes the <strong>input</strong> to the method as a collection of parameters.</li> <li>A <strong>request</strong> describes the <strong>input</strong> to the method as a collection of parameters.</li>
@ -222,41 +222,41 @@
Both elements have no attributes and may contain one or more "param" elements as child elements.</p> Both elements have no attributes and may contain one or more "param" elements as child elements.</p>
</section2> </section2>
<section2 topic='Parameter' anchor='restdis-parameter'> <section2 topic='Parameter' anchor='restdis-parameter'>
<p>A "param" element describes a parameterized component of its parent element (either a request or a <p>A "param" element describes a parameterized component of its parent element (either a request or a
response). It can be identified by its "name" attribute and MUST have a minimum of one "option" element response). It can be identified by its "name" attribute and MUST have a minimum of one "option" element
that defines one of a set of possible that defines one of a set of possible
values for the parameter. In order to parameterize a component, the "param" element SHOULD specify values for the parameter. In order to parameterize a component, the "param" element SHOULD specify
a combination of the following attributes:</p> a combination of the following attributes:</p>
<ul> <ul>
<li>The <strong>name</strong> attribute specifies the name of the parameter and is a required attribute.</li> <li>The <strong>name</strong> attribute specifies the name of the parameter and is a required attribute.</li>
<li>The <strong>default</strong> attribute specifies an OPTIONAL default value that is applied if this <li>The <strong>default</strong> attribute specifies an OPTIONAL default value that is applied if this
parameter is not used while accessing a resource. If this attribute is specified, the overall parameter parameter is not used while accessing a resource. If this attribute is specified, the overall parameter
element is optional when accessing a resource.</li> element is optional when accessing a resource.</li>
<li>The <strong>required</strong> attribute is an OPTIONAL element and can be either false or true (default is false). <li>The <strong>required</strong> attribute is an OPTIONAL element and can be either false or true (default is false).
It indicates whether the parameter is required to be present or not.</li> It indicates whether the parameter is required to be present or not.</li>
<li>The <strong>repeating</strong> attribute is an OPTIONAL element and can be either false or true (default is false). <li>The <strong>repeating</strong> attribute is an OPTIONAL element and can be either false or true (default is false).
It indicates whether the parameter is single valued or may have multiple values.</li> It indicates whether the parameter is single valued or may have multiple values.</li>
</ul> </ul>
<p>Some combinations of attributes do not make sense, e.g. the specification of "default=?" and "repeating=true", <p>Some combinations of attributes do not make sense, e.g. the specification of "default=?" and "repeating=true",
and SHOULD be considered application specific.</p> and SHOULD be considered application specific.</p>
</section2> </section2>
<section2 topic='Option' anchor='restdis-option'> <section2 topic='Option' anchor='restdis-option'>
<p>An "option" element defines one of a set of possible types, representations, link type, or also values <p>An "option" element defines one of a set of possible types, representations, link type, or also values
for the parameter. An "option" element MUST have one of the following attributes:</p> for the parameter. An "option" element MUST have one of the following attributes:</p>
<dl> <dl>
<di> <di>
<dt>type</dt> <dt>type</dt>
<dd> <dd>
<p>The "type" attribute indicates one possible type of the parameter as an XML qualified name, <p>The "type" attribute indicates one possible type of the parameter as an XML qualified name,
defaults to xs:string. It SHOULD specify the type of a single optional value. Multiple options defaults to xs:string. It SHOULD specify the type of a single optional value. Multiple options
with the same type but different values SHOULD specify a set of possible values which are with the same type but different values SHOULD specify a set of possible values which are
acceptable as input for the parent parameter.</p> acceptable as input for the parent parameter.</p>
</dd> </dd>
</di> </di>
<di> <di>
<dt>mediaType</dt> <dt>mediaType</dt>
<dd> <dd>
<p>The "mediaType" attribute indicates that the parent parameter acts as a media type selector <p>The "mediaType" attribute indicates that the parent parameter acts as a media type selector
for requests or responses. The value of the attribute is the media type that is expected. If for requests or responses. The value of the attribute is the media type that is expected. If
a representation of an OPTIONAL media type is exposed, this representation can act as a a representation of an OPTIONAL media type is exposed, this representation can act as a
template for manipulating a resource.</p> template for manipulating a resource.</p>
@ -266,7 +266,7 @@
<dt>link</dt> <dt>link</dt>
<dd> <dd>
<p>The "link" attribute is used to identify links to resources. It can have the value local, remote, <p>The "link" attribute is used to identify links to resources. It can have the value local, remote,
or list. A local link links to another resource located at the same server entity. A remote link links to or list. A local link links to another resource located at the same server entity. A remote link links to
a resource located at another server entity anywhere in the XMPP network overlay. A link with a a resource located at another server entity anywhere in the XMPP network overlay. A link with a
list value indicates a list of remote links that can be used for discovery or linking to a set list value indicates a list of remote links that can be used for discovery or linking to a set
of resources.</p> of resources.</p>
@ -276,13 +276,13 @@
</section2> </section2>
</section1> </section1>
<section1 topic='Resource Access' anchor='restaccess'> <section1 topic='Resource Access' anchor='restaccess'>
<p>In order to access a resource, the &IQ; stanza type "set" has to be used. The returned <p>In order to access a resource, the &IQ; stanza type "set" has to be used. The returned
&IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be
complied with the xml-rest schema of this specification. The xml-rest schema has been designed complied with the xml-rest schema of this specification. The xml-rest schema has been designed
for providing a xml-rest encoded payload for accessing a resource. for providing a xml-rest encoded payload for accessing a resource.
An &IQ; stanza MUST NOT contain more than one method element with one request and one response. An &IQ; stanza MUST NOT contain more than one method element with one request and one response.
The following example illustrates how the create method of the previous example is requested. The following example illustrates how the create method of the previous example is requested.
Here, the client requests three VMs which are based on an image that is available as resource Here, the client requests three VMs which are based on an image that is available as resource
on the client's side.</p> on the client's side.</p>
<!-- computeCreateRequestIQ.xml --> <!-- computeCreateRequestIQ.xml -->
<example caption='Access of an OpenStack interface to create a virtual machnine'><![CDATA[ <example caption='Access of an OpenStack interface to create a virtual machnine'><![CDATA[
@ -290,25 +290,25 @@
from="requester@company-b.com/rest-client" from="requester@company-b.com/rest-client"
to="company-a.com/openstack" to="company-a.com/openstack"
id="rest2"> id="rest2">
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute"> <resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create"> <method name="create">
<request> <request>
<param name="image"> <param name="image">
<link> <link>
<to>requester@company-b.com/rest-client</to> <to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path> <path>/images/myLinuxImage</path>
</link> </link>
</param> </param>
<param name="number"> <param name="number">
<value type="xs:integer">3</value> <value type="xs:integer">3</value>
</param> </param>
</request> </request>
<response> <response>
<param name="newVM"> <param name="newVM">
<resourceList/> <resourceList/>
</param> </param>
</response> </response>
</method> </method>
</resource> </resource>
</iq> </iq>
]]></example> ]]></example>
@ -319,50 +319,50 @@
</p> </p>
<!-- computeCreateRequestIQ.xml --> <!-- computeCreateRequestIQ.xml -->
<example caption='Result of an access to create a virtual machnine'><![CDATA[ <example caption='Result of an access to create a virtual machnine'><![CDATA[
<iq type="result" <iq type="result"
from="company-a.com/openstack" from="company-a.com/openstack"
to="requester@company-b.com/rest-client" to="requester@company-b.com/rest-client"
id="rest2"> id="rest2">
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute"> <resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create"> <method name="create">
<request> <request>
<param name="image"> <param name="image">
<link> <link>
<to>requester@company-b.com/rest-client</to> <to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path> <path>/images/myLinuxImage</path>
</link> </link>
</param> </param>
<param name="number"> <param name="number">
<value type="xs:integer">3</value> <value type="xs:integer">3</value>
</param> </param>
</request> </request>
<response> <response>
<param name="newVM"> <param name="newVM">
<resourceList> <resourceList>
<link> <link>
<to>dc1.company-a.com/openstack</to> <to>dc1.company-a.com/openstack</to>
<path>requester/vms/vm1</path> <path>requester/vms/vm1</path>
</link> </link>
<link> <link>
<to>dc2.company-a.com/openstack</to> <to>dc2.company-a.com/openstack</to>
<path>requester/vms/vm02</path> <path>requester/vms/vm02</path>
</link> </link>
<link> <link>
<to>dc3.company-a.com/openstack</to> <to>dc3.company-a.com/openstack</to>
<path>requester/vms/vm003</path> <path>requester/vms/vm003</path>
</link> </link>
</resourceList> </resourceList>
</param> </param>
</response> </response>
</method> </method>
</resource> </resource>
</iq> </iq>
]]></example> ]]></example>
<p>The following subsections describe each component of a xml-rest document in detail.</p> <p>The following subsections describe each component of a xml-rest document in detail.</p>
<section2 topic='Resource' anchor='restaccess-resource'> <section2 topic='Resource' anchor='restaccess-resource'>
<p>The "resource" element forms the root of an xml-rest document and MUST comprise only a <p>The "resource" element forms the root of an xml-rest document and MUST comprise only a
single "method" sub-element. In contrast to the xwadl description, no further documentation or grammers single "method" sub-element. In contrast to the xwadl description, no further documentation or grammers
are possible in order to keep the number of bytes as low as possible. are possible in order to keep the number of bytes as low as possible.
In order to specify the resource to access, the "path" attribute is required.</p> In order to specify the resource to access, the "path" attribute is required.</p>
</section2> </section2>
<section2 topic='Method' anchor='restaccess-method'> <section2 topic='Method' anchor='restaccess-method'>
@ -370,7 +370,7 @@
"name" attribute is required in order to identify the action that has to be performed on the resource.</p> "name" attribute is required in order to identify the action that has to be performed on the resource.</p>
</section2> </section2>
<section2 topic='Request and Response' anchor='restaccess-reqeesp'> <section2 topic='Request and Response' anchor='restaccess-reqeesp'>
<p>The "request" and the "response" element are according to the xml-rest schema of type "call". They are <p>The "request" and the "response" element are according to the xml-rest schema of type "call". They are
identical by definition and including the information for applying the method of a resource. identical by definition and including the information for applying the method of a resource.
Both elements have no attributes and may contain one or more "param" elements as child elements.</p> Both elements have no attributes and may contain one or more "param" elements as child elements.</p>
<ul> <ul>
@ -390,9 +390,9 @@
</section2> </section2>
<section2 topic='Link and Resource List' anchor='restaccess-link'> <section2 topic='Link and Resource List' anchor='restaccess-link'>
<p>A "link" element or a "resourceList" element have no attributes. While a link targets to a single local <p>A "link" element or a "resourceList" element have no attributes. While a link targets to a single local
or remote location, a resource list is a set of links which are targeting to any resource in an XMPP or remote location, a resource list is a set of links which are targeting to any resource in an XMPP
overlay network. A link can be expressed in two forms: as XMPP resource link with a "to" overlay network. A link can be expressed in two forms: as XMPP resource link with a "to"
(e.g. &lt;to&gt;requester@company-b.com/rest-client&lt;/to&gt;) and a "path" (e.g. (e.g. &lt;to&gt;requester@company-b.com/rest-client&lt;/to&gt;) and a "path" (e.g.
&lt;path&gt;/images/myLinuxImage&lt;/path&gt;) element &lt;path&gt;/images/myLinuxImage&lt;/path&gt;) element
or as URI (&lt;uri&gt;xmpp://requester@company-b.com/rest-client?/images/myLinuxImage&lt;/uri&gt;).</p> or as URI (&lt;uri&gt;xmpp://requester@company-b.com/rest-client?/images/myLinuxImage&lt;/uri&gt;).</p>
</section2> </section2>
@ -402,12 +402,12 @@
<p>Example to access the sla method.</p> <p>Example to access the sla method.</p>
</section2 --> </section2 -->
<section2 topic='Multi-Dimensional Resource Placement' anchor='usecases-multi-dim'> <section2 topic='Multi-Dimensional Resource Placement' anchor='usecases-multi-dim'>
<p>The REST with XMPP protocol enables a multi-dimensional resource placement. The following examples show <p>The REST with XMPP protocol enables a multi-dimensional resource placement. The following examples show
how different resources can be placed within a single server entity:</p> how different resources can be placed within a single server entity:</p>
<example caption='A request to a server'><![CDATA[ <example caption='A request to a server'><![CDATA[
<iq type='set' <iq type='set'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='company-a.com' to='company-a.com'
id='rest1'> id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/"> <resource xmlns="urn:xmpp:xml-rest" path="/">
... ...
@ -415,9 +415,9 @@
</iq> </iq>
]]></example> ]]></example>
<example caption='A request to a server with a JID contained a resource part'><![CDATA[ <example caption='A request to a server with a JID contained a resource part'><![CDATA[
<iq type='set' <iq type='set'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='company-a.com/resource' to='company-a.com/resource'
id='rest1'> id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/"> <resource xmlns="urn:xmpp:xml-rest" path="/">
... ...
@ -425,9 +425,9 @@
</iq> </iq>
]]></example> ]]></example>
<example caption='A request to a server with a JID contained a local part'><![CDATA[ <example caption='A request to a server with a JID contained a local part'><![CDATA[
<iq type='set' <iq type='set'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='responder@company-a.com' to='responder@company-a.com'
id='rest1'> id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/"> <resource xmlns="urn:xmpp:xml-rest" path="/">
... ...
@ -435,9 +435,9 @@
</iq> </iq>
]]></example> ]]></example>
<example caption='A request to a server with a JID contained a local and a resource part'><![CDATA[ <example caption='A request to a server with a JID contained a local and a resource part'><![CDATA[
<iq type='set' <iq type='set'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource' to='responder@company-a.com/resource'
id='rest1'> id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/"> <resource xmlns="urn:xmpp:xml-rest" path="/">
... ...
@ -445,34 +445,34 @@
</iq> </iq>
]]></example> ]]></example>
<example caption='A request to a server with a JID contained a local and a resource part, but accesses another resource'><![CDATA[ <example caption='A request to a server with a JID contained a local and a resource part, but accesses another resource'><![CDATA[
<iq type='set' <iq type='set'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource' to='responder@company-a.com/resource'
id='rest1'> id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/resource/"> <resource xmlns="urn:xmpp:xml-rest" path="/resource/">
... ...
</resource> </resource>
</iq> </iq>
]]></example> ]]></example>
<p>All examples above are accessing different resources. A variation of the path attribute of the resource <p>All examples above are accessing different resources. A variation of the path attribute of the resource
element would also combine the presented JIDs and referring to different resources. element would also combine the presented JIDs and referring to different resources.
Further examples are possible to show how different resources can be located at a single server entity.</p> Further examples are possible to show how different resources can be located at a single server entity.</p>
</section2> </section2>
</section1> </section1>
<section1 topic='Service Discovery' anchor='disco'> <section1 topic='Service Discovery' anchor='disco'>
<p>If an entity supports the REST with XMPP protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rest" and a feature of "jabber:iq:rest":</p> <p>If an entity supports the REST with XMPP protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rest" and a feature of "jabber:iq:rest":</p>
<example caption='A disco#info query'><![CDATA[ <example caption='A disco#info query'><![CDATA[
<iq type='get' <iq type='get'
from='requester@company-b.com/rest-client' from='requester@company-b.com/rest-client'
to='responder@company-a.com/rest-server' to='responder@company-a.com/rest-server'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq type='result' <iq type='result'
to='requester@company-b.com/rest-client' to='requester@company-b.com/rest-client'
from='responder@company-a.com/rest-server' from='responder@company-a.com/rest-server'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='rest'/> <identity category='automation' type='rest'/>
@ -482,9 +482,9 @@
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>Determining when and how a resource can be accessed or modified based on permissions or <p>Determining when and how a resource can be accessed or modified based on permissions or
rights are considered outside the scope of this document. Although such mechanisms SHOULD be rights are considered outside the scope of this document. Although such mechanisms SHOULD be
considered specifically to the application and/or implementation of this document, considered specifically to the application and/or implementation of this document,
future specifications may address these concerns.</p> future specifications may address these concerns.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>

48
inbox/sensors.xml
View File

@ -215,7 +215,7 @@ To achive this, the specific requirements are:
<section1 topic='Glossary' anchor='glossary'> <section1 topic='Glossary' anchor='glossary'>
<p>The following terms are used throughout this document to refer to elements, objects, or actions that occur in the context of a transducer using the pubsub service. (Note: Some of these terms are specified in greater detail within the body of this document.)</p> <p>The following terms are used throughout this document to refer to elements, objects, or actions that occur in the context of a transducer using the pubsub service. (Note: Some of these terms are specified in greater detail within the body of this document.)</p>
<dl> <dl>
<di><dt>Sensor </dt><dd> A device that measures a physical quantity.</dd></di> <di><dt>Sensor </dt><dd> A device that measures a physical quantity.</dd></di>
<di><dt>Actuator </dt><dd> A device for moving or controlling a mechanism or system. </dd></di> <di><dt>Actuator </dt><dd> A device for moving or controlling a mechanism or system. </dd></di>
<di><dt>Transducer </dt><dd> A device that is a Sensor or Actuator or both. Transducers can also be virtualized, in the sense that they may not necessarily refer to the physical device that is directly measuring or controlling a phenomena, but rather to a software agent that serves as an intermediary.</dd></di> <di><dt>Transducer </dt><dd> A device that is a Sensor or Actuator or both. Transducers can also be virtualized, in the sense that they may not necessarily refer to the physical device that is directly measuring or controlling a phenomena, but rather to a software agent that serves as an intermediary.</dd></di>
<di><dt>PubSub Service </dt><dd> An XMPP server or component that adheres to the protocol defined in &xep0060;.</dd></di> <di><dt>PubSub Service </dt><dd> An XMPP server or component that adheres to the protocol defined in &xep0060;.</dd></di>
@ -246,7 +246,7 @@ Thus, for the meta data, the node id would be UUID_meta and the data value node
<section2 topic='Device Metadata' anchor='devicem'> <section2 topic='Device Metadata' anchor='devicem'>
Adapter publishes device meta data: Adapter publishes device meta data:
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish1'> id='publish1'>
@ -556,7 +556,7 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
</tr> </tr>
<tr> <tr>
<td> <td>
multimedia input multimedia input
</td> </td>
<td> <td>
Sensors and controls associated with multimedia input (video camera, microphone, etc) Sensors and controls associated with multimedia input (video camera, microphone, etc)
@ -614,11 +614,11 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
</table> </table>
</section3> </section3>
<section3 topic='Units' anchor='units'> <section3 topic='Units' anchor='units'>
<p>For the sake of interoperability, implementations SHOULD transform native sensor units into the closest relevant SI form. SI units are defined based on <p>For the sake of interoperability, implementations SHOULD transform native sensor units into the closest relevant SI form. SI units are defined based on
SI conventions as shown in the <link url='http://aurora.regenstrief.org/~ucum/ucum.html'>The Unified Code For Units of Measurement</link>. SI conventions as shown in the <link url='http://aurora.regenstrief.org/~ucum/ucum.html'>The Unified Code For Units of Measurement</link>.
</p> </p>
<p> <p>
After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters. After specifying the units of the transducer device, you can then also specify an SI scalar value as powers of 10. The following example shows how to specify a sensor in centimeters.
<code><![CDATA[ <code><![CDATA[
<device id='01020301' type='other'> <device id='01020301' type='other'>
<transducer name='inchworm movement' id='0001' <transducer name='inchworm movement' id='0001'
@ -626,7 +626,7 @@ After specifying the units of the transducer device, you can then also specify a
</device> </device>
]]></code> ]]></code>
The following example shows how to specify a sensor in kilograms. The following example shows how to specify a sensor in kilograms.
<code><![CDATA[ <code><![CDATA[
<device id='xyzzy' type='scale'> <device id='xyzzy' type='scale'>
<transducer name='bathroom scale' id='0001' <transducer name='bathroom scale' id='0001'
@ -651,7 +651,7 @@ If no unitScaler value is specified, then a unitScaler of 0 (aka 10**0 = 1) is a
<section2 topic='Transducer Values' anchor='transducervalues'> <section2 topic='Transducer Values' anchor='transducervalues'>
Values for a transducer are published via the data value node: Values for a transducer are published via the data value node:
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish2'> id='publish2'>
@ -756,7 +756,7 @@ As mentioned earlier, if the XMPP service is capable of handling pub-sub collect
If the XMPP service is not capable of handling pub-sub collections, adapters which want to create nodes for individual transducers SHOULD use a node id of the form X_Y where X is the UUID for the device and Y is the transducer id as listed in the UUID_meta node. If the XMPP service is not capable of handling pub-sub collections, adapters which want to create nodes for individual transducers SHOULD use a node id of the form X_Y where X is the UUID for the device and Y is the transducer id as listed in the UUID_meta node.
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish3'> id='publish3'>
@ -806,7 +806,7 @@ The information in the meta node is used by consumers to determine which node th
<section2 topic='Setting Transducer Values' anchor='transducerset'> <section2 topic='Setting Transducer Values' anchor='transducerset'>
Values for a transducer can also be set by publishing to the data value node. Values for a transducer can also be set by publishing to the data value node.
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='house-capulet@capulet.lit/castle' from='house-capulet@capulet.lit/castle'
id='publish5'> id='publish5'>
@ -847,7 +847,7 @@ If the data value node is configured to include payloads, the subscribers will r
<p>Per the optional note above. If a transducer has the "hasOwnNode" attribute set in the UUID_meta node, then the value set would be done via the UUID_TransducerId node as described above. <p>Per the optional note above. If a transducer has the "hasOwnNode" attribute set in the UUID_meta node, then the value set would be done via the UUID_TransducerId node as described above.
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='juliet@capulet.lit/balcony' from='juliet@capulet.lit/balcony'
id='publish6'> id='publish6'>
@ -935,7 +935,7 @@ This last step allows an interested agent to subscribe to this node to confirm t
There is the possibility of contention if multiple users attempt to actuate the same device. There is the possibility of contention if multiple users attempt to actuate the same device.
This arbitration SHOULD happen at a higher control layer. This arbitration SHOULD happen at a higher control layer.
Any interested agent can always verify the latest state of the actuator by subscribing to the actuator's node. Any interested agent can always verify the latest state of the actuator by subscribing to the actuator's node.
</p> </p>
</section3> </section3>
</section2> </section2>
</section1> </section1>
@ -957,7 +957,7 @@ Since the mechanism for setting a transducer uses the same pubsub node as showin
The sensor used is accurate to the nearest 10 Wh. The sensor used is accurate to the nearest 10 Wh.
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish10'> id='publish10'>
@ -979,7 +979,7 @@ The sensor used is accurate to the nearest 10 Wh.
</pubsub> </pubsub>
</iq> </iq>
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish11'> id='publish11'>
@ -1003,7 +1003,7 @@ The new sensor is more accurate and can measure to the nearest 1 Wh.
The adapter provides this additional information in the meta node and data value node. The adapter provides this additional information in the meta node and data value node.
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish20'> id='publish20'>
@ -1029,7 +1029,7 @@ The adapter provides this additional information in the meta node and data value
</pubsub> </pubsub>
</iq> </iq>
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle' from='heater-capulet@capulet.lit/castle'
id='publish21'> id='publish21'>
@ -1064,7 +1064,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat' from='camera-montague@montague.lit/moat'
id='publish40'> id='publish40'>
@ -1092,7 +1092,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
</pubsub> </pubsub>
</iq> </iq>
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat' from='camera-montague@montague.lit/moat'
id='publish41'> id='publish41'>
@ -1110,7 +1110,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
</pubsub> </pubsub>
</iq> </iq>
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat' from='camera-montague@montague.lit/moat'
id='publish42'> id='publish42'>
@ -1134,7 +1134,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
<code><![CDATA[ <code><![CDATA[
Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat' from='camera-montague@montague.lit/moat'
id='publish43'> id='publish43'>
@ -1166,7 +1166,7 @@ One action could be to turn on the light, in which case the agent would publish:
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='watcher-montague@montague.lit/agent99' from='watcher-montague@montague.lit/agent99'
id='publish44'> id='publish44'>
@ -1189,7 +1189,7 @@ In response, the camera adapter would turn on the light and publish an acknowled
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.montague.lit' to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat' from='camera-montague@montague.lit/moat'
id='publish45'> id='publish45'>
@ -1228,7 +1228,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
</p> </p>
<code><![CDATA[ <code><![CDATA[
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='chariot-capulet@capulet.lit/convertible' from='chariot-capulet@capulet.lit/convertible'
id='publish50'> id='publish50'>
@ -1267,7 +1267,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
</pubsub> </pubsub>
</iq> </iq>
<iq type='set' <iq type='set'
to='pubsub.capulet.lit' to='pubsub.capulet.lit'
from='chariot-capulet@capulet.lit/convertible' from='chariot-capulet@capulet.lit/convertible'
id='publish51'> id='publish51'>
@ -1424,7 +1424,7 @@ The publication of sensor information is not known to introduce any new security
<xs:attribute name='precision' type='xs:float' use='optional'/> <xs:attribute name='precision' type='xs:float' use='optional'/>
<xs:attribute name='accuracy' type='xs:float' use='optional'/> <xs:attribute name='accuracy' type='xs:float' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='allowedUnits'> <xs:simpleType name='allowedUnits'>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">

2
inbox/server-rosters.xml
View File

@ -84,7 +84,7 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
</xep> </xep>

78
inbox/sift.xml
View File

@ -149,7 +149,7 @@
<li>Make it possible for a client to receive only inbound presence, message, or IQ stanzas that contain a payload matching a particular element name and XML namespace.</li> <li>Make it possible for a client to receive only inbound presence, message, or IQ stanzas that contain a payload matching a particular element name and XML namespace.</li>
<li>Make it possible for a client to "sift" based on all senders, local vs. remote senders, or other senders vs. oneself.</li> <li>Make it possible for a client to "sift" based on all senders, local vs. remote senders, or other senders vs. oneself.</li>
<li>Make it possible for a client to "sift" based on whether the recipient is the user's bare JID or the particular client's full JID.</li> <li>Make it possible for a client to "sift" based on whether the recipient is the user's bare JID or the particular client's full JID.</li>
<li>Enable future extensibility based on regular expressions, XPath expressions, etc.</li> <li>Enable future extensibility based on regular expressions, XPath expressions, etc.</li>
</ol> </ol>
</section1> </section1>
@ -212,7 +212,7 @@
<section2 topic='Discovering Supported Features' anchor='discovering'> <section2 topic='Discovering Supported Features' anchor='discovering'>
<p>If a server supports the SIFT protocol, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sift:1":</p> <p>If a server supports the SIFT protocol, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sift:1":</p>
<example caption='A disco#info query'><![CDATA[ <example caption='A disco#info query'><![CDATA[
<iq type='get' <iq type='get'
from='romeo@montague.lit/pda' from='romeo@montague.lit/pda'
to='montague.lit' to='montague.lit'
id='bf4vb167'> id='bf4vb167'>
@ -220,7 +220,7 @@
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq type='result' <iq type='result'
from='montague.lit' from='montague.lit'
to='romeo@montague.lit/pda' to='romeo@montague.lit/pda'
id='bf4vb167'> id='bf4vb167'>
@ -342,7 +342,7 @@
</section2> </section2>
<section2 topic='Handling Message Stanzas' anchor='rules-message'> <section2 topic='Handling Message Stanzas' anchor='rules-message'>
<p>When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and &xmppim;.</p> <p>When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and &xmppim;.</p>
<p>If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.</p> <p>If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.</p>
</section2> </section2>
<section2 topic='Handling IQ Stanzas' anchor='rules-iq'> <section2 topic='Handling IQ Stanzas' anchor='rules-iq'>
<p>If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).</p> <p>If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).</p>
@ -408,7 +408,7 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'> <section1 topic='XMPP Registrar Considerations' anchor='reg'>
@ -456,17 +456,17 @@
<xs:element name='sift'> <xs:element name='sift'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='iq' <xs:element name='iq'
type='siftElementType' type='siftElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='message' <xs:element name='message'
type='siftElementType' type='siftElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='presence' <xs:element name='presence'
type='siftElementType' type='siftElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
@ -475,20 +475,20 @@
<xs:element name='featureElementType'> <xs:element name='featureElementType'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='recipient' <xs:element name='recipient'
type='recipientElementType' type='recipientElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='sender' <xs:element name='sender'
type='senderElementType' type='senderElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='allow' <xs:element name='allow'
type='allowElementType' type='allowElementType'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
<xs:any namespace='##other' <xs:any namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
@ -497,12 +497,12 @@
<xs:element name='siftElementType'> <xs:element name='siftElementType'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='allow' <xs:element name='allow'
type='allowElementType' type='allowElementType'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
<xs:any namespace='##other' <xs:any namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xs:sequence> </xs:sequence>
<xs:attribute name='recipient' <xs:attribute name='recipient'
@ -535,16 +535,16 @@
<xs:element name='recipientElementType'> <xs:element name='recipientElementType'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='all' <xs:element name='all'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='bare' <xs:element name='bare'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='full' <xs:element name='full'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
</xs:sequence> </xs:sequence>
@ -554,24 +554,24 @@
<xs:element name='senderElementType'> <xs:element name='senderElementType'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name='all' <xs:element name='all'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='local' <xs:element name='local'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='others' <xs:element name='others'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='remote' <xs:element name='remote'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='self' <xs:element name='self'
type='empty' type='empty'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
</xs:sequence> </xs:sequence>

6
inbox/sox.xml
View File

@ -147,7 +147,7 @@ a=sendrecv
<section1 topic='Determining Support' anchor='disco'> <section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports SoX, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sox:0":</p> <p>If an entity supports SoX, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:sox:0":</p>
<example caption='A disco#info query'><![CDATA[ <example caption='A disco#info query'><![CDATA[
<iq type='get' <iq type='get'
from='romeo@example.net/orchard' from='romeo@example.net/orchard'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
id='hx62f49'> id='hx62f49'>
@ -155,7 +155,7 @@ a=sendrecv
</iq> </iq>
]]></example> ]]></example>
<example caption='A disco#info response'><![CDATA[ <example caption='A disco#info response'><![CDATA[
<iq type='result' <iq type='result'
from='juliet@example.com/chamber' from='juliet@example.com/chamber'
to='romeo@example.net/orchard' to='romeo@example.net/orchard'
id='hx62f49'> id='hx62f49'>
@ -172,7 +172,7 @@ a=sendrecv
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='reg'> <section1 topic='XMPP Registrar Considerations' anchor='reg'>

44
inbox/sxe.xml
View File

@ -254,8 +254,8 @@
<section1 topic='Determining the features of the Host' anchor='host'> <section1 topic='Determining the features of the Host' anchor='host'>
<p>Before connecting to a session, a party MUST determine the &xep0030; identity and supported features of the host. In many situations the party already knows this information (e.g., if the host is the initiator of the Jingle session). In other situations the party will need to send a service discovery information request to the host.</p> <p>Before connecting to a session, a party MUST determine the &xep0030; identity and supported features of the host. In many situations the party already knows this information (e.g., if the host is the initiator of the Jingle session). In other situations the party will need to send a service discovery information request to the host.</p>
<example caption='Service Discovery Request'><![CDATA[ <example caption='Service Discovery Request'><![CDATA[
<iq from='laertes@shakespeare.lit/castle' <iq from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle' to='kingclaudius@shakespeare.lit/castle'
id='disco1'> id='disco1'>
type='get'> type='get'>
<query xmlns='http://xmpp.org/protocol/disco#info'/> <query xmlns='http://xmpp.org/protocol/disco#info'/>
@ -290,7 +290,7 @@
<p>In order to synchronize its local state with the existing state of the edited object, an entity sends a connection request to the host. The identity learned through service discovery determines what kind of message the joining party sends (e.g., type='groupchat' if the host is a MUC room).</p> <p>In order to synchronize its local state with the existing state of the edited object, an entity sends a connection request to the host. The identity learned through service discovery determines what kind of message the joining party sends (e.g., type='groupchat' if the host is a MUC room).</p>
<p>To connect to a session, the joiner MUST send an SXE &lt;connect/&gt; element to the host.</p> <p>To connect to a session, the joiner MUST send an SXE &lt;connect/&gt; element to the host.</p>
<example caption='Connecting to a session'><![CDATA[ <example caption='Connecting to a session'><![CDATA[
<message <message
from='laertes@shakespeare.lit/castle' from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'> to='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' id='e' session='851ba2'> <sxe xmlns='urn:xmpp:sxe:0' id='e' session='851ba2'>
@ -309,7 +309,7 @@
</ol> </ol>
<p>The state offer MUST contain the &lt;description/&gt; element or elements that were included in the Jingle session-initiate request.</p> <p>The state offer MUST contain the &lt;description/&gt; element or elements that were included in the Jingle session-initiate request.</p>
<example caption='A state offer'><![CDATA[ <example caption='A state offer'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -326,7 +326,7 @@
<p>The joiner accepts a state offer by sending an &lt;accept-state/&gt; element to one of the entities that offer to send the state. The joiner MUST store all the &lt;sxe/&gt; elements it receives after the &lt;state-offer/&gt; element it decides to accept. It MUST also abort the negotiation with the other users that offered to send the state.</p> <p>The joiner accepts a state offer by sending an &lt;accept-state/&gt; element to one of the entities that offer to send the state. The joiner MUST store all the &lt;sxe/&gt; elements it receives after the &lt;state-offer/&gt; element it decides to accept. It MUST also abort the negotiation with the other users that offered to send the state.</p>
<p>Once the other entity receives the &lt;accept-state/&gt; element it MUST proceed sending the state as described in the next section.</p> <p>Once the other entity receives the &lt;accept-state/&gt; element it MUST proceed sending the state as described in the next section.</p>
<example caption='Accepting a state offer'><![CDATA[ <example caption='Accepting a state offer'><![CDATA[
<message <message
from='laertes@shakespeare.lit/castle' from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'> to='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -340,7 +340,7 @@
<section2 topic='Refusing a State Offer'> <section2 topic='Refusing a State Offer'>
<p>If a multiple state offers were received, one should be accepted and the others should be refused by sending a &lt;refuse-state/&gt; element.</p> <p>If a multiple state offers were received, one should be accepted and the others should be refused by sending a &lt;refuse-state/&gt; element.</p>
<example caption='Refusing a state offer'><![CDATA[ <example caption='Refusing a state offer'><![CDATA[
<message <message
from='laertes@shakespeare.lit/castle' from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'> to='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -361,7 +361,7 @@
<p>The state can be sent in any number of &lt;sxe/&gt; elements but the user sending the state MUST NOT send any new &lt;sxe/&gt; elements between sending the &lt;document-begin/&gt; (i.e. taking the snapshot) and the &lt;document-end/&gt; element.</p> <p>The state can be sent in any number of &lt;sxe/&gt; elements but the user sending the state MUST NOT send any new &lt;sxe/&gt; elements between sending the &lt;document-begin/&gt; (i.e. taking the snapshot) and the &lt;document-end/&gt; element.</p>
<p>The state SHOULD include a version of each element that was synchronized, and hence won't be undone, as well as all the later versions. In practice this can often be impossible to know in a session without a specialized MUC component so it may be safest to send version 0 and all the later edits to each element. Version 0 is implied if the version element is missing.</p> <p>The state SHOULD include a version of each element that was synchronized, and hence won't be undone, as well as all the later versions. In practice this can often be impossible to know in a session without a specialized MUC component so it may be safest to send version 0 and all the later edits to each element. Version 0 is implied if the version element is missing.</p>
<example caption='Sending the state of a blank document (only prolog)'><![CDATA[ <example caption='Sending the state of a blank document (only prolog)'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -381,14 +381,14 @@
]]></example> ]]></example>
<p>If the session is already in progress, the entity sends the snapshot.</p> <p>If the session is already in progress, the entity sends the snapshot.</p>
<example caption='Sending the state of an existing document'><![CDATA[ <example caption='Sending the state of an existing document'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
session='851ba2' session='851ba2'
id='bxyz'> id='bxyz'>
<state> <state>
<document-begin <document-begin
prolog='data:text/xml,%3C!DOCTYPE%20html%0D%0APUBLIC%20%22-\ prolog='data:text/xml,%3C!DOCTYPE%20html%0D%0APUBLIC%20%22-\
%2F%2FW3C%2F%2FDTD%20XHTML%201.0%20Strict%2F%2FEN%22%0D%0A%22htt\ %2F%2FW3C%2F%2FDTD%20XHTML%201.0%20Strict%2F%2FEN%22%0D%0A%22htt\
p%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-strict.dtd%223\ p%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-strict.dtd%223\
@ -452,7 +452,7 @@
<section1 topic='Subsequent State Changes'> <section1 topic='Subsequent State Changes'>
<p>Once a participant has received initial state, he can participate in the editing session.</p> <p>Once a participant has received initial state, he can participate in the editing session.</p>
<example caption='An edit'><![CDATA[ <example caption='An edit'><![CDATA[
<message <message
to='laertes@shakespeare.lit/castle' to='laertes@shakespeare.lit/castle'
from='kingclaudius@shakespeare.lit/castle'> from='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -476,7 +476,7 @@
]]></example> ]]></example>
<p>Here is another edit in the session.</p> <p>Here is another edit in the session.</p>
<example caption='Another edit'><![CDATA[ <example caption='Another edit'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -755,7 +755,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<section2 topic='Commutative and Non-commutative Edits'> <section2 topic='Commutative and Non-commutative Edits'>
<p>Changes to the records can be divided into two categories: commutative and non-commutative edits.</p> <p>Changes to the records can be divided into two categories: commutative and non-commutative edits.</p>
<p>Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Edits that add or remove records are commutative.</p> <p>Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Edits that add or remove records are commutative.</p>
<p>An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:</p> <p>An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:</p>
<table caption='Matrix of required history'> <table caption='Matrix of required history'>
<tr> <tr>
<td></td> <td></td>
@ -782,7 +782,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
</ol> </ol>
</section3> </section3>
</section2> </section2>
<section2 topic='Commutative Edits' anchor='commutativeedits'> <section2 topic='Commutative Edits' anchor='commutativeedits'>
<section3 topic='Creating New Nodes' anchor='newnode'> <section3 topic='Creating New Nodes' anchor='newnode'>
<p>A client can add a new node to the document by adding a record with the &lt;new/&gt; element.</p> <p>A client can add a new node to the document by adding a record with the &lt;new/&gt; element.</p>
@ -843,7 +843,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
</table> </table>
<example caption='Sending new nodes'><![CDATA[ <example caption='Sending new nodes'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -859,13 +859,13 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
rid='GUID5' rid='GUID5'
chdata='M10 10L30 50L50 10Z' /> chdata='M10 10L30 50L50 10Z' />
</sxe> </sxe>
</message> </message>
]]></example> ]]></example>
<p>To process a &lt;new/&gt; element the client MUST create a new record with the values of the attributes stored in the corresponding fields.</p> <p>To process a &lt;new/&gt; element the client MUST create a new record with the values of the attributes stored in the corresponding fields.</p>
</section3> </section3>
<section3 topic='Removing Nodes' anchor='editelement'> <section3 topic='Removing Nodes' anchor='editelement'>
<p>A client can remove any node in the document by removing the corresponding record with the &lt;remove/&gt; element.</p> <p>A client can remove any node in the document by removing the corresponding record with the &lt;remove/&gt; element.</p>
<table caption="Attributes of the &lt;remove/&gt; element"> <table caption="Attributes of the &lt;remove/&gt; element">
<tr> <tr>
<th>Attribute</th> <th>Attribute</th>
@ -876,11 +876,11 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<td>REQUIRED and MUST be the record id of the node to be removed.</td> <td>REQUIRED and MUST be the record id of the node to be removed.</td>
</tr> </tr>
</table> </table>
<p>A client MUST NOT send a &lt;remove/&gt; element that removes a node that has child nodes without explicitly removing the records of those nodes first.</p> <p>A client MUST NOT send a &lt;remove/&gt; element that removes a node that has child nodes without explicitly removing the records of those nodes first.</p>
<example caption='Removing an existing nodes.'><![CDATA[ <example caption='Removing an existing nodes.'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'
@ -898,7 +898,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<section2 topic='Non-commutative Edits' anchor='noncommutativeedits'> <section2 topic='Non-commutative Edits' anchor='noncommutativeedits'>
<section3 topic='The set Element'> <section3 topic='The set Element'>
<p>The &lt;set/&gt; element is used to modify an existing record.</p> <p>The &lt;set/&gt; element is used to modify an existing record.</p>
<table caption="Attributes of the &lt;set/&gt; element"> <table caption="Attributes of the &lt;set/&gt; element">
<tr> <tr>
<th>Attribute</th> <th>Attribute</th>
@ -948,12 +948,12 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<td>replacen</td> <td>replacen</td>
<td>replace n characters. OPTIONAL but only allowed if 'chdata' and 'replacefrom' attributes are also included. MUST be a non-negative integer.</td> <td>replace n characters. OPTIONAL but only allowed if 'chdata' and 'replacefrom' attributes are also included. MUST be a non-negative integer.</td>
</tr> </tr>
</table> </table>
<example caption='set elements.'><![CDATA[ <example caption='set elements.'><![CDATA[
<message <message
from='kingclaudius@shakespeare.lit/castle' from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'> to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' <sxe xmlns='urn:xmpp:sxe:0'

4
inbox/thumbs.xml
View File

@ -69,7 +69,7 @@ file being offered (name, size, and date). There currently is no way to provide
<p>When a client wishes to supply a thumbnail in a transfer offer, it can do so by including an extra <![CDATA[<thumbnail/>]]> element as show in the following exaples.</p> <p>When a client wishes to supply a thumbnail in a transfer offer, it can do so by including an extra <![CDATA[<thumbnail/>]]> element as show in the following exaples.</p>
<example caption='Inclusion of a thumbnail in SI file transfer offer'><![CDATA[ <example caption='Inclusion of a thumbnail in SI file transfer offer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'> <iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si' <si xmlns='http://jabber.org/protocol/si'
id='a0' id='a0'
mime-type='image/jpeg' mime-type='image/jpeg'
profile='http://jabber.org/protocol/si/profile/file-transfer'> profile='http://jabber.org/protocol/si/profile/file-transfer'>
@ -127,7 +127,7 @@ file being offered (name, size, and date). There currently is no way to provide
</iq> </iq>
]]> ]]>
</example> </example>
<section2 topic='Definition of the thumbnail Element' <section2 topic='Definition of the thumbnail Element'
anchor='thumbnail_element'> anchor='thumbnail_element'>
<p>The following attributes are defined for the &lt;thumbnail/&gt; element.</p> <p>The following attributes are defined for the &lt;thumbnail/&gt; element.</p>
<table caption='Attributes of the thumbnail Element'> <table caption='Attributes of the thumbnail Element'>

34
inbox/tictactoe-mug.xml
View File

@ -50,8 +50,8 @@
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p> <p>
It is quite common to play games over IM networks. It is quite common to play games over IM networks.
Since Tic-tac-toe is a well-known and simple game, Since Tic-tac-toe is a well-known and simple game,
it's a good example for a server-based game protocol. it's a good example for a server-based game protocol.
</p> </p>
</section1> </section1>
@ -59,7 +59,7 @@
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p> <p>
This document addresses the requirements for a game protocol as defined by &xep-mug;. This document addresses the requirements for a game protocol as defined by &xep-mug;.
In particular this consists of: In particular this consists of:
</p> </p>
<ol start='1'> <ol start='1'>
<li>game roles</li> <li>game roles</li>
@ -95,7 +95,7 @@
<section1 topic='Game Roles' anchor='roles'> <section1 topic='Game Roles' anchor='roles'>
<p> <p>
A Tic-tac-toe game uses two game roles, "x" and "o". A Tic-tac-toe game uses two game roles, "x" and "o".
Both roles have to be assigned to exactly one player to start a match. Both roles have to be assigned to exactly one player to start a match.
If one role gets unassigned or a player gets unavailable the match has to be paused. If one role gets unassigned or a player gets unavailable the match has to be paused.
</p> </p>
@ -112,8 +112,8 @@
</ol> </ol>
<p> <p>
An implementation MUST be able to handle the a board with three cols and rows An implementation MUST be able to handle the a board with three cols and rows
and three respective marks to win. and three respective marks to win.
Everything beyond that is OPTIONAL. Everything beyond that is OPTIONAL.
</p> </p>
<example caption='Service Sends Configuration Form'><![CDATA[ <example caption='Service Sends Configuration Form'><![CDATA[
<iq from='tictactoe@games.shakespeare.lit' <iq from='tictactoe@games.shakespeare.lit'
@ -122,16 +122,16 @@
type='result'> type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'> <query xmlns='http://jabber.org/protocol/mug#owner'>
<options> <options>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Tic-tac-toe Room</title> <title>Tic-tac-toe Room</title>
... ...
</x> </x>
<options xmlns='http://jabber.org/protocol/mug/tictactoe'> <options xmlns='http://jabber.org/protocol/mug/tictactoe'>
<x xmlns='jabber:x:data' type='form'> <x xmlns='jabber:x:data' type='form'>
<title>Configuration for Tic-tac-toe</title> <title>Configuration for Tic-tac-toe</title>
<instructions> <instructions>
Below you can see the default configuration. Below you can see the default configuration.
To accept the default configuration, click OK. To accept the default configuration, click OK.
To select a different configuration, please complete this form. To select a different configuration, please complete this form.
</instructions> </instructions>
<field var='FORM_TYPE' type='hidden'> <field var='FORM_TYPE' type='hidden'>
@ -238,7 +238,7 @@
when one player reaches the number of respective marks as defined by the strike option. when one player reaches the number of respective marks as defined by the strike option.
After termination the service broadcasts the final state including either a &lt;draw&gt; After termination the service broadcasts the final state including either a &lt;draw&gt;
or &lt;won&gt; (including a game role) element to indicate the resulting score or &lt;won&gt; (including a game role) element to indicate the resulting score
and the initial state of the next round. and the initial state of the next round.
</p> </p>
<example caption='Service Sends Draw State'><![CDATA[ <example caption='Service Sends Draw State'><![CDATA[
<presence <presence
@ -261,7 +261,7 @@
<section1 topic='Turns' anchor='turn'> <section1 topic='Turns' anchor='turn'>
<p> <p>
During the game, players change in turn, each of them MUST send only one move at a time. During the game, players change in turn, each of them MUST send only one move at a time.
It MUST possess these attributes: It MUST possess these attributes:
<table caption='&MOVE; attributes'> <table caption='&MOVE; attributes'>
<tr> <tr>
@ -287,15 +287,15 @@
</table> </table>
</p> </p>
<example caption='Juliet Sends a Move'><![CDATA[ <example caption='Juliet Sends a Move'><![CDATA[
<message <message
to='tictactoe@games.shakespeare.lit' to='tictactoe@games.shakespeare.lit'
from='juliet@capulet.com/garden' from='juliet@capulet.com/garden'
type='chat'> type='chat'>
<turn xmlns='http://jabber.org/protocol/mug#user'> <turn xmlns='http://jabber.org/protocol/mug#user'>
<move <move
xmlns='http://jabber.org/protocol/mug/tictactoe' xmlns='http://jabber.org/protocol/mug/tictactoe'
row='3' row='3'
col='2' col='2'
id='7'/> id='7'/>
</turn> </turn>
</message> </message>

2
inbox/tictactoe.xml
View File

@ -129,7 +129,7 @@
During the game, players change in turn, each of them sending one move at a time. During the game, players change in turn, each of them sending one move at a time.
The player with the role 'x' makes the first move. The player with the role 'x' makes the first move.
A game move is represented as a &MESSAGE; stanza addressed to the full JID of the other player. A game move is represented as a &MESSAGE; stanza addressed to the full JID of the other player.
It MUST have a &THREAD; child element which specifies the match ID. It MUST have a &THREAD; child element which specifies the match ID.
Furthermore, the &MESSAGE; stanza contains a &TURN; element which in turn contains exactly one &MOVE; element Furthermore, the &MESSAGE; stanza contains a &TURN; element which in turn contains exactly one &MOVE; element
qualified by 'http://jabber.org/protocol/games/tictactoe'. qualified by 'http://jabber.org/protocol/games/tictactoe'.
It MUST possess these attributes: It MUST possess these attributes:

314
inbox/user-auth.xml
View File

@ -45,80 +45,80 @@
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p> <p>
This document offers mechanisms to solve the following problem: This document offers mechanisms to solve the following problem:
There are two XMPP client entities (Verifier and Prover). The There are two XMPP client entities (Verifier and Prover). The
Verifier can be presenting e.g., a physical device, an application Verifier can be presenting e.g., a physical device, an application
or a service and and the Prover is presenting an XMPP account of or a service and and the Prover is presenting an XMPP account of
user entity (e.g., a human) that wants to login. user entity (e.g., a human) that wants to login.
Before the Verifier can execute or ask executing any access Before the Verifier can execute or ask executing any access
control mechanism, e.g., to check if the Prover's XMPP accout is control mechanism, e.g., to check if the Prover's XMPP accout is
authorized use certain resource(s), the Prover must be authenticated. authorized use certain resource(s), the Prover must be authenticated.
We present usage of two-factor authentication in which the following We present usage of two-factor authentication in which the following
authentication factors are used: authentication factors are used:
</p> </p>
<ul> <ul>
<li> <li>
A knowledge factor that means something only the user knows. A knowledge factor that means something only the user knows.
In this application this knowledge is a shared secret known In this application this knowledge is a shared secret known
only by the Prover and Verifier, and a full JID of the only by the Prover and Verifier, and a full JID of the
Verifier where a password calculated from this secret must Verifier where a password calculated from this secret must
be sent to. be sent to.
Notice that Prover's XMPP account's username and password Notice that Prover's XMPP account's username and password
are not necessarily used as knowledge factors, if, e.g., are not necessarily used as knowledge factors, if, e.g.,
mechanisms presented in &xep0175; are used. mechanisms presented in &xep0175; are used.
</li> </li>
<li> <li>
The second factor is a possession factor that means something only The second factor is a possession factor that means something only
the user has, e.g., a device or application that the user the user has, e.g., a device or application that the user
wants to use. The shared secret can be told only to certain wants to use. The shared secret can be told only to certain
Prover XMPP account that is running in a certain device or in Prover XMPP account that is running in a certain device or in
certain application. certain application.
</li> </li>
</ul> </ul>
<p> <p>
In addition to these, described mechanism offers possibility to In addition to these, described mechanism offers possibility to
approve authentication inside only a certain time-slot. approve authentication inside only a certain time-slot.
</p> </p>
<p> <p>
Prover and Verifier entities mean same as in &rfc6238; but are Prover and Verifier entities mean same as in &rfc6238; but are
implemented as two XMPP clients. When using terms of &xep0146;, implemented as two XMPP clients. When using terms of &xep0146;,
Prover is Local Client and Verifier is Remote Client. Prover is Local Client and Verifier is Remote Client.
</p> </p>
<p> <p>
Several mechanisms for client-to-client authentication, such as Several mechanisms for client-to-client authentication, such as
&xep0250; exist and can be used with the protocol defined in &xep0250; exist and can be used with the protocol defined in
this document. This document describes a new simple and this document. This document describes a new simple and
extendable protocol for two-factor one-way client authentication extendable protocol for two-factor one-way client authentication
by specifying a profile on &xep0050;. One-way here means that by specifying a profile on &xep0050;. One-way here means that
the actual user (e.g, a human) of Prover's XMPP Client is not the actual user (e.g, a human) of Prover's XMPP Client is not
required to know anything about the Verifier. required to know anything about the Verifier.
</p> </p>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p> <p>This document addresses the following requirements:</p>
<ul> <ul>
<li>Enable the Verifier entity to perform authentication of <li>Enable the Verifier entity to perform authentication of
their users (e.g., humans) by verifying that a Prover entity their users (e.g., humans) by verifying that a Prover entity
holds a shared secret.</li> holds a shared secret.</li>
<li>Verifier's and Prover's XMPP accounts do not necessarily need <li>Verifier's and Prover's XMPP accounts do not necessarily need
to know each other beforehand nor be contacts.</li> to know each other beforehand nor be contacts.</li>
<li>Re-use existing XMPP and Jabber protocols wherever possible.</li> <li>Re-use existing XMPP and Jabber protocols wherever possible.</li>
</ul> </ul>
</section1> </section1>
<section1 topic='Discovery' anchor='disco'> <section1 topic='Discovery' anchor='disco'>
<p> <p>
A client MAY advertise any authentication commands it A client MAY advertise any authentication commands it
supports via &xep0030; (as described in <cite>XEP-0050</cite>). supports via &xep0030; (as described in <cite>XEP-0050</cite>).
</p> </p>
<p> <p>
If these commands are advertised, &xep0115; can be used to If these commands are advertised, &xep0115; can be used to
query capability of authentication commands in a client. query capability of authentication commands in a client.
If the Prover and the Verifier are working on a same physical If the Prover and the Verifier are working on a same physical
device, they both MAY know the exact format and existence of supported device, they both MAY know the exact format and existence of supported
commands. commands.
</p> </p>
</section1>SkkdJi88C())oo </section1>SkkdJi88C())oo
@ -129,15 +129,15 @@
</p> </p>
<dl> <dl>
<di><dt>HMAC</dt><dd>Keyed-Hashing for Message Authentication</dd></di> <di><dt>HMAC</dt><dd>Keyed-Hashing for Message Authentication</dd></di>
<di><dt>HMAC-SHA-256</dt><dd>HMAC-SHA-256 is the realization of the <di><dt>HMAC-SHA-256</dt><dd>HMAC-SHA-256 is the realization of the
HMAC message authentication code using the SHA-256 hash function.</dd></di> HMAC message authentication code using the SHA-256 hash function.</dd></di>
<di><dt>HMAC-SHA-512</dt><dd>HMAC-SHA-512 is the realization of the <di><dt>HMAC-SHA-512</dt><dd>HMAC-SHA-512 is the realization of the
HMAC message authentication code using the SHA-512 hash function.</dd></di> HMAC message authentication code using the SHA-512 hash function.</dd></di>
<di><dt>HOTP</dt><dd>HMAC-Based One-Time Password Algorithm</dd></di> <di><dt>HOTP</dt><dd>HMAC-Based One-Time Password Algorithm</dd></di>
<di><dt>Local Client</dt><dd>An XMPP client that wants to authenticate <di><dt>Local Client</dt><dd>An XMPP client that wants to authenticate
itself to Remote Client.</dd></di> itself to Remote Client.</dd></di>
<di><dt>One-time pad</dt><dd>Example of perfectly secret encryption scheme.</dd></di> <di><dt>One-time pad</dt><dd>Example of perfectly secret encryption scheme.</dd></di>
<di><dt>OTP</dt><dd>A one-time password is a password that is valid <di><dt>OTP</dt><dd>A one-time password is a password that is valid
for only one login session or transaction.</dd></di> for only one login session or transaction.</dd></di>
<di><dt>Prover</dt><dd>Same as Local Client.</dd></di> <di><dt>Prover</dt><dd>Same as Local Client.</dd></di>
<di><dt>Remote Client</dt><dd>An XMPP client that authenticates Local Client.</dd></di> <di><dt>Remote Client</dt><dd>An XMPP client that authenticates Local Client.</dd></di>
@ -148,8 +148,8 @@
</section1> </section1>
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Use Cases' anchor='usecases'>
<p> <p>
This document defines a profile of <cite>XEP-0050</cite> that This document defines a profile of <cite>XEP-0050</cite> that
enables a client to perform the following tasks on a entity enables a client to perform the following tasks on a entity
that or which resources it wants to use: that or which resources it wants to use:
</p> </p>
<ol> <ol>
@ -158,13 +158,13 @@
<li>Authenticate with a ...</li> <li>Authenticate with a ...</li>
</ol> </ol>
<p> <p>
Although this document aims to define common use cases for Although this document aims to define common use cases for
authentication, an implementation or deployment MAY support any authentication, an implementation or deployment MAY support any
subset and MAY support additional commands not defined herein. subset and MAY support additional commands not defined herein.
</p> </p>
<p> <p>
<em>Note: The text that follows assumes that implementors have <em>Note: The text that follows assumes that implementors have
read and understood <cite>XEP-0050</cite>, password read and understood <cite>XEP-0050</cite>, password
generation algorithms described in &rfc4226; and <cite>RFC 6238</cite></em>, generation algorithms described in &rfc4226; and <cite>RFC 6238</cite></em>,
and randomness requirements described in &rfc4086;, and randomness requirements described in &rfc4086;,
and know about one-time pads and perfect secrecy. and know about one-time pads and perfect secrecy.
@ -172,11 +172,11 @@
<section2 topic='Authenticate with a Time-Based One-Time Password (TOTP)' anchor='set-totp'> <section2 topic='Authenticate with a Time-Based One-Time Password (TOTP)' anchor='set-totp'>
<p> <p>
Time-Based One-Time Password (TOTP) algorithm described in Time-Based One-Time Password (TOTP) algorithm described in
<cite>RFC 6238</cite> is an extension of the HMAC-based <cite>RFC 6238</cite> is an extension of the HMAC-based
One-Time Password (HOTP) algorithm defined in <cite>RFC 4226</cite>, One-Time Password (HOTP) algorithm defined in <cite>RFC 4226</cite>,
to support the time-based moving factor. In TOTP, time to support the time-based moving factor. In TOTP, time
reference and a time step replaces the counter in the HOTP reference and a time step replaces the counter in the HOTP
computation. computation.
</p> </p>
<example caption='Local Client (Prover) requests to authenticate with a TOTP to a Remote Client (Verifier)'><![CDATA[ <example caption='Local Client (Prover) requests to authenticate with a TOTP to a Remote Client (Verifier)'><![CDATA[
@ -185,19 +185,19 @@
type='set' type='set'
id='set-totp-1' id='set-totp-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='http://jabber.org/protocol/auth#set-totp'/> node='http://jabber.org/protocol/auth#set-totp'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service <link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p> SHOULD return the appropriate form.</p>
<example caption='Remote Client (Verifier) replies with a form to set a TOTP'><![CDATA[ <example caption='Remote Client (Verifier) replies with a form to set a TOTP'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='set-totp-1' id='set-totp-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -224,7 +224,7 @@
type='set' type='set'
id='set-totp-2' id='set-totp-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/auth#set-totp' node='http://jabber.org/protocol/auth#set-totp'
sessionid='set-status:20131020T1320Z'> sessionid='set-status:20131020T1320Z'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -237,9 +237,9 @@
]]></example> ]]></example>
<p>After receiving a correct secret, the Verifier informs Prover of completion.</p> <p>After receiving a correct secret, the Verifier informs Prover of completion.</p>
<example caption='Remote Client (Verifier) informs Local Client (Prover) of completion'><![CDATA[ <example caption='Remote Client (Verifier) informs Local Client (Prover) of completion'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='set-totp-2' id='set-totp-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -249,16 +249,16 @@
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Authenticate with a one-time pad' anchor='set-otpad'> <section2 topic='Authenticate with a one-time pad' anchor='set-otpad'>
<p> <p>
As described in &rfc4949; one-time pad is an encryption As described in &rfc4949; one-time pad is an encryption
algorithm in which the key is a random sequence of symbols algorithm in which the key is a random sequence of symbols
and each symbol is used for encryption only one time, and each symbol is used for encryption only one time,
i.e., used to encrypt only one plaintext symbol and thus i.e., used to encrypt only one plaintext symbol and thus
produce only one ciphertext symbol and thus produce only one produce only one ciphertext symbol and thus produce only one
ciphertext symbol. A copy of the key is used similarly ciphertext symbol. A copy of the key is used similarly
for decryption. for decryption.
</p> </p>
<example caption='Local Client (Prover) requests to authenticate with a one-time pad to a Remote Client (Verifier)'><![CDATA[ <example caption='Local Client (Prover) requests to authenticate with a one-time pad to a Remote Client (Verifier)'><![CDATA[
@ -267,20 +267,20 @@
type='set' type='set'
id='set-otpad-1' id='set-otpad-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
action='execute' action='execute'
node='http://jabber.org/protocol/auth#set-otpad'/> node='http://jabber.org/protocol/auth#set-otpad'/>
</iq> </iq>
]]></example> ]]></example>
<p>Unless an error occurs (see the <p>Unless an error occurs (see the
<link url='#errors'>Error Handling</link> section below), the service <link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p> SHOULD return the appropriate form.</p>
<example caption='Remote Client (Verifier) replies with a form to set a one-time pad'><![CDATA[ <example caption='Remote Client (Verifier) replies with a form to set a one-time pad'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='set-otpad-1' id='set-otpad-1'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -307,7 +307,7 @@
type='set' type='set'
id='set-otpad-2' id='set-otpad-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/auth#set-otpad' node='http://jabber.org/protocol/auth#set-otpad'
sessionid='set-status:20131125T1022Z'> sessionid='set-status:20131125T1022Z'>
<x xmlns='jabber:x:data' type='submit'> <x xmlns='jabber:x:data' type='submit'>
@ -320,9 +320,9 @@
]]></example> ]]></example>
<p>After receiving a one-time pad, the Verifier informs Prover of completion.</p> <p>After receiving a one-time pad, the Verifier informs Prover of completion.</p>
<example caption='Remote Client (Verifier) informs Local Client (Prover) of completion'><![CDATA[ <example caption='Remote Client (Verifier) informs Local Client (Prover) of completion'><![CDATA[
<iq from='juliet@example.com/balcony' <iq from='juliet@example.com/balcony'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='result' type='result'
id='set-otpad-2' id='set-otpad-2'
xml:lang='en'> xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands' <command xmlns='http://jabber.org/protocol/commands'
@ -332,15 +332,15 @@
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Error Handling' anchor='errors'> <section1 topic='Error Handling' anchor='errors'>
<p> <p>
Several error conditions are possible when a Prover sends a Several error conditions are possible when a Prover sends a
command request to the Verifier, as defined in the following command request to the Verifier, as defined in the following
table. If one of these errors occurs, the Verifier entity MUST table. If one of these errors occurs, the Verifier entity MUST
return an error stanza to the requesting Prover. return an error stanza to the requesting Prover.
</p> </p>
@ -356,12 +356,12 @@
</tr>--> </tr>-->
<tr> <tr>
<td>&feature;</td> <td>&feature;</td>
<td>The specific command is not supported (even though the <td>The specific command is not supported (even though the
ad-hoc commands protocol is).</td> ad-hoc commands protocol is).</td>
</tr> </tr>
<tr> <tr>
<td>&forbidden;</td> <td>&forbidden;</td>
<td>The requesting entity does not have sufficient <td>The requesting entity does not have sufficient
privileges to perform the command.</td> privileges to perform the command.</td>
</tr> </tr>
<tr> <tr>
@ -370,14 +370,14 @@
</tr> </tr>
<tr> <tr>
<td>&payment;</td> <td>&payment;</td>
<td>If the user needs to provide payment in order to access <td>If the user needs to provide payment in order to access
to resources behind the Verifier (e.g., if the user is not to resources behind the Verifier (e.g., if the user is not
in the customer database or the customer's account is not in the customer database or the customer's account is not
paid up).</td> paid up).</td>
</tr> </tr>
</table> </table>
<p>For the syntax of these errors, see &xep0086;. Naturally, other <p>For the syntax of these errors, see &xep0086;. Naturally, other
errors may be returned as well.</p> errors may be returned as well.</p>
</section1> </section1>
@ -385,20 +385,20 @@
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<p> <p>
Implementations of this protocol MAY introduce extra forms for Implementations of this protocol MAY introduce extra forms for
commands and MAY use other secret key generation mechanisms than commands and MAY use other secret key generation mechanisms than
currently presented TOTP and one-time pad. currently presented TOTP and one-time pad.
</p> </p>
<p> <p>
There are several secure ways to transmit one-time pads or the There are several secure ways to transmit one-time pads or the
shared secret that is used in TOTP from Verifier to the Prover. shared secret that is used in TOTP from Verifier to the Prover.
If both Verifier and Prover entities are running in one If both Verifier and Prover entities are running in one
application inside one device, the shared secret can be application inside one device, the shared secret can be
generated and transmitted inside running implementation and generated and transmitted inside running implementation and
be removed right after the usage. be removed right after the usage.
</p> </p>
</section1> </section1>
<!--<section1 topic='Accessibility Considerations' anchor='access'> <!--<section1 topic='Accessibility Considerations' anchor='access'>
<p>OPTIONAL.</p> <p>OPTIONAL.</p>
</section1>--> </section1>-->
@ -408,106 +408,106 @@
</section1>--> </section1>-->
<section1 topic='Business Rules' anchor='rules'> <section1 topic='Business Rules' anchor='rules'>
<p>Presented authentication mechanism offers possibilities to <p>Presented authentication mechanism offers possibilities to
execute at least the following access policies and different execute at least the following access policies and different
combinations of them, but their detailed descriptions and how combinations of them, but their detailed descriptions and how
policies are transmitted to the Verifier are out of scope of policies are transmitted to the Verifier are out of scope of
this document:</p> this document:</p>
<ul> <ul>
<li> <li>
The policy MAY allow only anonymous XMPP accounts, only The policy MAY allow only anonymous XMPP accounts, only
non-anonymous XMPP accounts, or both, to be verified and/or non-anonymous XMPP accounts, or both, to be verified and/or
to access certain resources. to access certain resources.
No additional access control mechanisms are necessarily No additional access control mechanisms are necessarily
needed. needed.
</li> </li>
<li> <li>
The policy MAY allow, e.g., only JIDs in certain domains, The policy MAY allow, e.g., only JIDs in certain domains,
JIDs in a certain whitelist, JIDs in certain roster JIDs in a certain whitelist, JIDs in certain roster
group(s), or JIDs with certain subscription types to be group(s), or JIDs with certain subscription types to be
verified and/or to access certain resources. Additional verified and/or to access certain resources. Additional
mechanisms are required, e.g., to check wanted roster. mechanisms are required, e.g., to check wanted roster.
</li> </li>
</ul> </ul>
In each case, the Verifier MAY check Prover's JID right after In each case, the Verifier MAY check Prover's JID right after
receiving the first Ad-Hoc command or after a succesful verification receiving the first Ad-Hoc command or after a succesful verification
process. process.
If Prover's JID is not approved, the Verifier SHOULD If Prover's JID is not approved, the Verifier SHOULD
reply with &forbidden; error message. reply with &forbidden; error message.
After the a succesful verification the Verifier can, e.g., After the a succesful verification the Verifier can, e.g.,
<ul> <ul>
<li>start the wanted process,</li> <li>start the wanted process,</li>
<li>ask access rights from additional provision servers, <li>ask access rights from additional provision servers,
e.g. with &xep0324;, and/or</li> e.g. with &xep0324;, and/or</li>
<li>give access to the wanted resource.</li> <li>give access to the wanted resource.</li>
</ul> </ul>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p> <p>
Mechanisms for determining when a command can be executed based Mechanisms for determining when a command can be executed based
on permissions or rights are considered specific to the on permissions or rights are considered specific to the
application and/or implementation of <cite>XEP-0050</cite>, as application and/or implementation of <cite>XEP-0050</cite>, as
defined in <cite>XEP-0050</cite>. defined in <cite>XEP-0050</cite>.
In this application a command SHOULD be executed if and only In this application a command SHOULD be executed if and only
if it comes from full user's JID that is already known to if it comes from full user's JID that is already known to
the Verifier. This decreases possibility to execute, e.g, the Verifier. This decreases possibility to execute, e.g,
relay attacks. relay attacks.
Determining other permissions or rights are considered specific Determining other permissions or rights are considered specific
to access policies of systems, as presented in to access policies of systems, as presented in
<link url='#rules'>Business Rules</link> section. <link url='#rules'>Business Rules</link> section.
</p> </p>
<p> <p>
Possibility of executing Denial-of-service (DoS) attacks against Possibility of executing Denial-of-service (DoS) attacks against
the Verifier can be reduced by ending processing of received the Verifier can be reduced by ending processing of received
messages coming from not authorized JIDs or containing incorrect messages coming from not authorized JIDs or containing incorrect
secret as early as possible. secret as early as possible.
</p> </p>
<p> <p>
Randomness requirements for security described in Randomness requirements for security described in
<cite>RFC 4086</cite> apply. <cite>RFC 4086</cite> apply.
</p> </p>
<p> <p>
When using TOTP, security considerations of When using TOTP, security considerations of
<cite>RFC 6238</cite> apply. <cite>RFC 6238</cite> apply.
</p> </p>
<p> <p>
When using TOTP, HMAC-SHA-256 or HMAC-SHA-512 functions SHOULD When using TOTP, HMAC-SHA-256 or HMAC-SHA-512 functions SHOULD
be used instead of the HMAC-SHA-1 that has been specified for be used instead of the HMAC-SHA-1 that has been specified for
the HOTP computation in <cite>RFC 4226</cite>. the HOTP computation in <cite>RFC 4226</cite>.
</p> </p>
<p> <p>
When using TOTP, when an OTP is generated at the end of a When using TOTP, when an OTP is generated at the end of a
time-step window, the receiving time most likely falls into the time-step window, the receiving time most likely falls into the
next time-step window. A validation system MUST set a policy next time-step window. A validation system MUST set a policy
for an acceptable OTP transmission delay window for validation. for an acceptable OTP transmission delay window for validation.
A larger acceptable delay window would expose a larger window A larger acceptable delay window would expose a larger window
for attacks, so as in <cite>RFC 6238</cite>, we RECOMMEND that for attacks, so as in <cite>RFC 6238</cite>, we RECOMMEND that
at most one time step is allowed as the network delay. at most one time step is allowed as the network delay.
</p> </p>
<p> <p>
As described in <link url='#intro'>Introduction</link>, the As described in <link url='#intro'>Introduction</link>, the
user of the Prover XMPP client does not necessarily know user of the Prover XMPP client does not necessarily know
anything about the Verifier. In addition to this, the user anything about the Verifier. In addition to this, the user
does not necessarily know what the device or the application does not necessarily know what the device or the application
will do after a succesful authentication. Notice that this will do after a succesful authentication. Notice that this
problem relates to every closed source XMPP client problem relates to every closed source XMPP client
implementations, thus implementations' code SHOULD be open implementations, thus implementations' code SHOULD be open
source. source.
</p> </p>
<p> <p>
When using one-time pads, to ensure one-time use, the copy of When using one-time pads, to ensure one-time use, the copy of
the key used for encryption MUST be destroyed after use, as the key used for encryption MUST be destroyed after use, as
is the copy used for decryption. is the copy used for decryption.
</p> </p>
<p> <p>
When using one-time pads, commands containing pads that have When using one-time pads, commands containing pads that have
incorrect pad length, SHOULD not be executed. incorrect pad length, SHOULD not be executed.
</p> </p>
</section1> </section1>
@ -517,17 +517,17 @@
</p> </p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-protocol'> <section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
<p>The XMPP Registrar includes 'http://jabber.org/protocol/auth' <p>The XMPP Registrar includes 'http://jabber.org/protocol/auth'
in its registry of protocol namespaces (see &NAMESPACES;).</p> in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2> </section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'> <section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&xep0068; defines a process for standardizing the fields used <p>&xep0068; defines a process for standardizing the fields used
within Data Forms scoped by a particular namespace within Data Forms scoped by a particular namespace
(see also &FORMTYPES;). The reserved fields for the (see also &FORMTYPES;). The reserved fields for the
'http://jabber.org/protocol/auth' namespace are specified 'http://jabber.org/protocol/auth' namespace are specified
below.</p> below.</p>
<code caption='Registry Submission'><![CDATA[ <code caption='Registry Submission'><![CDATA[
<form_type> <form_type>
@ -546,7 +546,7 @@
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
<p> <p>
Because the protocol defined here is a profile of Because the protocol defined here is a profile of
<cite>XEP-0050</cite>, no schema definition is needed. <cite>XEP-0050</cite>, no schema definition is needed.
</p> </p>
</section1> </section1>

12
inbox/xtls.xml
View File

@ -230,7 +230,7 @@
<section2 topic='Sending Encrypted Stanzas' anchor='stanzas'> <section2 topic='Sending Encrypted Stanzas' anchor='stanzas'>
<p>After the TLS handshake has been completed, the parties exchange encrypted data over the tunnel. Because the routing information is already present in the IQ stanzas used by XTLS, it is OPTIONAL for the stanzas encapsulated in the XTLS stream to include routing information (i.e., the 'from' and 'to' attributes). In that case, the entity receiving the data MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.</p> <p>After the TLS handshake has been completed, the parties exchange encrypted data over the tunnel. Because the routing information is already present in the IQ stanzas used by XTLS, it is OPTIONAL for the stanzas encapsulated in the XTLS stream to include routing information (i.e., the 'from' and 'to' attributes). In that case, the entity receiving the data MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.</p>
<example caption='A Stanza to Send'><![CDATA[ <example caption='A Stanza to Send'><![CDATA[
<message <message
from='romeo@montague.lit/orchard' from='romeo@montague.lit/orchard'
to='juliet@capulet.lit//chamber' to='juliet@capulet.lit//chamber'
type='chat'> type='chat'>
@ -270,7 +270,7 @@
<section2 topic='Closing the XTLS Tunnel' anchor='close'> <section2 topic='Closing the XTLS Tunnel' anchor='close'>
<p>Either party can close the XTLS tunnel; this is done by sending an IQ-set containing an empty &lt;close/&gt; element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;. However, if the entities have a mutual presence subscription then it is RECOMMENDED for the entities to maintain the tunnel until one entity becomes unavailable. Keeping the XTLS tunnel open does not require significant resources and prevents the need for a new TLS handshake.</p> <p>Either party can close the XTLS tunnel; this is done by sending an IQ-set containing an empty &lt;close/&gt; element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;. However, if the entities have a mutual presence subscription then it is RECOMMENDED for the entities to maintain the tunnel until one entity becomes unavailable. Keeping the XTLS tunnel open does not require significant resources and prevents the need for a new TLS handshake.</p>
<example caption='One Party Closes the XTLS Tunnel'><![CDATA[ <example caption='One Party Closes the XTLS Tunnel'><![CDATA[
<iq type='set' <iq type='set'
from='romeo@montague.net/orchard' from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony' to='juliet@capulet.com/balcony'
id='xtls_10'> id='xtls_10'>
@ -279,7 +279,7 @@
]]></example> ]]></example>
<p>The other party then acknowledges that the tunnel is closed by sending an IQ-result containing an empty &lt;closed/&gt; element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.</p> <p>The other party then acknowledges that the tunnel is closed by sending an IQ-result containing an empty &lt;closed/&gt; element qualified by the 'urn:xmpp:tmp:xtls' namespace &NSNOTE;.</p>
<example caption='Other Party Acknowledges Closing of the Tunnel'><![CDATA[ <example caption='Other Party Acknowledges Closing of the Tunnel'><![CDATA[
<iq type='result' <iq type='result'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
id='xtls_10'> id='xtls_10'>
@ -288,7 +288,7 @@
]]></example> ]]></example>
<p>If the tunnel is unknown to the receiving party, it MUST return an &notfound; error.</p> <p>If the tunnel is unknown to the receiving party, it MUST return an &notfound; error.</p>
<example caption='Unknown Tunnel'><![CDATA[ <example caption='Unknown Tunnel'><![CDATA[
<iq type='error' <iq type='error'
from='juliet@capulet.com/balcony' from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard' to='romeo@montague.net/orchard'
id='xtls_10'> id='xtls_10'>
@ -332,7 +332,7 @@
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>This entire document addresses security. Particular security-related issues are discussed in the following sections.</p> <p>This entire document addresses security. Particular security-related issues are discussed in the following sections.</p>
<section2 topic='Mandatory-to-Implement Technologies' anchor='security-mti'> <section2 topic='Mandatory-to-Implement Technologies' anchor='security-mti'>
<p>An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.</p> <p>An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.</p>
</section2> </section2>
<section2 topic='Certificates' anchor='security-certs'> <section2 topic='Certificates' anchor='security-certs'>
<p>As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS tunnel will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;.</p> <p>As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS tunnel will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;.</p>
@ -344,7 +344,7 @@
</section2> </section2>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'> <section2 topic='Protocol Namespaces' anchor='ns'>

4
xep-0313.xml
View File

@ -152,7 +152,7 @@
</section1> </section1>
<section1 topic='Message archives' anchor='archives'> <section1 topic='Message archives' anchor='archives'>
<p>An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction, <p>An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction,
and a server is not bound to any particular implementation or arrangement of data stores.</p> and a server is not bound to any particular implementation or arrangement of data stores.</p>
<p>Exactly which messages a server archives is up to implementation and deployment policy, <p>Exactly which messages a server archives is up to implementation and deployment policy,
but it is expected that all messages that hold meaningful content, rather than state changes such as Chat State Notifications, would be archived. Rules are specified later in this document.</p> but it is expected that all messages that hold meaningful content, rather than state changes such as Chat State Notifications, would be archived. Rules are specified later in this document.</p>
@ -178,7 +178,7 @@
reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted
to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages.</p> to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages.</p>
<p>However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted <p>However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted
sensitive information may omit the &lt;message&gt; stanza from inside the &lt;forwarded&gt; element or replace the sensitive information may omit the &lt;message&gt; stanza from inside the &lt;forwarded&gt; element or replace the
message with an appropriate placeholder when transmitting the result in response to a query. However servers message with an appropriate placeholder when transmitting the result in response to a query. However servers
MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent. MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent.

48
xep-0369.xml
View File

@ -45,7 +45,7 @@
Remove namespace references in Info/Config nodes; Remove namespace references in Info/Config nodes;
Modify Participant and JID Map syntaxes; Modify Participant and JID Map syntaxes;
Clarifications on subscription to participants node and using this to receive Nick changes; Clarifications on subscription to participants node and using this to receive Nick changes;
Replace use of "query" as MIX defined operations for setting nick; Replace use of "query" as MIX defined operations for setting nick;
</p></remark> </p></remark>
</revision> </revision>
<revision> <revision>
@ -418,10 +418,10 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "&lt;generated identifier&gt;#&lt;channel&gt;@&lt;mix domain&gt;". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character. The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "&lt;generated identifier&gt;#&lt;channel&gt;@&lt;mix domain&gt;". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character.
</p> </p>
<p> <p>
The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned. The mapping of real bare JID to proxy JID is defined when a participant joins a channel. While a user is a participant in a Channel, the mapping between real JID and proxy JID MUST NOT be changed. This mapping must be maintained after the user leaves the channel. Proxy JID values MUST NOT be re-used. If a JID that left a channel joins the channel again the same proxy JID MAY be used again or a different new proxy JID MAY be assigned.
</p> </p>
<p> <p>
The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated. The example real full JIDs in this specification are aligned the anticipated new format that splits the resource into two parts. The first part is UUID that is a stable and fixed value for the client and is anticipated to be a fixed format which may well be UUID 4. The second part is server assigned and will vary with each session. A realistic JID with resource is: 'hag66@shakespeare.example/d104f6a7-97e9-477f-8947-e4a37691d7ee/7533375f2cd'. This specification uses examples of the style: 'hag66@shakespeare.example/UUID-a1j/7533' which are aligned to real resources, but more compact. CITATION TO BE ADDED. If the final specification differs from this, the examples will be updated.
</p> </p>
<p> <p>
The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID. The full JIDs held in the presence nodes are anonymized using a similar mechanism. First the bare JID is mapped to a bare proxy JID, using the mapping held in the "urn:xmpp:mix:nodes:jidmap" node for the bare JID. Then the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
@ -493,7 +493,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub. When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
</p> </p>
<p> <p>
Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node. Users MAY subscribe to and read information this node, when permitted by the channel. Standard PubSub access will allow a full list of participants and associated nicks to be determined. By subscribing to the node, a user will be informed of changes to the Participants Node.
</p> </p>
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.</p> <p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.</p>
<example caption="Value of Participants Node"><![CDATA[ <example caption="Value of Participants Node"><![CDATA[
@ -521,14 +521,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</items> </items>
]]></example> ]]></example>
</section3> </section3>
<section3 topic="JID Maybe Visible Map Node" anchor="jid-map2-node"> <section3 topic="JID Maybe Visible Map Node" anchor="jid-map2-node">
<p>The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID. <p>The JID Maybe Visible Map node is a similar node to the JID Map node that is used in addition to the JID Map Node in JID Maybe Visible channels. All participants may subscribe to and access this node. It uses the same encoding as JID Map node and all participant JIDs MUST be included. Where a participant's preference is to not share the JID, the encoded participant value is the proxy JID. This will enable a user looking up a JID to clearly determine that the user preference is to not share the JID and to clearly distinguish this case from an erroneous proxy JID.
</p> </p>
</section3> </section3>
<section3 topic="Presence Node" anchor="presence-node"> <section3 topic="Presence Node" anchor="presence-node">
<p> <p>
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence stanza. The full proxy JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control MAY be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
@ -638,7 +638,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<tr><td>'Configuration Node Access'</td><td>Controls who can subscribe to configuration node and who has read access to it.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'owners'</td></tr> <tr><td>'Configuration Node Access'</td><td>Controls who can subscribe to configuration node and who has read access to it.</td><td>list-single</td><td>'participants'; 'allowed'; 'nobody'; 'admins'; 'owners' </td><td>'owners'</td></tr>
<tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr> <tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr> <tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
<tr><td>'Open Presence'</td><td>If selected, any client MAY register presence. If not selected, only clients with bare JID in the participants list are allowed to register presence.</td><td>boolean</td><td>-</td><td>false</td></tr> <tr><td>'Open Presence'</td><td>If selected, any client MAY register presence. If not selected, only clients with bare JID in the participants list are allowed to register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are REQUIRED to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr> <tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are REQUIRED to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
<tr><td>'User Message Retraction'</td><td>If this option is selected users will be able to retract messages that they have sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr> <tr><td>'User Message Retraction'</td><td>If this option is selected users will be able to retract messages that they have sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
@ -901,7 +901,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<participant xmlns='urn:xmpp:mix:0'> <participant xmlns='urn:xmpp:mix:0'>
<nick>top witch</nick> <nick>top witch</nick>
</participant> </participant>
</item> </item>
</items> </items>
</pubsub> </pubsub>
<items> <items>
@ -1080,7 +1080,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Roster Management" anchor="usecase-roster-management"> <section3 topic="Roster Management" anchor="usecase-roster-management">
<p> <p>
As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined.
This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user. This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel to the user.
</p> </p>
<p> <p>
If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as described below. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this. If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as described below. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this.
@ -1089,7 +1089,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p> <p>
The user's server MUST remove this roster entry when the user leaves the channel. The user's server MUST remove this roster entry when the user leaves the channel.
</p> </p>
<p> <p>
A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel. A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
</p> </p>
@ -1098,7 +1098,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref"> <section3 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref">
<p>A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values: <p>A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
</p> </p>
<ol> <ol>
<li>'default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set. This means JID is visible for a JID Visible channel and JID is hidden for JID Hidden and JID Maybe Visible channels.</li> <li>'default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set. This means JID is visible for a JID Visible channel and JID is hidden for JID Hidden and JID Maybe Visible channels.</li>
<li>'never'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID Visible.</li> <li>'never'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID Visible.</li>
@ -1414,7 +1414,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p> <p>
When an Nick is assigned, the MIX server MUST update the Participants Node in the channel to reflect this change. Any users subscribed to this node will be notified of the change of Nick. When an Nick is assigned, the MIX server MUST update the Participants Node in the channel to reflect this change. Any users subscribed to this node will be notified of the change of Nick.
</p> </p>
<p>The following example shows an example of reporting successful Nick assignment.</p> <p>The following example shows an example of reporting successful Nick assignment.</p>
<example caption="Service Returns User of Nick"><![CDATA[ <example caption="Service Returns User of Nick"><![CDATA[
<iq type='result' <iq type='result'
@ -1505,13 +1505,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3> </section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids"> <section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p> <p>
Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels. Presence information will provide a MIX client with the nicks and proxy JIDs for participants in a channel. Messages sent to a channel and retrieved from MAM archives will show the proxy JID and nick of the sender. It is sometimes useful to determine the real JID associated with proxy JID. This can always be done for JID Visible channels and can sometimes be done for JID Maybe Visible channels.
</p> </p>
<p> <p>
For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node. This is shown in the following example: For current users JID visible rooms, the real JID is found by a PubSub lookup on the JID Map node. This is shown in the following example:
</p> </p>
<example caption='Client looks up Real JID from Proxy JID'><![CDATA[ <example caption='Client looks up Real JID from Proxy JID'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573' <iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27' id='kl2fax27'
@ -1540,9 +1540,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<items> <items>
</iq>]]> </example> </iq>]]> </example>
<p>For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node. Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID. </p> <p>For JID Maybe Visible rooms the lookup is performed on the JID Maybe Visible Map node. Note that where a user prefers to not share real JID, the result of this lookup of proxy JID will be the (same) proxy JID. </p>
<p> <p>
When an older message is considered, it is possible that the proxy JID of the sender is not current. Such a JID can be looked up in the MAM Archive of the JID Map Node. This is shown in the following example: When an older message is considered, it is possible that the proxy JID of the sender is not current. Such a JID can be looked up in the MAM Archive of the JID Map Node. This is shown in the following example:
</p> </p>
@ -1561,7 +1561,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<field var='id'> <field var='id'>
<value>123456#coven@mix.shakespeare.example</value> <value>123456#coven@mix.shakespeare.example</value>
</field> </field>
</x> </x>
</query> </query>
</iq> </iq>
@ -1589,8 +1589,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='kl2fax27' id='kl2fax27'
type='result'> type='result'>
</iq>]]> </example> </iq>]]> </example>
</section3> </section3>
@ -1646,8 +1646,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example> ]]></example>
<p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in <p>The MIX channel then puts a copy of the message into the MAM archive for the channel and sends a copy of the message to each participant in
standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.</p> standard groupchat format. These messages sent by the channel are addressed to the bare JID of each participant and this will be handled by the participant's local server. The message from value is the JID of the channel. To enable sender identification, the Nick and bare proxy JID of the sender are included in the message as MIX parameters. The id of the message is the ID from the MAM archive and NOT the id used by the sender. The message placed in the MAM archive is the reflected message without a 'to' element.</p>
<example caption="Channel Puts Message in MAM Archive"><![CDATA[ <example caption="Channel Puts Message in MAM Archive"><![CDATA[
<message from='coven@mix.shakespeare.example' <message from='coven@mix.shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'