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'>
<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[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -95,13 +95,13 @@ S: <stream:features>
</stream:features>
C: <starttls 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'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<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'>
Y2FwdWxldC5saXQ=</auth>
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features/>
<!-- 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.
-->
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>
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>
]]></example>
<example caption='Bidirectional Streams with Server Dialback'><![CDATA[
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='65b30434afd7646699d077f7affcb2c120c48e18'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
@ -145,13 +145,13 @@ S: <stream:features>
</stream:features>
C: <starttls 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'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
C: <stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns:db='jabber:server:dialback'
to='montague.lit' from='capulet.lit'
xml:lang='en' version='1.0'>
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
S: <stream:stream xmlns='jabber:server' xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en'
id='b5cd769b1dc292c6f6557fe76cabc4d112333f9a'
from='montague.lit' to='capulet.lit' version='1.0'>
S: <stream:features>
<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.
-->
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>
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>
S: <db:result from='conference.montague.lit' to='capulet.lit'>
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
-->
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 topic="Buddycloud Channels" anchor="Buddycloud Channels">
<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
name (example:
<link url="buddycloud:juliet@capulit.lit">juliet@capulet.lit</link>
@ -232,7 +232,7 @@
]]>
</example>
<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>
<example caption="The Entity sends a disco#info request to each component">
<![CDATA[
@ -280,7 +280,7 @@
</section2>
</section1>
<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>
<example caption="The Entity sends a register request to the domain">
@ -294,11 +294,11 @@
]]>
</example>
<p>The register request creates the user's personal channels on first use
and has the additional benefit of creating additional new channel nodes
<p>The register request creates the user's personal channels on first use
and has the additional benefit of creating additional new channel nodes
as they become available on the server (e.g. 'status' node, 'geoloc' nodes).
</p>
</section1>
<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
@ -767,32 +767,32 @@
<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.
</p>
<section2 topic="Retrieving items" anchor="items-retrieve">
<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>
<example caption="Recent items query">
<![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z"
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z"
max="50"
parent-only="true" />
</pubsub>
parent-only="true" />
</pubsub>
</iq>
]]>
</example>
<example caption="Recent items reply">
<![CDATA[
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/romeo@montague.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,16584564008760001">
...atom payload...
@ -811,16 +811,16 @@
...atom payload...
</item>
</items>
</pubsub>
</pubsub>
</iq>
]]>
</example>
<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
<em>parent-only</em> allows users to requests posts which only start a discussion
<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
<em>parent-only</em> allows users to requests posts which only start a discussion
(i.e. no reply posts).</p>
<section4 topic="Error Cases" anchor="items-recent-errorcases">
<p>The following extended error cases are used:
</p>
@ -843,19 +843,19 @@
</li>
</ul>
</section4>
</section3>
</section2>
<section2 topic="Deleting items" anchor="items-delete">
<example caption="The client sends">
<![CDATA[
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/>
</retract>
</pubsub>
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/>
</retract>
</pubsub>
</iq>
]]>
</example>
@ -868,10 +868,10 @@
replace the deleted post
<example caption="The Buddycloud server sends retractions out to online clients">
<![CDATA[
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts">
<retract id="1291048772456"/>
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts">
<retract 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">
<updated>2012-07-01T15:08:32.950Z</updated>
@ -884,8 +884,8 @@
<verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb>
</deleted-entry>
</item>
</items>
</event>
</items>
</event>
</message>
]]>
</example>
@ -1209,7 +1209,7 @@
<p>
The Buddycloud server should make sure that the remote server
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? -->
process and confirming the same XMPP component name.
</p>

84
inbox/calendaring.xml
View File

@ -15,17 +15,17 @@
<!ENTITY ITEM "&lt;item/&gt;">
<!ENTITY ITEMS "&lt;items/&gt;">
<!ENTITY PUBSUB "&lt;pubsub/&gt;">
<!ENTITY VEVENT "&lt;vevent/&gt;">
<!ENTITY VTODO "&lt;vtodo/&gt;">
<!ENTITY VJOURNAL "&lt;vjournal/&gt;">
<!ENTITY VFREEBUSY "&lt;vfreebusy/&gt;">
<!ENTITY VALARM "&lt;valarm/&gt;">
<!ENTITY VTIMEZONE "&lt;vtimezone/&gt;">
<!ENTITY SN "calendar">
<!ENTITY NS "urn:xmpp:tmp:&SN;:0">
<!ENTITY TODO "## TODO. ##">
]>
<?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>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>
<!-- == How It Works ===================================================== -->
<section2 topic='How It Works' anchor='intro-howitworks'>
@ -135,7 +135,7 @@ END:VCALENDAR
]]></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>
</section2>
<!-- == Formatting 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>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>
<!-- == Related Documents ================================================ -->
<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>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 ================================================= -->
<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>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>
<!-- == Calendar 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>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>
<!-- == Calendar Items =================================================== -->
<section2 topic='Calendar Items' anchor='datamodel-items'>
@ -265,7 +265,7 @@ END:VCALENDAR
-->
<p>&TODO;</p>
</section2>
<!-- == Calendar Entry State ============================================= -->
<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 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>
<!-- == Calendar Item Revisions ========================================== -->
<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 retrieving calendar objects from a calendar node or sending pubsub notifications to subscribers.</li>
</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>
<!-- == Request Sequencing =============================================== -->
<section2 topic='Request Sequencing' anchor='requestsequencing'>
@ -300,9 +300,9 @@ END:VCALENDAR
======================================================================= -->
<section1 topic='Discovering Support' anchor='disco'>
<!-- == Service Features ================================================= -->
<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>
<example caption='Entity queries calendar service regarding supported features'><![CDATA[
@ -327,9 +327,9 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Node Information ================================================= -->
<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>
<example caption='Entity queries a node for information'><![CDATA[
@ -437,7 +437,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<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>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<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>
<example caption='Service does not allow creation of calendar nodes'><![CDATA[
@ -476,7 +476,7 @@ END:VCALENDAR
</iq>
]]></example>
</section3>
<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>
<example caption='Requesting entity has insufficient privileges to create calendar nodes'><![CDATA[
@ -628,7 +628,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<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>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>
<!-- == Error Cases ====================================================== -->
<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>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<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>
<example caption='Entity attempts to publish item with invalid payload'><![CDATA[
@ -676,15 +676,15 @@ END:VCALENDAR
</iq>
]]></example>
</section3>
<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>
</section3>
<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>
</section3>
<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>
<ul>
@ -737,7 +737,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='retrieve-success'>
@ -763,7 +763,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='retrieve-error'>
@ -779,11 +779,11 @@ END:VCALENDAR
<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>
</section3>
<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>
</section3>
<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>
<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>
</ul>
</section3>
<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>
</section3>
@ -834,7 +834,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Success Case ===================================================== -->
<section2 topic='Success Case' anchor='freebusy-success'>
@ -860,7 +860,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Error Cases ====================================================== -->
<section2 topic='Error Cases' anchor='freebusy-error'>
@ -919,7 +919,7 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Subscribing to Alarm Notifications =============================== -->
<section2 topic='Subscribing to Alarm Notifications' anchor='alarm-subscribe'>
@ -946,9 +946,9 @@ END:VCALENDAR
</iq>
]]></example>
</section2>
<!-- == Receiving Alarm Notifications ==================================== -->
<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>
<section3 topic='Notification With Payload' anchor='alarm-notify-withpayload'>
@ -1002,10 +1002,10 @@ END:VCALENDAR
</section1>
<section1 topic='Examples' anchor='examples'>
<section2 topic='Published Event Examples' anchor='examples-event'>
<p>&TODO;</p>
<section3 topic='A Minimal Published Event'></section3>
<section3 topic='Changing 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'>
<p>&TODO;</p>
<section3 topic='A Group Event Request'></section3>
<section3 topic='Reply To A Group Event Request'></section3>
<section3 topic='Update An Event'></section3>
@ -1037,7 +1037,7 @@ END:VCALENDAR
<section2 topic='Busy Time Examples' anchor='examples-freebusy'>
<p>&TODO;</p>
<!-- <section3 topic='Request Busy Time'></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'>
<p>&TODO;</p>
<section3 topic='A Recurring Event Spanning Time Zones'></section3>
<section3 topic='Modify A Recurring Instance'></section3>
<section3 topic='Cancel an Instance'></section3>
@ -1084,7 +1084,7 @@ END:VCALENDAR
<section2 topic='Journal Examples' anchor='examples-journal'>
<p>&TODO;</p>
</section2>
<section2 topic='Notification Examples' anchor='examples-notification'>
<p>&TODO;</p>
</section2>

10
inbox/carbons.xml
View File

@ -66,7 +66,7 @@
<p>This XEP defines an approach for ensuring that all of my devices
get both sides of all conversations in order to avoid user
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>
</section1>
@ -110,7 +110,7 @@
<feature var='urn:xmpp:carbons:0'/>
...
</query>
</iq>]]></example>
</iq>]]></example>
</section2>
<section2 topic='Enabling Carbons' anchor='enabling'>
@ -236,7 +236,7 @@
RECOMMENDED. (Note: another XEP might be written to document
traditional resource locking, if the documentation in &rfc3921bis;
is not sufficient.)</p>
<p>Also note that &xep0085; recommends sending chat state
notifications as chat type messages, which means that they will be
subject to Carbon-copying. This is intentional.</p>
@ -328,7 +328,7 @@
copied client had terminated the conversation. In order to
prevent unwanted termination of conversations on other resources,
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>
<p>Upon receiving an outbound notification of any chat state other
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>
</section1>
<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 topic='XMPP Registrar Considerations' anchor='reg'>
<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
Juliet has her phone screen turned off and is not interested in the status of her contacts unless they are
communicating with her.</p>
<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>
<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>
</section2>
@ -90,12 +90,12 @@
<example caption='Client indicates it is inactive'><![CDATA[
<inactive xmlns='urn:xmpp:csi'/>
]]></example>
<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[
<active xmlns='urn:xmpp:csi'/>
]]></example>
<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>
</section2>
@ -103,10 +103,10 @@
<section1 topic='Business Rules' anchor='rules'>
<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>
<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>
<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
fully standard behaviour of XMPP is required.</p>

24
inbox/content-types.xml
View File

@ -4,9 +4,9 @@
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!--
<!--
© XMPP Standards Foundation, 2016
Author: Peter Waher
Author: Peter Waher
-->
<xep>
<header>
@ -57,7 +57,7 @@ Author: Peter Waher
</p>
<example caption='Hinting at a content type'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -76,7 +76,7 @@ Author: Peter Waher
</p>
<example caption='Alternate encoding'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -96,7 +96,7 @@ Author: Peter Waher
</p>
<example caption='Alternate encodings'>
<![CDATA[
<message
<message
from='person1@example.org/34892374'
to='person2@example.org/938089023'
type='chat'>
@ -156,20 +156,20 @@ Author: Peter Waher
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Content Types' anchor='contentTypes'>
<p>
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
encodings in the same message.
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
encodings in the same message.
</p>
</section2>
<section2 topic='Custom Content Types' anchor='customTypes'>
<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.
</p>
</section2>
<section2 topic='Stanza size' anchor='stanzaSize'>
<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.
</p>
</section2>
@ -186,9 +186,9 @@ Author: Peter Waher
<code>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<!--
<!--
© XMPP Standards Foundation, 2016
Author: Peter Waher
Author: Peter Waher
-->
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'

2
inbox/decloak.xml
View File

@ -167,7 +167,7 @@
<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>
<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>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>
</presence>
]]></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 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>
@ -349,7 +349,7 @@
<body>Message 4.</body>
</message>
]]></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 topic='sync' anchor='Re-Syncing after Connectivity Loss'>
<p>To follow.</p>
@ -365,11 +365,11 @@
</section1>
<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 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 topic='Acknowledgements' anchor='ack'>

34
inbox/dmuc3.xml
View File

@ -51,7 +51,7 @@
<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.
It needs no bandwidth for remote rooms without local occupants.
</p>
</p>
</section2>
<section2 topic='Requirements' anchor='reqs'>
<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>
]]></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,
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
@ -191,13 +191,13 @@ will contain information like if the room is moderated, how much history, who is
id='roster1'
type='set'>
<roster xmlns='urn:xmpp:dmuc:0'>
<item affiliation='owner'
<item affiliation='owner'
jid='scott@fairfax.tridsys.com' name='Scott'/>
<item affiliation='admin'
<item affiliation='admin'
jid='kevin@fairfax.tridsys.com' name='Kevin'/>
<item affiliation='none'
<item affiliation='none'
jid='wayne@raleigh.tridsys.com' name='Wayne'/>
<item affiliation='none'
<item affiliation='none'
jid='keith@raleigh.tridsys.com' name='Keith'/>
</roster>
</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'
id='history'
type='get'>
<room xmlns='urn:xmpp:dmuc:0'
<room xmlns='urn:xmpp:dmuc:0'
id='chatroom@conference.fairfax.tridsys.com'>
<history xmlns='http://jabber.org/protocol/muc'/>
</room>
@ -227,20 +227,20 @@ will contain information like if the room is moderated, how much history, who is
id='history1'
type='result'>
<history xmlns='http://jabber.org/protocol/muc'>
<message xmlns='jabber:client'
<message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Wayne' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay'
from='wayne@raleigh.tridsys.com/TransVerse'
<delay xmlns='urn:xmpp:delay'
from='wayne@raleigh.tridsys.com/TransVerse'
stamp='2011-01-19T08:02:43Z'/>
</message>
...
</message>
<message xmlns='jabber:client'
<message xmlns='jabber:client'
from='chatroom@conference.fairfax.tridsys.com/Scott' type='groupchat'>
<body>All work and no play makes Jack a dull boy</body>
<delay xmlns='urn:xmpp:delay'
from='scott@fairfax.tridsys.com/TransVerse'
<delay xmlns='urn:xmpp:delay'
from='scott@fairfax.tridsys.com/TransVerse'
stamp='2011-01-19T08:23:10Z'/>
<body>All work and no play makes Jack a dull boy</body>
</message>
@ -293,7 +293,7 @@ will contain information like if the room is moderated, how much history, who is
</section3>
<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
need to know.
</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'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'>
<registration-required
<registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'>
<registration-required
<registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</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>
</presence>
]]></example>
<example caption='Mirror delivers join to its occupants'><![CDATA[
<presence
from='chatroom@conference.fairfax.tridsys.com/Kevin'

12
inbox/dna.xml
View File

@ -56,7 +56,7 @@
<di>
<dt>Self-hosted domain</dt>
<dd>A domain whose owner acts as its hosting provider.</dd>
</di>
</di>
<di>
<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>
@ -115,7 +115,7 @@
<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 following domain names are used in the examples:</p>
<dl>
<dl>
<di>
<dt>asserted.tld</dt>
<dd>The domain name being asserted.</dd>
@ -180,7 +180,7 @@
<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>The following domain names are used in the examples:</p>
<dl>
<dl>
<di>
<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>
@ -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>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'/>
</stream:features>
]]></example>
@ -296,7 +296,7 @@ CN=server.originatingprovider.tld
<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>
<example caption='Server assertion'><![CDATA[<stream:features>
<example caption='Server assertion'><![CDATA[<stream:features>
<assert xmlns='urn:xmpp:dna:0' from='target.tld'/>
</stream:features>
]]></example>
@ -315,7 +315,7 @@ CN=server.originatingprovider.tld
<p>The domains offered are International Domain Names, as specified in <strong>rfc3920bis</strong>.</p>
</section1>
<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 include a mechanism for revocation.</p>
</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>
<example><![CDATA[
<message from='romeo@example.net/orchard'
id='6410ed123'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<signed xmlns='urn:xmpp:signed:0'>
@ -213,7 +213,7 @@
error condition element of &lt;bad-signature/&gt; as shown below:</p>
<example><![CDATA[
<message from='romeo@example.net/orchard'
id='6410ed123'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<e2e xmlns='urn:xmpp:signed:0'>

4
inbox/fmuc.xml
View File

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

22
inbox/instant-gaming.xml
View File

@ -132,7 +132,7 @@
</query>
</iq>]]></example>
</section2>
<section2 topic='Invitation' anchor='1to1-invite'>
<p>
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'/>
</invite>
</message>]]></example>
<table caption='Invitation types'>
<tr>
<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>
</tr>
--> </table>
<p>
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.
@ -260,7 +260,7 @@
<thread>romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234</thread>
<join xmlns='http://jabber.org/protocol/games'/>
</message>]]></example>
<p>
A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.
</p>
@ -281,9 +281,9 @@
</error>
</message>]]></example>
</section2>
<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.
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).
@ -324,13 +324,13 @@
<saved xmlns='http://jabber.org/protocol/games'/>
</message>]]></example>
<p>After receiving such an notification, an implementation MAY decide to save the game, too.</p>
<p>
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.
The game protocol MUST define whether its game has to be saved independently or mutually.
</p>
<p>
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.
@ -373,7 +373,7 @@
</section2>
<section2 topic='Game Loading' anchor='1to1-load'>
<p>
<p>
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.
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.
If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it.
</p>
<table caption='Termination reasons'>
<tr>
<th>Reason</th>
@ -550,7 +550,7 @@
xmlns='http://jabber.org/protocol/games'
elementFormDefault='qualified'>
<xs:import
<xs:import
namespace='jabber:x:data'
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.
</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
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,
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
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,
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
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.
</p>
@ -267,7 +267,7 @@
<section1 topic='Use Cases' anchor='usecases'>
<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>.
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,
with some differences, as will be described in this document.
</p>
@ -285,7 +285,7 @@
<section2 topic='Request Subscription of momentary values' anchor='subscribemomentary'>
<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.
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.
</p>
<example caption='Subscription request of momentary values from a device'>
@ -325,7 +325,7 @@
id='S0002'>
<subscribe xmlns='urn:xmpp:iot:events' seqnr='1' momentary='true' maxInterval='PT5M'/>
</iq>
<iq type='error'
from='device@clayster.com'
to='client@clayster.com/amr'
@ -380,7 +380,7 @@
id='S0003'>
<unsubscribe xmlns='urn:xmpp:iot:events' seqnr='1'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='client@clayster.com/amr'
@ -610,7 +610,7 @@
</section2>
<section2 topic='Overriding subscriptions' anchor='overriding'>
<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.
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>
@ -652,7 +652,7 @@
elementFormDefault='qualified'>
<xs:import namespace='urn:xmpp:iot:sensordata'/>
<xs:element name='subscribe'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'>

2
inbox/jid-mention.xml
View File

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

8
inbox/jingle-ibb.xml
View File

@ -114,9 +114,9 @@ Initiator Responder
]]></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>
<example caption='An IBB packet'><![CDATA[
<iq from='romeo@montague.net/orchard'
<iq from='romeo@montague.net/orchard'
id='ls72b58f'
to='juliet@capulet.com/balcony'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='ch3d9s71'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
@ -128,9 +128,9 @@ Initiator Responder
</iq>
]]></example>
<example caption='An IBB ack'><![CDATA[
<iq from='juliet@capulet.com/balcony'
<iq from='juliet@capulet.com/balcony'
id='ls72b58f'
to='romeo@montague.net/orchard'
to='romeo@montague.net/orchard'
type='result'/>
]]></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>

38
inbox/jingle-nodes.xml
View File

@ -121,7 +121,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</services>
</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>
</section2>
</section2>
<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>
<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'/>
</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>
</section2>
</section2>
<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>
<example caption="Service List Request"><![CDATA[
@ -162,7 +162,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</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>
<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">
<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>
@ -236,35 +236,35 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<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>REQUIRED on response, NOT RECOMMENDED on requests</td>
</tr>
</tr>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
</table>
@ -279,10 +279,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<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>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'>
<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'>
<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>
@ -303,19 +303,19 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<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>REQUIRED</td>
</tr>
</tr>
<tr>
<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>
</tr>
<tr>
<td>protocol</td>
<td>The protocol supported by the retrieved service.</td>
<td>The protocol supported by the retrieved service.</td>
<td>REQUIRED</td>
</tr>
</table>
</section2>
</section2>
</section1>
<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>
@ -429,14 +429,14 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<xs:element name='services'>
<xs:complexType>
<xs:sequence>
<xs:element name='relay'
<xs:element name='relay'
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element name='tracker'
<xs:element name='tracker'
type='serviceElementType'
minOccurs='0'
maxOccurs='unbounded'/>
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>

14
inbox/jingle-s5b.xml
View File

@ -256,15 +256,15 @@ Romeo Juliet
<content creator='initiator' name='a-file-offer'>
<description xmlns='urn:xmpp:jingle:apps:stub:0'/>
<transport xmlns='urn:xmpp:jingle:transports:s5b:0'
sid='vj3hs98y'
sid='vj3hs98y'
mode='tcp'>
<streamhost
jid='romeo@montague.lit/orchard'
host='192.168.4.1'
<streamhost
jid='romeo@montague.lit/orchard'
host='192.168.4.1'
port='5086'/>
<streamhost
jid='streamer.shakespeare.lit'
host='24.24.24.1'
<streamhost
jid='streamer.shakespeare.lit'
host='24.24.24.1'
zeroconf='_jabber.bytestreams'/>
</transport>
</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
s=-
t=0 0
a=group:BUNDLE audio
a=group:BUNDLE audio
a=msid-semantic: WMS QoHel4kmL4ZFaJuTwmz3VpyxzMRCcNDEmcCl
</session>
<content creator='initiator' name='audio'>

10
inbox/jingle-xtls.xml
View File

@ -315,11 +315,11 @@ Initiator Responder
A B
| |
| challengeSaltA |
|=========================>|
|=========================>|
| challengeSaltB + hashB |
|<=========================|
|<=========================|
| hashA |
|=========================>|
|=========================>|
hashB = sha1(publicKeyB + password + challengeSaltA + respondSaltB)
hashA = sha1(publicKeyA + password + challengeSaltB + respondSaltA)
@ -330,9 +330,9 @@ hashA = sha1(publicKeyA + password + challengeSaltB + respondSaltA)
A B
| |
| respondSaltB |
|<=========================|
|<=========================|
| respondSaltA |
|=========================>|
|=========================>|
]]></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>
<ul>

4
inbox/jingle-zrtp.xml
View File

@ -90,7 +90,7 @@ a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46d
<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>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
<iq type='get'
from='calvin@usrobots.lit/lab'
to='herbie@usrobots.lit/home'
id='disco1'>
@ -98,7 +98,7 @@ a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46d
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
<iq type='result'
from='herbie@usrobots.lit/home'
to='calvin@usrobots.lit/lab'
id='disco1'>

2
inbox/json.xml
View File

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

178
inbox/lop.xml
View File

@ -104,17 +104,17 @@
</p>
<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>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>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>
</ul>
<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>
</section1>
@ -136,7 +136,7 @@
<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>
</ul>
<section3 topic="Rules Regarding Farm Presence">
<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.
@ -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>
</ul>
</section3>
<section3 topic="Spawning a Virtual Machine">
<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>.
</p>
<ul>
<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>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>
@ -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>
<ul>
<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_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_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>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul>
<li><tt>&lt;species_not_supported/&gt;</tt></li>
@ -179,72 +179,72 @@
<li><tt>&lt;malformed_packet/&gt;</tt></li>
<li><tt>&lt;internal_error/&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>
<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">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascript"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" vm_species="javascript"/>
</iq>
]]></example>
<example caption="An unsuccessful &lt;spawn_vm/&gt; request."><![CDATA[<iq from="lp1@linkedprocess.org/villein"
]]></example>
<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">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascr"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
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">
<service_unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<species_not_supported xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
'javascr' is not a supported virtual machine species
</text>
</error>
</text>
</error>
</iq>
]]></example>
</section3>
<section3 topic="Submitting a Job to a Virtual Machine">
<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.
</p>
<ul>
<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>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>
</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>
<ul>
<ul>
<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>&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>
<ul>
<li><tt>&lt;malformed_packet/&gt;</tt></li>
<li><tt>&lt;internal_error/&gt;</tt></li>
<li><tt>&lt;evaluation_error/&gt;</tt></li>
<li><tt>&lt;permission_denied/&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_not_found/&gt;</tt></li>
<li><tt>&lt;malformed_packet/&gt;</tt></li>
<li><tt>&lt;internal_error/&gt;</tt></li>
<li><tt>&lt;evaluation_error/&gt;</tt></li>
<li><tt>&lt;permission_denied/&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_not_found/&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>
<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">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
var temp=0;
@ -255,7 +255,7 @@
</submit_job>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
10
@ -265,14 +265,14 @@
<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>.
</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">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
temp + 1;
</submit_job>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
11
@ -295,12 +295,12 @@
<evaluation_error xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
ReferenceError: "bad_variable" is not defined at line number 1
</text>
</text>
</error>
</iq>
]]></example>
]]></example>
</section3>
<section3 topic="Determining the Status of a Virtual Machine Job">
<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.
@ -314,7 +314,7 @@
</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>
<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>status</tt> attribute: the job's status. This MUST be provided if <tt>&lt;iq type="result"/&gt;</tt>.</li>
<ul>
@ -331,17 +331,17 @@
</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">
<ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" status="in_progress"/>
</iq>
]]></example>
</section3>
<section3 topic="Aborting a Virtual Machine Job">
<p>
@ -354,10 +354,10 @@
<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>
</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>
<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>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul>
@ -369,32 +369,32 @@
</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">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
]]></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">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="zzzz"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
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">
<item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<job_not_found xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
Job 'zzzz' was not found in the virtual machine.
</text>
</error>
</text>
</error>
</iq>
]]></example>
</section3>
@ -420,7 +420,7 @@
</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>
<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>&lt;binding/&gt;</tt> child tag of <tt>&lt;manage_bindings/&gt;</tt> for <tt>&lt;iq type="get"/&gt;</tt></li>
<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>
</ul>
</ul>
</ul>
</ul>
<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">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
@ -446,12 +446,12 @@
</manage_bindings>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
]]></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">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age"/>
@ -459,7 +459,7 @@
</manage_bindings>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<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"/>
@ -469,22 +469,22 @@
]]></example>
<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
<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.
</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">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="fact"/>
</manage_bindings>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="zzzz">
<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"/>
</manage_bindings>
</iq>
@ -494,7 +494,7 @@
while(true) {
x = x + 0.0001;
}</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>
</section3>
<section3 topic="Terminating a Virtual Machine">
@ -504,12 +504,12 @@ while(true) {
<ul>
<li>Villein generated <tt>&lt;iq type="get"&gt;</tt> <tt>&lt;terminate_vm/&gt;</tt>:</li>
<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>
</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>
<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>One of these error conditions MUST be provided if <tt>&lt;iq type="error"/&gt;</tt>.</li>
<ul>
@ -520,12 +520,12 @@ while(true) {
</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">
<terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
]]>
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
<![CDATA[<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
@ -546,13 +546,13 @@ while(true) {
</p>
<ul>
<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>
<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.
</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>
<table caption='Fields of the data forms for the disco#info of a farm.'>
<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>
</ul>
</section3>
</section2>
<section2 topic="Registry Use Cases">
<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.
</p>
<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"/>
<presence to="lp2@linkedprocess.org/farm"
<presence to="lp2@linkedprocess.org/farm"
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"/>
<presence from="lp2@linkedprocess.org/farm"
<presence from="lp2@linkedprocess.org/farm"
to="lp3@linkedprocess.org/registry" type="subscribed"/>
]]>
</example>
@ -724,12 +724,12 @@ while(true) {
<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>.
</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">
<query xmlns="http://jabber.org/protocol/disco#items"/>
</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">
<query xmlns="http://jabber.org/protocol/disco#items">
<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.
</p>
<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>
<p>
The following <tt>&lt;feature/&gt;</tt>s MUST be supported by a registry:
@ -914,7 +914,7 @@ while(true) {
<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>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>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>
@ -933,7 +933,7 @@ while(true) {
<li><tt>http://linkedprocess.org/2006/06/Farm#</tt></li>
<li><tt>http://linkedprocess.org/2006/06/Registry#</tt></li>
</ul>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<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:complexType>
</xs:element>
<xs:element name='submit_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
</xs:complexType>
</xs:element>
<xs:element name='ping_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
@ -978,21 +978,21 @@ while(true) {
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name='abort_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:attribute name='job_id' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='manage_bindings'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:element ref='binding'/>
</xs:complexType>
</xs:element>
<xs:element name='binding'>
<xs:complexType>
<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:complexType>
</xs:element>
<xs:element name='malformed_packet' type='empty'/>
<xs:element name='wrong_farm_password' type='empty'/>
<xs:element name='internal_error' type='empty'/>

2
inbox/message-retraction.xml
View File

@ -41,7 +41,7 @@
</revision>
</header>
<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 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>

150
inbox/moved.xml
View File

@ -86,28 +86,28 @@
<section1 topic='Introduction' anchor='intro'>
<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
an easier JID to remember.
an easier JID to remember.
</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
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.
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>The methods described here maintain compatibility with &rfc3920; and
<li>The methods described here maintain compatibility with &rfc3920; and
&rfc3921;</li>
</ul>
</section1>
<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
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>
<dl>
@ -116,23 +116,23 @@
<dt><strong>new JID</strong></dt>
<dd>user2@example2.com</dd>
</dl>
<section2 topic='Unsubscribing the original JID from outbound subscriptions'
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.
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>
<p>To unsubscribe all outbound subscriptions for the original JID send an
unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED;
<p>To unsubscribe all outbound subscriptions for the original JID send an
unsubscribe &PRESENCE; stanza to all the old contacts with a &MOVED;
element containing the new JID.</p>
<p>There is the potential for other users to send a malicious unsubscribe
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
<p>There is the potential for other users to send a malicious unsubscribe
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza when
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>
<example caption='Client unsubscribes outbound subscriptions from original JID'>
@ -148,20 +148,20 @@
<section2 topic='Unsubscribing the original JID from inbound subscriptions'
anchor='unsubscribed'>
<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
subscription from. These can be identified as those in the 'from'
subscription state as defined in in the 'jabber:iq:roster' protocol
<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
subscription from. These can be identified as those in the 'from'
subscription state as defined in in the 'jabber:iq:roster' protocol
in &rfc3921;.</p>
<p>To unsubscribe all inbound subscriptions send an unsubscribed
&PRESENCE; stanza to all the old contacts with a &MOVED; element
<p>To unsubscribe all inbound subscriptions send an unsubscribed
&PRESENCE; stanza to all the old contacts with a &MOVED; element
containing the new JID.</p>
<p>There is the potential for other users to send a malicious unsubscribed
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza
without displaying the &MOVED; JID to the user. See the Security
<p>There is the potential for other users to send a malicious unsubscribed
containing a spoofed &MOVED; JID. Therefore, clients SHOULD NOT
automatically subscribe to the JID contained in the &MOVED; stanza
without displaying the &MOVED; JID to the user. See the Security
Considerations section for details.</p>
<example caption='Client unsubscribes inbound subscriptions from original JID'>
@ -174,27 +174,27 @@
</example>
</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'>
<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
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.
</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
request and spoof the content of the &MOVED; element identifying an
original JID. Therefore, clients SHOULD NOT automatically unsubscribe
an existing roster entry if is listed as the target in the &MOVED;
element when a subscribe is received. See the Security
request and spoof the content of the &MOVED; element identifying an
original JID. Therefore, clients SHOULD NOT automatically unsubscribe
an existing roster entry if is listed as the target in the &MOVED;
element when a subscribe is received. See the Security
Consideration section for details.</p>
<p>Clients accepting the moved subscription SHOULD indicate to the
user that that this subscription request was the result of a move
operation and because of potential malicious behavior SHOULD NOT
user that that this subscription request was the result of a move
operation and because of potential malicious behavior SHOULD NOT
auto-accept the subscription without displaying the &MOVED; JID to the
user.</p>
@ -208,44 +208,44 @@
</example>
</section2>
<section2 topic='Contacts Offline at the Time the Rename Occurs'
<section2 topic='Contacts Offline at the Time the Rename Occurs'
anchor='offline'>
<p>&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza
MUST be preserved by the server and &PRESENCE; stanzas of type
unsubscribe and unsubscribed are not preserved on the server.
Therefore, for a contact who is offline, their servers MAY have
automatically removed the original roster entry when seeing the
unsubscribe and unsubscribed stanzas. At the time of writing this XEP,
NOT saving and forwarding the presence stanzas will be the default
<p>&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza
MUST be preserved by the server and &PRESENCE; stanzas of type
unsubscribe and unsubscribed are not preserved on the server.
Therefore, for a contact who is offline, their servers MAY have
automatically removed the original roster entry when seeing the
unsubscribe and unsubscribed stanzas. At the time of writing this XEP,
NOT saving and forwarding the presence stanzas will be the default
behavior of most servers.
</p>
<p>What this means is that a contact coming online after the rename
outlined above MAY only see the &PRESENCE; of type 'subscribe' with
<p>What this means is that a contact coming online after the rename
outlined above MAY only see the &PRESENCE; of type 'subscribe' with
the &MOVED; element. Clients should be aware of this behavior.
</p>
</section2>
<section2 topic='Presence Ordering' anchor='ordering'>
<p>In following the principle of least surprise, it is considered good
practice to send the subscribe stanza after the unsubscribe and unsubscribed
<p>In following the principle of least surprise, it is considered good
practice to send the subscribe stanza after the unsubscribe and unsubscribed
stanzas.
</p>
</section2>
<section2 topic='Preservation of Groups' anchor='grouping'>
<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.
</p>
<ul>
<li>If the contacts client receives an unsubscribed with a &MOVED;
element, remove the subscription but initiate a roster push for the
original JID with the subscription set to 'none'. When the new
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
<li>If the contacts client receives an unsubscribed with a &MOVED;
element, remove the subscription but initiate a roster push for the
original JID with the subscription set to 'none'. When the new
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
removed from the roster.
</li>
@ -254,7 +254,7 @@
</li>
</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.
If this occurs it will be impossible to preserve the original groups.
</p>
@ -264,10 +264,10 @@
<section2 topic='One-way subcriptions and full roster state' anchor='one-way'>
<section3 topic='One-way Inbound subscription' anchor='from_subs'>
<p>If the original JID, user@example.com, had only an inbound subscription
(from or pending in), then the contact will only receive an
unsubscribed &PRESENCE; stanza. The contact's client, knowing the
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 or pending in), then the contact will only receive an
unsubscribed &PRESENCE; stanza. The contact's client, knowing the
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
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
@ -277,11 +277,11 @@
</section3>
<section3 topic='One-way Outbound subscription' anchor='to_subs'>
<p>If the original JID, user@example.com, had only an outbound
subscription (to or ask), then the contact SHOULD only receive an
unsubscribe &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'from' from the contact's perspective),
at that point MAY choose to prompt
<p>If the original JID, user@example.com, had only an outbound
subscription (to or ask), then the contact SHOULD only receive an
unsubscribe &PRESENCE; stanza. The contact's client, knowing the
state of the subscription (which is 'from' 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>
<p>Because of the ability to spoof the &MOVED; element, the client SHOULD
@ -289,7 +289,7 @@
</section3>
<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>
<td>Server state</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
&PRESENCE; stanzas sent in from a client. This allows clients as well as
servers to implement these same procedures.</p>
<p>In order to prevent other users from maliciously altering contacts
the client SHOULD NOT automatically subscribe to a &MOVED; JID when it
<p>In order to prevent other users from maliciously altering contacts
the client SHOULD NOT automatically subscribe to a &MOVED; JID when it
receives an unsubscribe and SHOULD NOT automatically unsubscribe to
a &MOVED; JID when it receives a subscribe.</p>
@ -379,10 +379,10 @@
<ol>
<li>userA@example.com subscribes to userB@example.com</li>
<li>The userB@example.com automatically accepts the subscription from
userA@example.com. (Automatically done by the client using a simple
<li>The userB@example.com automatically accepts the subscription from
userA@example.com. (Automatically done by the client using a simple
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>
<li>The previous steps can be repeated and have userB@example.com subscribe
to a large number of people.</li>
@ -399,19 +399,19 @@
<status>Subscribe to me!</status>
<moved xmlns='urn:xmpp:moved:0' old='userA@example.com'/>
</presence>
]]>
]]>
</li>
<li>If userB's client automatically accepted the subscription without
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
the roster.
the roster.
</li>
</ol>
</section1>
<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 topic='XMPP Registrar Considerations' anchor='reg'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
@ -419,8 +419,8 @@
<ul>
<li>urn:xmpp:moved:0</li>
</ul>
<p>Upon advancement of this specification from a status of Experimental
to a status of Draft, the &REGISTRAR; shall add the foregoing namespace
<p>Upon advancement of this specification from a status of Experimental
to a status of Draft, the &REGISTRAR; shall add the foregoing namespace
to the registry located at &NAMESPACES;, as described in Section 4 of
&xep0053;.
</p>
@ -454,6 +454,6 @@
]]></code>
</section1>
<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>
</xep>

46
inbox/muc-admin.xml
View File

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

6
inbox/muc-light.xml
View File

@ -785,7 +785,7 @@
<user affiliation='none'>hag88@shakespeare.lit</user>
</query>
</iq>
<message from='coven@muclight.shakespeare.lit'
to='crone1@shakespeare.lit'
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>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>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'>
<example caption='Retrieving blocking list'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop' type='get' id='comp-getlist'>
@ -1533,7 +1533,7 @@
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='query'>
<xs:complexType>
<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>
<p>Moderated Room --
The owner is allowed to kick users, revoke roles and save the match; antonym: Unmoderated Room.</p>
<p>Hidden Room --
a room that cannot be found by any user through normal means such as searching and service discovery;
antonym: Public Room.</p>
<p>Public Room --
a room that can be found by any user through normal means such as searching and service discovery;
antonym: Hidden Room.</p>
<p>Members-Only Room --
a room that a user cannot enter without being on the member list;
antonym: Open Room.</p>
<p>Open Room --
a room that anyone may enter without being on the member list;
antonym: Members-Only Room.</p>
<p>Password-Protected Room --
a room that a user cannot enter without first providing the correct password;
antonym: Unsecured Room.</p>
@ -170,14 +170,14 @@
a room that anyone is allowed to enter without first providing the correct password;
antonym: Password-Protected Room.</p>
<p>Fully-Anonymous Room --
a room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone,
<p>Fully-Anonymous Room --
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>
<p>Semi-Anonymous Room --
a room in which an occupant's full JID can be discovered by the room owner only;
<p>Semi-Anonymous Room --
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>
<p>Non-Anonymous Room --
a room in which an occupant's full JID is exposed to all other occupants;
<p>Non-Anonymous Room --
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>
</section2>
@ -195,7 +195,7 @@
<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>
</section2>
<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,
represented here as the "island-chess@games.shakespeare.lit" room. The characters are as follows:
@ -237,7 +237,7 @@
<p>
Information about affiliations MUST be sent in all presence stanzas generated or reflected by the match and sent to occupants.
</p>
<section2 topic='Privileges' anchor='privileges'>
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.
@ -289,8 +289,8 @@
</p>
<section2 topic='Discovering MUG Component Support' anchor='disco-component'>
<p>
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
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
discovery information ("disco#info") query to the service's JID:
</p>
<example caption="Client Queries Gaming Service for MUG Support via Disco"><![CDATA[
@ -323,11 +323,11 @@
</iq>
]]></example>
</section2>
<section2 topic='Discovering Active Rooms' anchor='disco-matches'>
<p>
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
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
consist of the active game rooms hosted by the service.
</p>
<example caption="User Queries for Active Rooms"><![CDATA[
@ -359,9 +359,9 @@
</iq>
]]></example>
<p>
If the full list of rooms is large (see &xep0030; for details),
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 the full list of rooms is large (see &xep0030; for details),
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;)
to indicate that the list is not the full result set.
</p>
</section2>
@ -512,9 +512,9 @@
</iq>
]]></example>
<p>
If the full list of rooms is large,
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 the full list of rooms is large,
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;)
to indicate that the list is not the full result set.
</p>
@ -523,8 +523,8 @@
<section2 topic='Querying for Room Information' anchor='disco-matchinfo'>
<p>
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
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
room in order to discover the room configuration.
</p>
<example caption="Discovering Game Options of an Active Room"><![CDATA[
@ -578,8 +578,8 @@
</iq>
]]></example>
<p>
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
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
value is "http://jabber.org/protocol/mug#matchinfo".
It MUST include a 'mug#game' field specifiying the namespace of the
game.
@ -606,8 +606,8 @@
</iq>
]]></example>
<p>
An implementation MAY return a list of existing occupants if that
information is publicly available, or return no list at all if this
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 kept private.
</p>
<example caption='Room Returns Disco Item Results (Items are Public)'><![CDATA[
@ -622,8 +622,8 @@
</iq>
]]></example>
<p>
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,
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,
for example.
</p>
<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'>
<p>
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
&badrequest; error condition. If an occupant sends such a request, the service
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
&badrequest; error condition. If an occupant sends such a request, the service
MAY pass it through the intended recipient.
</p>
</section2>
<section2 topic='Discovering Client Support for MUG' anchor='disco-client'>
<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.
</p>
<example caption='User Queries Contact Regarding MUG Support'><![CDATA[
@ -678,9 +678,9 @@
</iq>
]]></example>
<p>
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;)
while specifying the Service Discovery node
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;)
while specifying the Service Discovery node
'http://jabber.org/protocol/mug#matches':
</p>
<example caption='User Queries Contact for Current Rooms'><![CDATA[
@ -836,7 +836,7 @@
]]></example>
<p>
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).
Thus the service MUST handle both the invites and declines.
</p>
@ -887,7 +887,7 @@
from='island-chess@games.shakespeare.lit/damsel'
to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='owner' role='White'/>
<item affiliation='owner' role='White'/>
</game>
</presence>
@ -895,7 +895,7 @@
from='island-chess@games.shakespeare.lit/lad'
to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/>
<item affiliation='none' role='Black'/>
</game>
</presence>
]]></example>
@ -910,7 +910,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples'
to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/>
<item affiliation='none'/>
</game>
</presence>
@ -918,7 +918,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples'
to='ferdinand@shakespeare.lit/laptop'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/>
<item affiliation='none'/>
</game>
</presence>
]]></example>
@ -928,23 +928,23 @@
from='island-chess@games.shakespeare.lit/KingOfNaples'
to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none'/>
<item affiliation='none'/>
</game>
</presence>
]]></example>
<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
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
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
"room roster".
</p>
</section3>
<section3 topic="Non-Anonymous Rooms" anchor='enter-nonanon'>
<p>
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
by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child
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
by the 'http://jabber.org/protocol/mug' namespace and containing an &ITEM; child
with a 'jid' attribute specifying the occupant's full JID:
</p>
<example caption="Service Sends Full JID to all Occupants"><![CDATA[
@ -952,7 +952,7 @@
from='island-chess@games.shakespeare.lit/KingOfNaples'
to='miranda@shakespeare.lit/desktop'
<game xmlns='http://jabber.org/protocol/mug'>
<item jid='alonso@shakespeare.lit/pda' affiliation='none'/>
<item jid='alonso@shakespeare.lit/pda' affiliation='none'/>
</game>
</presence>
@ -961,24 +961,24 @@
</section3>
<section3 topic="Semi-Anonymous Rooms" anchor='enter-semianon'>
<p>
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
only in the presence notifications it sends to the room owner and not to any other
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
only in the presence notifications it sends to the room owner and not to any other
occupant.
</p>
</section3>
<section3 topic="Fully-Anonymous Rooms" anchor='enter-fullyanon'>
<p>
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
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 any other occupant.
</p>
</section3>
<section3 topic='Password-Protected Rooms' anchor='enter-pw'>
<p>
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
user that they are unauthorized; this is done by returning a presence stanza of
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
user that they are unauthorized; this is done by returning a presence stanza of
type "error" specifying a &notauthorized; error:
</p>
<example caption='Service Denies Access Because No Password Provided'><![CDATA[
@ -994,11 +994,11 @@
]]></example>
<p>
Passwords SHOULD be supplied with the presence stanza sent when entering the room,
contained within an &lt;game/&gt; element qualified by the
'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
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>
contained within an &lt;game/&gt; element qualified by the
'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
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>
section of this document).
</p>
<example caption='User Provides Password On Entering a Room'><![CDATA[
@ -1015,9 +1015,9 @@
</section3>
<section3 topic='Members-Only Rooms' anchor='enter-members'>
<p>
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
room; this is done by returning a presence stanza of type "error" specifying a
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
room; this is done by returning a presence stanza of type "error" specifying a
&registration; error condition:
</p>
<example caption='Service Denies Access Because User Is Not on Member List'><![CDATA[
@ -1034,10 +1034,10 @@
</section3>
<section3 topic='Nickname Conflict' anchor='enter-conflict'>
<p>
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
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
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
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; error condition:
</p>
<example caption='Service Denies Access Because of Nick Conflict'><![CDATA[
@ -1065,9 +1065,9 @@
</section3>
<section3 topic='Max Users' anchor='enter-maxusers'>
<p>
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
by returning a presence stanza of type "error" specifying a &unavailable;
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
by returning a presence stanza of type "error" specifying a &unavailable;
error condition:
</p>
<example caption='Service Informs User that Room Occupant Limit Has Been Reached'><![CDATA[
@ -1088,7 +1088,7 @@
<section3 topic='Locked Room' anchor='enter-locked'>
<p>
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:
</p>
<example caption='Service Denies Access Because Room Does Not Exist'><![CDATA[
@ -1106,8 +1106,8 @@
<section3 topic='Nonexistent Room' anchor='enter-nonexistent'>
<p>
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
choose to restrict the privilege of creating rooms. For details, see the
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
<link url='#creatematch'>Creating a Room</link> section of this document.
</p>
</section3>
@ -1123,7 +1123,7 @@
from='ferdinand@shakespeare.lit/laptop'
to='island-chess@games.shakespeare.lit'>
<game xmlns='http://jabber.org/protocol/mug'>
<item role='Black'/>
<item role='Black'/>
</game>
</presence>
]]></example>
@ -1136,7 +1136,7 @@
from='island-chess@games.shakespeare.lit/lad'
to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/>
<item affiliation='none' role='Black'/>
</game>
</presence>
@ -1144,7 +1144,7 @@
from='island-chess@games.shakespeare.lit/lad'
to='ferdinand@shakespeare.lit/laptop'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/>
<item affiliation='none' role='Black'/>
</game>
</presence>
]]></example>
@ -1154,11 +1154,11 @@
from='island-chess@games.shakespeare.lit/lad'
to='alonso@shakespeare.lit/pda'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='none' role='Black'/>
<item affiliation='none' role='Black'/>
</game>
</presence>
]]></example>
<p>If the role is already taken, the service must return the following error.</p>
<example caption="Service Informs User About Role Conflict"><![CDATA[
@ -1170,7 +1170,7 @@
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
</presence>
]]></example>
<p>
If the requested role doesn't exist in the match, the service MUST return a not-acceptable error.
@ -1193,7 +1193,7 @@
]]></example>
<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.
</p>
@ -1232,7 +1232,7 @@
it MUST update the match status from inactive to active by a
presence broadcast to all occupants.
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.
</p>
@ -1420,7 +1420,7 @@
</message>
]]></example>
</section2>
<section2 topic='Resignation' anchor='mug-resign'>
<p>
If a client wants to resign, he sends the following.
@ -1440,7 +1440,7 @@
based on the game specification.
</p>
</section2>
<section2 topic='Termination' anchor='mug-term'>
<p>
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'>
<won>Black</won>
</state>
</game>
</game>
</presence>
]]></example>
]]></example>
</section2>
<section2 topic="Changing Nickname">
@ -1538,9 +1538,9 @@
<section2 topic='Sending a Private Message' anchor='privatemessage'>
<p>
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
type SHOULD be "chat", or MAY be left unspecified (i.e., a normal message). This privilege
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
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).
</p>
<example caption='Occupant Sends Private Message'><![CDATA[
@ -1552,7 +1552,7 @@
</message>
]]></example>
<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.
</p>
<example caption='Recipient Receives the Private Message'><![CDATA[
@ -1564,18 +1564,18 @@
</message>
]]></example>
<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.
</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.
</p>
</section2>
<section2 topic='Getting Member List' anchor='getmemberlist'>
<p>
If allowed in accordance with room configuration, an occupant MAY be allowed to
retrieve the list of room members. For details, see the
If allowed in accordance with room configuration, an occupant MAY be allowed to
retrieve the list of room members. For details, see the
<link url='#modifymember'>Modifying the Member List</link> section of this document.
</p>
</section2>
@ -1662,9 +1662,9 @@
<state xmlns='http://jabber.org/protocol/mug/chess'>
<match-canceled />
</state>
</game>
</game>
</presence>
]]></example>
]]></example>
</section2>
</section1>
@ -1688,7 +1688,7 @@
and the room cannot be created,
the service MUST reply with the following error.
</p>
<example caption='Service Informs User of Inability to Create a Room'><![CDATA[
<presence
from='island-chess@games.shakespeare.lit/damsel'
@ -1703,8 +1703,8 @@
]]></example>
<p>
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
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
presence with a bad request error back to the user.
</p>
@ -1733,7 +1733,7 @@
from='island-chess@games.shakespeare.lit/damsel'>
to='miranda@shakespeare.lit/desktop'>
<game xmlns='http://jabber.org/protocol/mug'>
<item affiliation='owner' role='White'/>
<item affiliation='owner' role='White'/>
</game>
</presence>
]]></example>
@ -1804,7 +1804,7 @@
type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'>
<options>
<x xmlns='jabber:x:data' type='form'>
<x xmlns='jabber:x:data' type='form'>
<title>Configuration for "Island Chess" Room</title>
<instructions>
Your room island-chess@games.shakespeare.lit has been created!
@ -1907,7 +1907,7 @@
var='mug#roomconfig_chat'/>
</x>
<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>
<instructions>
The default configuration is as follows:
@ -1949,7 +1949,7 @@
type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'>
<options>
<x xmlns='jabber:x:data' type='submit'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/mug#roomconfig</value>
</field>
@ -1986,7 +1986,7 @@
<field var='mug#roomconfig_chat'/>
</x>
<options xmlns='http://jabber.org/protocol/mug/chess'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/mug/chess#chessconfig</value>
@ -2052,7 +2052,7 @@
</error>
</iq>
]]></example>
<p>Alternatively, the room owner MAY cancel the configuration process:</p>
<example caption='Owner Cancels Initial Configuration'><![CDATA[
@ -2065,7 +2065,7 @@
</query>
</iq>
]]></example>
<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).
</p>
@ -2095,7 +2095,7 @@
type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'>
<options>
<x xmlns='jabber:x:data' type='form'>
<x xmlns='jabber:x:data' type='form'>
<title>Configuration for "Island Chess" Room</title>
<instructions>
To select a different configuration, please complete
@ -2186,7 +2186,7 @@
</field>
</x>
<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>
<instructions>
The default configuration is as follows:
@ -2252,7 +2252,7 @@
</section3>
</section2>
</section2>
<section2 topic='Room Saving' anchor='mug-save'>
<p>
@ -2326,20 +2326,20 @@
<section2 topic='Modifying the Member List' anchor='modifymember'>
<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
a member is effectively banned from entering the match.
</p>
<p>
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
may appear in a match roster, have their match nickname reserved, be
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
may appear in a match roster, have their match nickname reserved, be
returned in search results, and the like.
</p>
<p>
It is RECOMMENDED that only the room owner
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
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
for all users with an affiliation of "member":
</p>
<example caption='Owner Requests Member List'><![CDATA[
@ -2353,18 +2353,18 @@
</iq>
]]></example>
<p>
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
a member in the room requests the member list.
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
if another user should be invited.
A service SHOULD also allow any member to retrieve the member list even
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
a member in the room requests the member list.
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
if another user should be invited.
A service SHOULD also allow any member to retrieve the member list even
if not yet an occupant.
</p>
<p>
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
'role' attributes for each members that is currently an occupant.
</p>
@ -2381,10 +2381,10 @@
</iq>
]]></example>
<p>
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
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
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
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
the 'role' attribute (which is used to manage game roles in a room):
</p>
<example caption='Owner Sends Modified Member List to Service'><![CDATA[
@ -2410,22 +2410,22 @@
type='result'/>
]]></example>
<p>
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
affiliation from "member" to "none".
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
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".
</p>
<p>
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
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
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
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
subsequently refuse entry to the user.
</p>
<p>
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
'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the
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
'http://jabber.org/protocol/mug' namespace and containing an &lt;item/&gt; child with the
'affiliation' attribute set to a value of "none".
</p>
<example caption="Service Sends Notice of Loss of Membership to All Occupants"><![CDATA[
@ -2437,13 +2437,13 @@
</game>
</presence>
...
...
]]></example>
<p>
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
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 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
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 --
both child elements are OPTIONAL):
</p>
<example caption='Room Sends Invitation to New Member'><![CDATA[
@ -2458,12 +2458,12 @@
</message>
]]></example>
<p>
While only the owner SHOULD be allowed to modify the member list,
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
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
to a send an invitation, the service MUST deny the invitation request and return a
While only the owner SHOULD be allowed to modify the member list,
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
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
to a send an invitation, the service MUST deny the invitation request and return a
&forbidden; error to the sender:
</p>
<example caption='Service Returns Error on Attempt by Mere Member to Invite Others to a Members-Only Match'><![CDATA[
@ -2483,14 +2483,14 @@
</message>
]]></example>
<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.
</p>
<p>
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,
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;
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,
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 'affiliation' attribute set to a value of "member".
</p>
<example caption="Service Sends Notice of Membership to All Occupants"><![CDATA[
@ -2509,7 +2509,7 @@
<section2 topic='Revoke and Assign Roles' anchor='modifyroles'>
<p>
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:
</p>
<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.
</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
'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each
occupant in the room.
'role' and 'nick' attributes and MAY include the 'jid' and 'affiliation' attributes for each
occupant in the room.
</p>
<example caption='Service Sends List of Occupants and Assigned Roles to Owner'><![CDATA[
<iq from='island-chess@games.shakespeare.lit'
@ -2553,9 +2553,9 @@
</p>
<p>
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;
each item MUST include the 'roles' attribute
and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include
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
and 'nick' attribute but SHOULD NOT include the 'jid' attribute and MUST NOT include
the 'affiliation' attribute:
</p>
<example caption='Owner Sends Modified List of Assigned Roles to Service'><![CDATA[
@ -2582,9 +2582,9 @@
]]></example>
<p>
The service MUST change the roles of any affected user and
MUST send updated presence to all occupants,
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
MUST send updated presence to all occupants,
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
'role' attribute.
</p>
<example caption="Service Sends Notice of Changed Roles to All Occupants"><![CDATA[
@ -2596,7 +2596,7 @@
</game>
</presence>
...
...
]]></example>
</section2>
@ -2649,7 +2649,7 @@
<p>OPTIONAL.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>The following guidelines may assist client and component developers in creating MUG implementations.</p>
<section2 topic='Services' anchor='impl-services'>
@ -2675,7 +2675,7 @@
<li>
<p>
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.
</p>
</li>
@ -2710,7 +2710,7 @@
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<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.
</p>
<!-- <p>
@ -2729,17 +2729,17 @@
<section2 topic='Service Discovery Category/Type' anchor='registrar-discocat'>
<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.
</p>
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>
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
is the 'http://jabber.org/protocol/mug' namespace. In addition, a MUG match
SHOULD provide information about the specific match features it implements,
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
is the 'http://jabber.org/protocol/mug' namespace. In addition, a MUG match
SHOULD provide information about the specific match features it implements,
such as password protection and match moderation.
</p>
<!-- <p>
@ -2756,7 +2756,7 @@
xmpp:island-chess@games.shakespeare.lit?play
]]></example>
<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.
</p>
<p>
@ -2771,14 +2771,14 @@ xmpp:island-chess@games.shakespeare.lit?play
</presence>
]]></example>
<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.
</p>
<example caption="Play Action with Game: IRI/URI"><![CDATA[
xmpp:island-chess@games.shakespeare.lit?play;game=http://jabber.org/protocol/mug/chess
]]></example>
<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.
</p>
<example caption="Play Action: IRI/URI"><![CDATA[

2
inbox/peptzo.xml
View File

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

4
inbox/pubsub-since.xml
View File

@ -90,7 +90,7 @@
</section1>
<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 topic='Implementation Notes' anchor='impl'>
@ -105,7 +105,7 @@
<var>
<name>http://jabber.org/protocol/pubsub#since</name>
<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.
</desc>
<doc>XEP-xxxx</doc>

78
inbox/qos.xml
View File

@ -4,9 +4,9 @@
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<!--
<!--
© XMPP Standards Foundation, 2015
Author: Peter Waher
Author: Peter Waher
-->
<xep>
<header>
@ -89,7 +89,7 @@ Author: Peter Waher
</p>
<p>
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.
</p>
</dd>
@ -109,13 +109,13 @@ Author: Peter Waher
</p>
<example caption='Sensor sending a momentary value'>
<![CDATA[
<message
<message
from='temperaturesensor@example.org/34892374'
to='user@example.org/938089023'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>
<node nodeId='Temp01'>
<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>
</node>
</fields>
@ -124,16 +124,16 @@ Author: Peter Waher
</section2>
<section2 topic='Acknowledged service - At least once' anchor='ack'>
<p>
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.
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.
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
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.
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.
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.
</p>
<p>
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 most once QoS level.
</p>
@ -144,7 +144,7 @@ Author: Peter Waher
</p>
<example caption='Setting light level'>
<![CDATA[
<iq id='123' type='set'
<iq id='123' type='set'
from='controller@example.org/34892374'
to='lightswitch@example.org/938089023'>
<qos:acknowledged xmlns:qos='urn:xmpp:qos'>
@ -155,7 +155,7 @@ Author: Peter Waher
</message>
</qos:acknowledged>
</iq>
<iq id='123' type='result'
from='lightswitch@example.org/938089023'
to='controller@example.org/34892374'/>
@ -177,14 +177,14 @@ Author: Peter Waher
memory. Still, the received response is returned as normal.
</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
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
assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used.
</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.
</p>
<p>
@ -194,7 +194,7 @@ Author: Peter Waher
</p>
<example caption='Counting cars or individuals in a closed space'>
<![CDATA[
<iq id='123' type='set'
<iq id='123' type='set'
from='entrance@example.org/34892374'
to='counter@example.org/938089023'>
<qos:assured xmlns:qos='urn:xmpp:qos' msgId='984232334'>
@ -205,27 +205,27 @@ Author: Peter Waher
</message>
</qos:assured>
</iq>
<iq id='123' type='result'
from='counter@example.org/938089023'>
to='entrance@example.org/34892374'>
<received msgId='984232334'/>
</iq>
<iq id='124' type='set'
<iq id='124' type='set'
from='entrance@example.org/34892374'
to='counter@example.org/938089023'>
<qos:deliver xmlns:qos='urn:xmpp:qos' msgId='984232334'/>
</iq>
<iq id='124' type='result'
from='counter@example.org/938089023'>
to='entrance@example.org/34892374'/>
</iq>
...
<iq id='456' type='set'
<iq id='456' type='set'
from='exit@example.org/34892374'
to='counter@example.org/938089023'>
<qos:assured xmlns:qos='urn:xmpp:qos' msgId='4645623466'>
@ -236,19 +236,19 @@ Author: Peter Waher
</message>
</qos:assured>
</iq>
<iq id='456' type='result'
from='counter@example.org/938089023'>
to='exit@example.org/34892374'>
<received msgId='4645623466'/>
</iq>
<iq id='457' type='set'
<iq id='457' type='set'
from='exit@example.org/34892374'
to='counter@example.org/938089023'>
<qos:deliver xmlns:qos='urn:xmpp:qos' msgId='4645623466'/>
</iq>
<iq id='457' type='result'
from='counter@example.org/938089023'>
to='exit@example.org/34892374'/>
@ -296,12 +296,12 @@ Author: Peter Waher
<section2 topic='Offline messages' anchor='offline'>
<p>
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>
</section2>
<section2 topic='Resource part' anchor='resource'>
<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.
For consistency, full JIDs should be used also for unacknowledged messaging service, if possible.
</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
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
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.)
</p>
</section2>
<section2 topic='Message IDs' anchor='msdId'>
<p>
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.
</p>
</section2>
@ -363,7 +363,7 @@ Author: Peter Waher
<li>
<p>
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.
</p>
</li>
@ -392,20 +392,20 @@ Author: Peter Waher
xmlns='urn:xmpp:qos'
xmlns:jbc='jabber:client'
elementFormDefault='qualified'>
<xs:import namespace='jabber:client'/>
<xs:element name='acknowledged' type='EmbeddedMessage'/>
<xs:element name='assured' type='Assured'/>
<xs:element name='received' type='WithMessageId'/>
<xs:element name='deliver' type='WithMessageId'/>
<xs:complexType name='EmbeddedMessage'>
<xs:sequence minOccurs='1' maxOccurs='1'>
<xs:element ref='jbc:message'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name='Assured'>
<xs:complexContent>
<xs:extension base='EmbeddedMessage'>
@ -413,13 +413,13 @@ Author: Peter Waher
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:attribute name='msgId' type='xs:string'/>
<xs:complexType name='WithMessageId'>
<xs:attribute ref='msgId' use='required'/>
</xs:complexType>
</xs:schema>
]]>
</code>

4
inbox/reputation.xml
View File

@ -188,7 +188,7 @@
to='juliet@capulet.lit/chamber'
id='bn4c297j'
type='result'>
<score xmlns='urn:xmpp:reputation:0'
<score xmlns='urn:xmpp:reputation:0'
jid='romeo@montague.lit'
num='65'/>
</iq>
@ -206,7 +206,7 @@
</section1>
<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 topic='XMPP Registrar Considerations' anchor='registrar'>

372
inbox/rest.xml
View File

@ -8,8 +8,8 @@
<header>
<title>REST with XMPP</title>
<abstract>This specification defines how the Representational State Transfer (REST)
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
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
requests and responses between two XMPP entities.</abstract>
<legal>
<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'>
<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
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)
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:
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>
<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
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
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>
<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.
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>
<ol>
<li>services are discoverable and explorable,</li>
@ -84,127 +84,127 @@
</ul>
</section1>
<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
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)
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
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>
<!-- computeExplorationRequestIQ.xml -->
<example caption='Exploration of an OpenStack interface for handling compute services'><![CDATA[
<iq type='get'
from='requester@company-b.com/rest-client'
to='company-a.com/openstack'
<iq type='get'
from='requester@company-b.com/rest-client'
to='company-a.com/openstack'
id='rest1'>
<resource_type xmlns="urn:xmpp:rest-xwadl" path="/compute" />
</iq>
]]></example>
<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
actions for this resource.</p>
<!-- computeExplorationResponseIQ.xml -->
<example caption='Result of an exploration for handling compute services'><![CDATA[
<iq type="result"
from="company-a.com/openstack"
from="company-a.com/openstack"
to="requester@company-b.com/rest-client"
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">
Use one of the following actions to manage your compute instances!
</doc>
<method name="create">
<request>
<param name="image" required="true" repeating="false">
<option link="remote"/>
</param>
<param name="flavors" repeating="false" default="m1.small">
<option type="xs:string">m1.small</option>
<option type="xs:string">m2.medium</option>
<option type="xs:string">m3.large</option>
</param>
<param name="number" repeating="false" default="1">
<doc title="number of requested virtual machnies"/>
<option type="xs:integer"/>
</param>
</request>
<response>
<param name="newVM">
<option link="list"/>
</param>
</response>
</method>
<method name="sla">
<response>
<param name="computeSla">
<option mediaType="text/plain"/>
<option mediaType="application/json"/>
</param>
</response>
</method>
</doc>
<method name="create">
<request>
<param name="image" required="true" repeating="false">
<option link="remote"/>
</param>
<param name="flavors" repeating="false" default="m1.small">
<option type="xs:string">m1.small</option>
<option type="xs:string">m2.medium</option>
<option type="xs:string">m3.large</option>
</param>
<param name="number" repeating="false" default="1">
<doc title="number of requested virtual machnies"/>
<option type="xs:integer"/>
</param>
</request>
<response>
<param name="newVM">
<option link="list"/>
</param>
</response>
</method>
<method name="sla">
<response>
<param name="computeSla">
<option mediaType="text/plain"/>
<option mediaType="application/json"/>
</param>
</response>
</method>
</resource_type>
</iq>
]]></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
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
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
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
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>
<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>
</section2>
<section2 topic='Documentation' anchor='restdis-documentation'>
<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
text description of the element being documented. The "doc" element can have mixed content
<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
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>
</section2>
<section2 topic='Grammars' anchor='restdis-grammars'>
<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
<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
XML Schema definition.</p>
<!-- grammarsExampleResponseIQ.xml -->
<example caption='Example xwadl document with a grammars element'><![CDATA[
<iq type="result"
from="responder@company-a.com"
<iq type="result"
from="responder@company-a.com"
to="requester@company-b.com/rest-client"
id="rest1">
<resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/address-book">
<grammars>
<doc title="Person List"/>
<xs:element name="PersonList" type="MyStructType"/>
<xs:complexType name="MyStructType">
<xs:sequence>
<xs:element name="Person" type="MyPersonType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MyPersonType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</grammars>
<method name="POST">
<request>
<param name="persons" required="true" repeating="false">
<option type="MyStructType"/>
</param>
</request>
<response/>
</method>
<resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/address-book">
<grammars>
<doc title="Person List"/>
<xs:element name="PersonList" type="MyStructType"/>
<xs:complexType name="MyStructType">
<xs:sequence>
<xs:element name="Person" type="MyPersonType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MyPersonType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</grammars>
<method name="POST">
<request>
<param name="persons" required="true" repeating="false">
<option type="MyStructType"/>
</param>
</request>
<response/>
</method>
</resource_type>
</iq>
]]></example>
</section2>
<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.
A method element is a child of a "resource_type" element and has a "name" attribute
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>
</section2>
<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>
<ul>
<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>
</section2>
<section2 topic='Parameter' anchor='restdis-parameter'>
<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
that defines one of a set of possible
values for the parameter. In order to parameterize a component, the "param" element SHOULD specify
<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
that defines one of a set of possible
values for the parameter. In order to parameterize a component, the "param" element SHOULD specify
a combination of the following attributes:</p>
<ul>
<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
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>
<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>
<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>
</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>
</section2>
<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>
<dl>
<di>
<dt>type</dt>
<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
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>
</dd>
</di>
<di>
<dt>mediaType</dt>
<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
a representation of an OPTIONAL media type is exposed, this representation can act as a
template for manipulating a resource.</p>
@ -266,7 +266,7 @@
<dt>link</dt>
<dd>
<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
list value indicates a list of remote links that can be used for discovery or linking to a set
of resources.</p>
@ -276,13 +276,13 @@
</section2>
</section1>
<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
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.
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.
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.
Here, the client requests three VMs which are based on an image that is available as resource
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
on the client's side.</p>
<!-- computeCreateRequestIQ.xml -->
<example caption='Access of an OpenStack interface to create a virtual machnine'><![CDATA[
@ -290,25 +290,25 @@
from="requester@company-b.com/rest-client"
to="company-a.com/openstack"
id="rest2">
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create">
<request>
<param name="image">
<link>
<to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path>
</link>
</param>
<param name="number">
<value type="xs:integer">3</value>
</param>
</request>
<response>
<param name="newVM">
<resourceList/>
</param>
</response>
</method>
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create">
<request>
<param name="image">
<link>
<to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path>
</link>
</param>
<param name="number">
<value type="xs:integer">3</value>
</param>
</request>
<response>
<param name="newVM">
<resourceList/>
</param>
</response>
</method>
</resource>
</iq>
]]></example>
@ -319,50 +319,50 @@
</p>
<!-- computeCreateRequestIQ.xml -->
<example caption='Result of an access to create a virtual machnine'><![CDATA[
<iq type="result"
<iq type="result"
from="company-a.com/openstack"
to="requester@company-b.com/rest-client"
id="rest2">
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create">
<request>
<param name="image">
<link>
<to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path>
</link>
</param>
<param name="number">
<value type="xs:integer">3</value>
</param>
</request>
<response>
<param name="newVM">
<resourceList>
<link>
<to>dc1.company-a.com/openstack</to>
<path>requester/vms/vm1</path>
</link>
<link>
<to>dc2.company-a.com/openstack</to>
<path>requester/vms/vm02</path>
</link>
<link>
<to>dc3.company-a.com/openstack</to>
<path>requester/vms/vm003</path>
</link>
</resourceList>
</param>
</response>
</method>
<resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
<method name="create">
<request>
<param name="image">
<link>
<to>requester@company-b.com/rest-client</to>
<path>/images/myLinuxImage</path>
</link>
</param>
<param name="number">
<value type="xs:integer">3</value>
</param>
</request>
<response>
<param name="newVM">
<resourceList>
<link>
<to>dc1.company-a.com/openstack</to>
<path>requester/vms/vm1</path>
</link>
<link>
<to>dc2.company-a.com/openstack</to>
<path>requester/vms/vm02</path>
</link>
<link>
<to>dc3.company-a.com/openstack</to>
<path>requester/vms/vm003</path>
</link>
</resourceList>
</param>
</response>
</method>
</resource>
</iq>
]]></example>
<p>The following subsections describe each component of a xml-rest document in detail.</p>
<section2 topic='Resource' anchor='restaccess-resource'>
<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
are possible in order to keep the number of bytes as low as possible.
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.
In order to specify the resource to access, the "path" attribute is required.</p>
</section2>
<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>
</section2>
<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.
Both elements have no attributes and may contain one or more "param" elements as child elements.</p>
<ul>
@ -390,9 +390,9 @@
</section2>
<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
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"
(e.g. &lt;to&gt;requester@company-b.com/rest-client&lt;/to&gt;) and a "path" (e.g.
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"
(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
or as URI (&lt;uri&gt;xmpp://requester@company-b.com/rest-client?/images/myLinuxImage&lt;/uri&gt;).</p>
</section2>
@ -402,12 +402,12 @@
<p>Example to access the sla method.</p>
</section2 -->
<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>
<example caption='A request to a server'><![CDATA[
<iq type='set'
from='requester@company-b.com/rest-client'
to='company-a.com'
<iq type='set'
from='requester@company-b.com/rest-client'
to='company-a.com'
id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/">
...
@ -415,9 +415,9 @@
</iq>
]]></example>
<example caption='A request to a server with a JID contained a resource part'><![CDATA[
<iq type='set'
from='requester@company-b.com/rest-client'
to='company-a.com/resource'
<iq type='set'
from='requester@company-b.com/rest-client'
to='company-a.com/resource'
id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/">
...
@ -425,9 +425,9 @@
</iq>
]]></example>
<example caption='A request to a server with a JID contained a local part'><![CDATA[
<iq type='set'
from='requester@company-b.com/rest-client'
to='responder@company-a.com'
<iq type='set'
from='requester@company-b.com/rest-client'
to='responder@company-a.com'
id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/">
...
@ -435,9 +435,9 @@
</iq>
]]></example>
<example caption='A request to a server with a JID contained a local and a resource part'><![CDATA[
<iq type='set'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource'
<iq type='set'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource'
id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/">
...
@ -445,34 +445,34 @@
</iq>
]]></example>
<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'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource'
<iq type='set'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/resource'
id='rest1'>
<resource xmlns="urn:xmpp:xml-rest" path="/resource/">
...
</resource>
</iq>
]]></example>
<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.
<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.
Further examples are possible to show how different resources can be located at a single server entity.</p>
</section2>
</section1>
<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>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/rest-server'
<iq type='get'
from='requester@company-b.com/rest-client'
to='responder@company-a.com/rest-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
to='requester@company-b.com/rest-client'
from='responder@company-a.com/rest-server'
<iq type='result'
to='requester@company-b.com/rest-client'
from='responder@company-a.com/rest-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='rest'/>
@ -482,9 +482,9 @@
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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
considered specifically to the application and/or implementation of this document,
<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
considered specifically to the application and/or implementation of this document,
future specifications may address these concerns.</p>
</section1>
<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'>
<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>
<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>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>
@ -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'>
Adapter publishes device meta data:
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
id='publish1'>
@ -556,7 +556,7 @@ The tuple (UUID X, transducer id Y) MUST be unique such that a publish operation
</tr>
<tr>
<td>
multimedia input
multimedia input
</td>
<td>
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>
</section3>
<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>.
</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[
<device id='01020301' type='other'>
<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>
]]></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[
<device id='xyzzy' type='scale'>
<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'>
Values for a transducer are published via the data value node:
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
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.
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
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'>
Values for a transducer can also be set by publishing to the data value node.
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='house-capulet@capulet.lit/castle'
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>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='juliet@capulet.lit/balcony'
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.
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.
</p>
</p>
</section3>
</section2>
</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.
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
id='publish10'>
@ -979,7 +979,7 @@ The sensor used is accurate to the nearest 10 Wh.
</pubsub>
</iq>
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
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.
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
id='publish20'>
@ -1029,7 +1029,7 @@ The adapter provides this additional information in the meta node and data value
</pubsub>
</iq>
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='heater-capulet@capulet.lit/castle'
id='publish21'>
@ -1064,7 +1064,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat'
id='publish40'>
@ -1092,7 +1092,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
</pubsub>
</iq>
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat'
id='publish41'>
@ -1110,7 +1110,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
</pubsub>
</iq>
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat'
id='publish42'>
@ -1134,7 +1134,7 @@ the adapter implements the OPTIONAL ability that allows a transducer value to ha
<code><![CDATA[
Event Node ID: 4d4335b5-4134-11e0-9207-0800200c9a66_data
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat'
id='publish43'>
@ -1166,7 +1166,7 @@ One action could be to turn on the light, in which case the agent would publish:
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='watcher-montague@montague.lit/agent99'
id='publish44'>
@ -1189,7 +1189,7 @@ In response, the camera adapter would turn on the light and publish an acknowled
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.montague.lit'
from='camera-montague@montague.lit/moat'
id='publish45'>
@ -1228,7 +1228,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
</p>
<code><![CDATA[
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='chariot-capulet@capulet.lit/convertible'
id='publish50'>
@ -1267,7 +1267,7 @@ Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the
</pubsub>
</iq>
<iq type='set'
<iq type='set'
to='pubsub.capulet.lit'
from='chariot-capulet@capulet.lit/convertible'
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='accuracy' type='xs:float' use='optional'/>
</xs:complexType>
</xs:element>
</xs:element>
<xs:simpleType name='allowedUnits'>
<xs:restriction base="xs:string">

2
inbox/server-rosters.xml
View File

@ -84,7 +84,7 @@
</section1>
<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>
</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 "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>Enable future extensibility based on regular expressions, XPath expressions, etc.</li>
<li>Enable future extensibility based on regular expressions, XPath expressions, etc.</li>
</ol>
</section1>
@ -212,7 +212,7 @@
<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>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
<iq type='get'
from='romeo@montague.lit/pda'
to='montague.lit'
id='bf4vb167'>
@ -220,7 +220,7 @@
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
<iq type='result'
from='montague.lit'
to='romeo@montague.lit/pda'
id='bf4vb167'>
@ -342,7 +342,7 @@
</section2>
<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>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 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>
@ -408,7 +408,7 @@
</section1>
<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 topic='XMPP Registrar Considerations' anchor='reg'>
@ -456,17 +456,17 @@
<xs:element name='sift'>
<xs:complexType>
<xs:sequence>
<xs:element name='iq'
<xs:element name='iq'
type='siftElementType'
minOccurs='0'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='message'
<xs:element name='message'
type='siftElementType'
minOccurs='0'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='presence'
<xs:element name='presence'
type='siftElementType'
minOccurs='0'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
@ -475,20 +475,20 @@
<xs:element name='featureElementType'>
<xs:complexType>
<xs:sequence>
<xs:element name='recipient'
type='recipientElementType'
<xs:element name='recipient'
type='recipientElementType'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='sender'
type='senderElementType'
<xs:element name='sender'
type='senderElementType'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='allow'
type='allowElementType'
<xs:element name='allow'
type='allowElementType'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
@ -497,12 +497,12 @@
<xs:element name='siftElementType'>
<xs:complexType>
<xs:sequence>
<xs:element name='allow'
type='allowElementType'
<xs:element name='allow'
type='allowElementType'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='recipient'
@ -535,16 +535,16 @@
<xs:element name='recipientElementType'>
<xs:complexType>
<xs:sequence>
<xs:element name='all'
type='empty'
<xs:element name='all'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='bare'
type='empty'
<xs:element name='bare'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='full'
type='empty'
<xs:element name='full'
type='empty'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
@ -554,24 +554,24 @@
<xs:element name='senderElementType'>
<xs:complexType>
<xs:sequence>
<xs:element name='all'
type='empty'
<xs:element name='all'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='local'
type='empty'
<xs:element name='local'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='others'
type='empty'
<xs:element name='others'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='remote'
type='empty'
<xs:element name='remote'
type='empty'
minOccurs='0'
maxOccurs='1'/>
<xs:element name='self'
type='empty'
<xs:element name='self'
type='empty'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>

6
inbox/sox.xml
View File

@ -147,7 +147,7 @@ a=sendrecv
<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>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
<iq type='get'
from='romeo@example.net/orchard'
to='juliet@example.com/chamber'
id='hx62f49'>
@ -155,7 +155,7 @@ a=sendrecv
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
<iq type='result'
from='juliet@example.com/chamber'
to='romeo@example.net/orchard'
id='hx62f49'>
@ -172,7 +172,7 @@ a=sendrecv
</section1>
<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 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'>
<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[
<iq from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
<iq from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
id='disco1'>
type='get'>
<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>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[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0' id='e' session='851ba2'>
@ -309,7 +309,7 @@
</ol>
<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[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<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>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[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0'
@ -340,7 +340,7 @@
<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>
<example caption='Refusing a state offer'><![CDATA[
<message
<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'>
<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 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[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0'
@ -381,14 +381,14 @@
]]></example>
<p>If the session is already in progress, the entity sends the snapshot.</p>
<example caption='Sending the state of an existing document'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0'
session='851ba2'
id='bxyz'>
<state>
<document-begin
<document-begin
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\
p%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-strict.dtd%223\
@ -452,7 +452,7 @@
<section1 topic='Subsequent State Changes'>
<p>Once a participant has received initial state, he can participate in the editing session.</p>
<example caption='An edit'><![CDATA[
<message
<message
to='laertes@shakespeare.lit/castle'
from='kingclaudius@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0'
@ -476,7 +476,7 @@
]]></example>
<p>Here is another edit in the session.</p>
<example caption='Another edit'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<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'>
<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>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'>
<tr>
<td></td>
@ -782,7 +782,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
</ol>
</section3>
</section2>
<section2 topic='Commutative Edits' anchor='commutativeedits'>
<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>
@ -843,7 +843,7 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
</table>
<example caption='Sending new nodes'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<sxe xmlns='urn:xmpp:sxe:0'
@ -859,13 +859,13 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
rid='GUID5'
chdata='M10 10L30 50L50 10Z' />
</sxe>
</message>
</message>
]]></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>
</section3>
<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>
<table caption="Attributes of the &lt;remove/&gt; element">
<tr>
<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>
</tr>
</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>
<example caption='Removing an existing nodes.'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<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'>
<section3 topic='The set Element'>
<p>The &lt;set/&gt; element is used to modify an existing record.</p>
<table caption="Attributes of the &lt;set/&gt; element">
<tr>
<th>Attribute</th>
@ -948,12 +948,12 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<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>
</tr>
</table>
<example caption='set elements.'><![CDATA[
<message
<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'>
<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>
<example caption='Inclusion of a thumbnail in SI file transfer offer'><![CDATA[
<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'
mime-type='image/jpeg'
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>
]]>
</example>
<section2 topic='Definition of the thumbnail Element'
<section2 topic='Definition of the thumbnail Element'
anchor='thumbnail_element'>
<p>The following attributes are defined for the &lt;thumbnail/&gt; element.</p>
<table caption='Attributes of the thumbnail Element'>

34
inbox/tictactoe-mug.xml
View File

@ -50,8 +50,8 @@
<section1 topic='Introduction' anchor='intro'>
<p>
It is quite common to play games over IM networks.
Since Tic-tac-toe is a well-known and simple game,
It is quite common to play games over IM networks.
Since Tic-tac-toe is a well-known and simple game,
it's a good example for a server-based game protocol.
</p>
</section1>
@ -59,7 +59,7 @@
<section1 topic='Requirements' anchor='reqs'>
<p>
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>
<ol start='1'>
<li>game roles</li>
@ -95,7 +95,7 @@
<section1 topic='Game Roles' anchor='roles'>
<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.
If one role gets unassigned or a player gets unavailable the match has to be paused.
</p>
@ -112,8 +112,8 @@
</ol>
<p>
An implementation MUST be able to handle the a board with three cols and rows
and three respective marks to win.
Everything beyond that is OPTIONAL.
and three respective marks to win.
Everything beyond that is OPTIONAL.
</p>
<example caption='Service Sends Configuration Form'><![CDATA[
<iq from='tictactoe@games.shakespeare.lit'
@ -122,16 +122,16 @@
type='result'>
<query xmlns='http://jabber.org/protocol/mug#owner'>
<options>
<x xmlns='jabber:x:data' type='form'>
<x xmlns='jabber:x:data' type='form'>
<title>Tic-tac-toe Room</title>
...
</x>
<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>
<instructions>
Below you can see the default configuration.
To accept the default configuration, click OK.
Below you can see the default configuration.
To accept the default configuration, click OK.
To select a different configuration, please complete this form.
</instructions>
<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.
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
and the initial state of the next round.
and the initial state of the next round.
</p>
<example caption='Service Sends Draw State'><![CDATA[
<presence
@ -261,7 +261,7 @@
<section1 topic='Turns' anchor='turn'>
<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:
<table caption='&MOVE; attributes'>
<tr>
@ -287,15 +287,15 @@
</table>
</p>
<example caption='Juliet Sends a Move'><![CDATA[
<message
<message
to='tictactoe@games.shakespeare.lit'
from='juliet@capulet.com/garden'
type='chat'>
<turn xmlns='http://jabber.org/protocol/mug#user'>
<move
xmlns='http://jabber.org/protocol/mug/tictactoe'
row='3'
col='2'
<move
xmlns='http://jabber.org/protocol/mug/tictactoe'
row='3'
col='2'
id='7'/>
</turn>
</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.
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.
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
qualified by 'http://jabber.org/protocol/games/tictactoe'.
It MUST possess these attributes:

314
inbox/user-auth.xml
View File

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

12
inbox/xtls.xml
View File

@ -230,7 +230,7 @@
<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>
<example caption='A Stanza to Send'><![CDATA[
<message
<message
from='romeo@montague.lit/orchard'
to='juliet@capulet.lit//chamber'
type='chat'>
@ -270,7 +270,7 @@
<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>
<example caption='One Party Closes the XTLS Tunnel'><![CDATA[
<iq type='set'
<iq type='set'
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
id='xtls_10'>
@ -279,7 +279,7 @@
]]></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>
<example caption='Other Party Acknowledges Closing of the Tunnel'><![CDATA[
<iq type='result'
<iq type='result'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='xtls_10'>
@ -288,7 +288,7 @@
]]></example>
<p>If the tunnel is unknown to the receiving party, it MUST return an &notfound; error.</p>
<example caption='Unknown Tunnel'><![CDATA[
<iq type='error'
<iq type='error'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='xtls_10'>
@ -332,7 +332,7 @@
<section1 topic='Security Considerations' anchor='security'>
<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'>
<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 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>
@ -344,7 +344,7 @@
</section2>
</section1>
<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 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>

4
xep-0313.xml
View File

@ -152,7 +152,7 @@
</section1>
<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>
<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>
@ -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
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
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.

48
xep-0369.xml
View File

@ -45,7 +45,7 @@
Remove namespace references in Info/Config nodes;
Modify Participant and JID Map syntaxes;
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>
</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.
</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>
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>
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.
</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>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[
@ -521,14 +521,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</items>
]]></example>
</section3>
<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>
</section3>
<section3 topic="Presence Node" anchor="presence-node">
<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.
@ -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>'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>'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>'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'>
<nick>top witch</nick>
</participant>
</item>
</item>
</items>
</pubsub>
<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">
<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.
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>
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>
The user's server MUST remove this roster entry when the user leaves the channel.
</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.
</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">
<p>A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
</p>
<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>'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>
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>The following example shows an example of reporting successful Nick assignment.</p>
<example caption="Service Returns User of Nick"><![CDATA[
<iq type='result'
@ -1505,13 +1505,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<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>
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>
<example caption='Client looks up Real JID from Proxy JID'><![CDATA[
<iq from='hag66@shakespeare.example/UUID-c8y/1573'
id='kl2fax27'
@ -1540,9 +1540,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<items>
</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>
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>
@ -1561,7 +1561,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<field var='id'>
<value>123456#coven@mix.shakespeare.example</value>
</field>
</x>
</x>
</query>
</iq>
@ -1589,8 +1589,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='kl2fax27'
type='result'>
</iq>]]> </example>
</section3>
@ -1646,8 +1646,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></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
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[
<message from='coven@mix.shakespeare.example'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'