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

XEP-0204–XEP-0298: DTD fixes

hacx
Sam Whited 2017-01-01 20:51:42 -06:00
parent caacf89081
commit 8de3ee3a29
29 changed files with 404 additions and 401 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
xep-0204.xml
View File

@ -571,10 +571,10 @@ A CDO client can query the server to determine the specific state of a particula
</query>
</iq>
]]></example>
Note an event type of info. This requires all attributes for the data-sync element and items be present
<p>Note an event type of info. This requires all attributes for the data-sync element and items be present</p>
</section2>
<section2 topic="Query an endpoint for a list of CDOs" anchor="cdolist">
In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.
<p>In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.</p>
<example caption="Client A constructs an IQ get and sends it to Server X wishing to obtain the current state of all CDOs belonging to the CDO users chatroom"><![CDATA[
<iq type='get' from='joe@mitre.org/Desktop' to='cdo_users@mitre.org' id='cdo_state_2>
<query xmlns='http://www.xmpp.org/extensions/xep-0204.html#ns-state'>
@ -595,18 +595,17 @@ In some cases a client may be interested in the state of all CDOs belonging to a
type="cdo:Location"
event="info"
xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns"/>
...
...
</query>
</iq>
]]></example>
Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs
<p>Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs</p>
<p>
If desired, Client A can then query the Server for the details on the state of a specific CDO using the protocol described earlier.
</p>
</section2>
<section2 topic="Create a new CDO" anchor="cdocreate">
When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:
<p>When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:</p>
<example caption="Client A creates a new CDO and sends it to client B"><![CDATA[
<message
to='joe@mitre.org/Desktop'
@ -625,7 +624,7 @@ When two endpoints (client A and client B) wish to create a new CDO. Each client
</data-sync>
</message>
]]></example>
Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero
<p>Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero</p>
<p>
Next, the message is intercepted by Server X. Server X is the IM server that both clients are connected to. When the server receives
the message, it MUST increment the version number and assign a uuid for both the &lt;data-sync&gt; and &lt;item&gt;. Once processed
@ -675,10 +674,10 @@ Server X MUST send a copy of the message back to client A as a receipt that the
</data-sync>
</message>
]]></example>
Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.
<p>Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.</p>
</section2>
<section2 topic="Create a new Item on an existing CDO" anchor="cdoitemcreate">
When client A wishes to create a new Item on an existing CDO, he sends the following information to client B
<p>When client A wishes to create a new Item on an existing CDO, he sends the following information to client B</p>
<example caption="Client A creates a new item on an existing CDO and sends it to client B"><![CDATA[
<message
to='joe@mitre.org/Desktop'
@ -741,10 +740,10 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
</data-sync>
</message>
]]></example>
Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.
<p>Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.</p>
</section2>
<section2 topic="Update an Item on an existing CDO" anchor="cdoitemupdate">
When client A wishes to update an item on an existing CDO, he sends the following information to client B
<p>When client A wishes to update an item on an existing CDO, he sends the following information to client B</p>
<example caption="Client A updates an item on an existing CDO and sends it to client B"><![CDATA[
<message
to='joe@mitre.org/Desktop'
@ -819,7 +818,7 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
</data-sync>
</message>
]]></example>
Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.
<p>Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.</p>
<section3 topic="Update Styles">
<p>
There are two types of behaviors associated with an item update: inclusive and exclusive. For an inclusive update, the content of the item element
@ -832,35 +831,35 @@ Once this is completed, both clients have a synchronized CDO message with an upd
Assume that client A has created a CDO cdo_1. This CDO has an item item_1 with the attribute named attr_1 set. If A wants to update item_1 with a value
for the attribute named attr_2 without destroying the previously set value for attr_1, the following data synchronization packets are equivalent:
</p>
<pre><![CDATA[
<data-sync protocol="1.0" uuid="cdo_1" packetID="0003"
<code><![CDATA[
<data-sync protocol="1.0" uuid="cdo_1" packetID="0003"
event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
<item type="field"
uuid="item_1"
event="update"
version="1"
<item type="field"
uuid="item_1"
event="update"
version="1"
updateStyle="inclusive">
<attribute name="attr_1">old value</attribute>
<attribute name="attr_2">new value</attribute>
</item>
</data-sync>
]]></pre>
<pre><![CDATA[
<data-sync protocol="1.0" uuid="cdo_1" packetID="0003"
]]></code>
<code><![CDATA[
<data-sync protocol="1.0" uuid="cdo_1" packetID="0003"
event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
<item type="field"
uuid="item_1"
event="update"
version="1"
<item type="field"
uuid="item_1"
event="update"
version="1"
updateStyle="exclusive">
<attribute name="attr_2">new value</attribute>
</item>
</item>
</data-sync>
]]></pre>
]]></code>
</section3>
</section2>
<section2 topic="Delete an Item on an existing CDO" anchor="cdoitemdelete">
When client A wishes to delete an item on an existing CDO, he sends the following information to client B
<p>When client A wishes to delete an item on an existing CDO, he sends the following information to client B</p>
<example caption="Client A deletes an item on an existing CDO and sends it to client B"><![CDATA[
<message
to='joe@mitre.org/Desktop'
@ -929,7 +928,7 @@ back to client A as a receipt that the message has been processed by Server X an
</data-sync>
</message>
]]></example>
Once this is completed, both clients have a synchronized CDO message with a deleted item.
<p>Once this is completed, both clients have a synchronized CDO message with a deleted item.</p>
</section2>
<section2 topic="Retire an existing CDO" anchor="cdoretire">
<p>
@ -990,7 +989,7 @@ message back to client A as a receipt that the message has been processed by Ser
</data-sync>
</message>
]]></example>
Once this is completed, both clients have retired (deleted) the CDO.
<p>Once this is completed, both clients have retired (deleted) the CDO.</p>
</section2>
</section1>
<section1 topic="Errors" anchor="errors">
@ -1590,12 +1589,12 @@ containing at least one overlapping item. When this occurs, the first packet to
reported back to the client of the second packet MAY be extended to describe the notional conflict. This additional error information is meant to facilitate
collaboration between the clients.
</p>
The additional error information provide includes:
<p>The additional error information provide includes:</p>
<ul>
<li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
<li>The timestamp of when the originating data sync packet was executed.</li>
<li>The item element of the originating data sync packet with which this error conflicts.</li>
</ul>
<li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
<li>The timestamp of when the originating data sync packet was executed.</li>
<li>The item element of the originating data sync packet with which this error conflicts.</li>
</ul>
<example caption=""><![CDATA[
<cdo:item-version-outdated identifier='I' version='V'>
<cdo:conflict resource-identifier='R' execution-timestamp='T'>

9
xep-0209.xml
View File

@ -54,11 +54,11 @@
</ul>
</section1>
<section1 topic='Overview' anchor='overview'>
The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.
<p>The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.</p>
<example caption='A metacontact tag'><![CDATA[
<meta jid='romeo@montague.net' tag='d93nov' order='0'>
]]></example>
In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP).
<p>In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP).</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>Below are example of setting and retrieving metacontacts for an account. When using metacontacts across multiple accounts, the steps are identical and the 'tag' attributes and used across accounts (that is: when the same tag is used for multiple contacts, all entries with the tag are merged into a single metacontact whether they reside on the same of different accounts).</p>
@ -114,7 +114,6 @@
<!--As metacontacts are especially useful when used across multiple accounts, examples are also provided for actions across two accounts.
<section2 topic='Retrieving metacontact data (account 1)' anchor='dualaccount-get1'>
<example caption=''><![CDATA[
]]></example>
</section2>-->
</section1>
@ -122,10 +121,10 @@
<section1 topic='Implementation Notes' anchor='impl'>
<!--<p>Optional.</p>-->
<section2 topic='Creating a metacontact' anchor='creating'>
Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.
<p>Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.</p>
</section2>
<section2 topic='Removing a metacontact' anchor='removing'>
Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.
<p>Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.</p>
</section2>
<section2 topic='Uniqueness of order within a metacontact' anchor='uniqueness'>
<p>Although it is unavoidable that multiple contacts within a metacontact MAY have the same order (due to potentially unavailable information from other accounts), clients SHOULD NOT apply the same order to multiple members of the same metacontact where it is possible to avoid it. If multiple members of a metacontact have the same order, the behaviour is dependent upon the client; it MAY apply rules itself to determine which member to communicate with (based upon presence, recent activity or other methods) it MAY present the user with the option to sort the members such that the orders are again unique, or it MAY employ another appropriate action.</p>

75
xep-0214.xml
View File

@ -12,7 +12,7 @@
<number>0214</number>
<status>Deferred</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
@ -98,16 +98,11 @@
</table>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>The following use cases describe tasks which are already covered by &xep0060; in a more generic context. These tasks are again being provided here in order to demonstrate the functionality provided by this protocol and convey the structure and syntax of the file listing. As a result of this close relationship, many details of PubSub are omitted here for brevity. Consult &xep0060; and &xep0248; for the full specification of node and user management commands as well as their server responses.</p>
<section2 topic='File Listing' anchor='list'>
<section3 topic='Publication' anchor='list-publication'>
<p>Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:</p>
<example caption='Creating a New File Listing'><code><![CDATA[<iq type='set'
<example caption='Creating a New File Listing'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create3'>
@ -140,11 +135,9 @@
</configure>
</pubsub>
</iq>
]]></code></example>
]]></example>
<p>Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another PubSub Collection Node under the Root Node:</p>
<example caption='Adding a Subsection to the Listing'><code><![CDATA[<iq type='set'
<example caption='Adding a Subsection to the Listing'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create3'>
@ -178,14 +171,11 @@
</configure>
</pubsub>
</iq>
]]></code></example>
]]></example>
</section3>
<section3 topic='Subscription' anchor='list-subscription'>
<p>Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:</p>
<example caption='Subscription to entire File Listing'><code><![CDATA[<iq type='set'
<example caption='Subscription to entire File Listing'><![CDATA[<iq type='set'
from='romeo@montague.net/orchard'
to='pubsub.shakespeare.lit'
id='collsub2'>
@ -202,14 +192,11 @@
</options>
</pubsub>
</iq>
]]></code></example>
]]></example>
</section3>
<section3 topic='Addition' anchor='list-addition'>
<p>Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new PubSub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:</p>
<example caption='Adding a new File'><code><![CDATA[<iq type='set'
<example caption='Adding a new File'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='create4'>
@ -311,8 +298,7 @@
</publish>
</pubsub>
</iq>
]]></code></example>
]]></example>
<p>The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.</p>
<p>Node IDs MAY take the form of "path/to/file.ext", rather than the randomized string "a6190c5d38e22452041d1c5798eff3f5" provided in the above use case. For example, Juliet's sonnet MAY instead use a Node ID of "juliets_sonnets/sonnet.txt", as long as this ID is unique within the PubSub server. Randomized strings are used in this document to illustrate that Node IDs SHOULD NOT be used for providing information about files.</p>
<p>Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:</p>
@ -326,8 +312,7 @@
<tr><th>Mirrors</th><td>A list of mirrors; their properties are defined below. If no downloads are available, MAY be left empty or removed entirely.</td></tr>
</table>
<p>Because Romeo is now subscribed, he receives notice of Juliet's addition:</p>
<example caption='Notification of Addition'><code><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
<example caption='Notification of Addition'><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<collection>
<node id='a6190c5d38e22452041d1c5798eff3f5'>
@ -374,16 +359,14 @@
</items>
</event>
</message>
]]></code></example>
]]></example>
<p>The above examples give a listing of several possible file transfer protocols in example configurations. Only the sipub mirror type is REQUIRED; the other types are OPTIONAL. Here is a full listing of those protocols and their available settings:</p>
<table caption="Mirror Types And Their Settings">
<tr><th>Protocol</th>
<th>Description</th><th>Ref</th>
<th>Address</th><th>Port (default)</th>
<th>User</th><th>Pass</th></tr>
<tr><th><link url='#file-requests'>sipub (REQUIRED)</link></th>
<tr><th>sipub (REQUIRED)</th>
<td>OPTIONAL</td><td>N/A</td>
<td>N/A</td><td>N/A</td>
<td>N/A</td><td>N/A</td></tr>
@ -419,7 +402,7 @@
<p>Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:</p>
<example caption='Adding a new Revision'><code><![CDATA[<iq type='set'
<example caption='Adding a new Revision'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='publish1'>
@ -458,14 +441,11 @@
</publish>
</pubsub>
</iq>
]]></code></example>
]]></example>
</section3>
<section3 topic='Modification/Deletion' anchor='list-deletion'>
<p>Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:</p>
<example caption='Modifying a Revision'><code><![CDATA[<iq type='set'
<example caption='Modifying a Revision'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='publish1'>
@ -501,11 +481,10 @@
</publish>
</pubsub>
</iq>
]]></code></example>
]]></example>
<p>Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:</p>
<example caption='Modifying Users'><code><![CDATA[<iq type='set'
<example caption='Modifying Users'><![CDATA[<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='ent3'>
@ -516,11 +495,11 @@
</affiliations>
</pubsub>
</iq>
]]></code></example>
]]></example>
<p>Romeo uses his owner access to remove the older revision of Juliet's sonnet:</p>
<example caption='Deleting a Revision'><code><![CDATA[<iq type='set'
<example caption='Deleting a Revision'><![CDATA[<iq type='set'
from='romeo@montague.net/orchard'
to='pubsub.shakespeare.lit'
id='retract1'>
@ -530,18 +509,17 @@
</retract>
</pubsub>
</iq>
]]></code></example>
]]></example>
<p>Other deletion, modification, and user management operations are available as described in &xep0060; and &xep0248;.</p>
</section3>
</section2>
<section2 topic='File Requests' anchor='file-requests'>
<p>Romeo is interested in seeing what files Juliet has made available. To do this, Romeo sends a request to Juliet for repositories which she is associated with:</p>
<example caption='Request for File Repository listing'><code><![CDATA[<iq type='get'
<example caption='Request for File Repository listing'><![CDATA[<iq type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='repolistreq'>
@ -549,11 +527,11 @@
<list/>
</fileshare>
</iq>
]]></code></example>
]]></example>
<p>Juliet responds with a list of PubSub nodes where she has published files or which she believes would be interesting to Romeo. If no such locations exist, Juliet SHOULD respond with an empty list.</p>
<example caption='File Repository listing'><code><![CDATA[<iq type='get'
<example caption='File Repository listing'><![CDATA[<iq type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='repolist'>
@ -564,18 +542,17 @@
</list>
</fileshare>
</iq>
]]></code></example>
]]></example>
<p>After browsing Juliet's repository, Romeo has chosen to download her sonnet. The most recent revision of this file contains a listing of available mirrors, and Romeo sees that one of them is an SI stream. Romeo sends an SI request to that mirror:</p>
<example caption='Request that a file be sent'><code><![CDATA[<iq type='get'
<example caption='Request that a file be sent'><![CDATA[<iq type='get'
id='sipub-request-0'
from='romeo@montague.net/orchard'
to='fileserver@capulet.com'>
<start xmlns='http://jabber.org/protocol/sipub'
id='publish-sonnet2.txt'/>
</iq>
]]></code></example>
]]></example>
<p>The rest of the negotiation and file transfer occurs as described in &xep0137;.</p>
</section2>

6
xep-0220.xml
View File

@ -52,20 +52,20 @@
</revision>
<revision>
<version>0.15</version>
<initials>psa/ph</initials>
<date>2013-08-27</date>
<initials>psa/ph</initials>
<remark><p>Addressed Last Call feedback and made editorial improvements.</p></remark>
</revision>
<revision>
<version>0.14</version>
<initials>ph</initials>
<date>2012-08-21</date>
<initials>ph</initials>
<remark><p>Updated the Security Considerations to describe the 'Unsolicited Dialback Attack' and added recommendations to avoid this attack.</p></remark>
</revision>
<revision>
<version>0.13</version>
<initials>ph/psa</initials>
<date>2012-08-08</date>
<initials>ph/psa</initials>
<remark>
<ul>
<li>Allowed same SRV target in multiplexing business</li>

17
xep-0224.xml
View File

@ -91,15 +91,14 @@
]]></example>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>The following rules apply to generating and processing of the attention extension.
<ol>
<li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
<li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
<li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
<li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
<li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
</ol>
</p>
<p>The following rules apply to generating and processing of the attention extension.</p>
<ol>
<li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
<li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
<li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
<li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
<li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
</ol>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an entity wishes to receive the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:attention:0":</p>

1
xep-0226.xml
View File

@ -20,7 +20,6 @@
<shortname>profiles</shortname>
&infiniti;
&stpeter;
<registry/>
<revision>
<version>0.3</version>
<date>2008-11-05</date>

54
xep-0244.xml
View File

@ -181,16 +181,14 @@ if (function instanceof IoDataFunction) {
]]></code>
<section2 topic='Transaction Types' anchor='trans'>
<table border="1" caption='IO Data Transaction Types allowed for client to service stanzas'>
<thead>
<tr>
<th>Transaction Type</th>
<th>Purpose</th>
<th>Associated Ad-Hoc Command</th>
<th>REQUIRED for generic XEP compatibility</th>
<th>Contained Elements</th>
</tr>
</thead>
<table caption='IO Data Transaction Types allowed for client to service stanzas'>
<tr>
<th>Transaction Type</th>
<th>Purpose</th>
<th>Associated Ad-Hoc Command</th>
<th>REQUIRED for generic XEP compatibility</th>
<th>Contained Elements</th>
</tr>
<tr>
<th>io-schemata-get</th>
<th>To request the schemata of input and output.</th>
@ -221,16 +219,14 @@ if (function instanceof IoDataFunction) {
</tr>
</table>
<table border="1" caption='IO Data Transaction Types allowed for service to client stanzas'>
<thead>
<tr>
<th>Transaction Type</th>
<th>Purpose</th>
<th>Associated Ad-Hoc Command status value</th>
<th>REQUIRED for generic XEP compatibility</th>
<th>Contained Elements</th>
</tr>
</thead>
<table caption='IO Data Transaction Types allowed for service to client stanzas'>
<tr>
<th>Transaction Type</th>
<th>Purpose</th>
<th>Associated Ad-Hoc Command status value</th>
<th>REQUIRED for generic XEP compatibility</th>
<th>Contained Elements</th>
</tr>
<tr>
<th>io-schemata-result</th>
<th>To return the schemata of input and output.</th>
@ -281,16 +277,14 @@ if (function instanceof IoDataFunction) {
<section1 topic='Implementation Notes' anchor='impl'>
<p>Commands (= remote procedures) executed with Ad-Hoc Commands and IO Data SHOULD NOT keep the requester in an uncertain state. This means the responder SHOULD respond to the requester always as fast as possible. Thereby the requester acquires the sessionid. (As some remote procedures/calculations are cost-intensive and/or time-consuming the requester MUST "save" this sessionid for the case a network problem occurs.)</p>
<p>The Ad-Hoc Command logic applied for the IO Data data container should be associated with the following rules and keywords:</p>
<table border="1" caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
<thead>
<tr>
<th>Ad-Hoc Command</th>
<th>Keyword</th>
<th>Associated Transaction Type</th>
<th>Subsequently allowed commands</th>
<th>Status description</th>
</tr>
</thead>
<table caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
<tr>
<th>Ad-Hoc Command</th>
<th>Keyword</th>
<th>Associated Transaction Type</th>
<th>Subsequently allowed commands</th>
<th>Status description</th>
</tr>
<tr>
<th>execute</th>
<th>Get Schemata</th>

4
xep-0245.xml
View File

@ -68,7 +68,7 @@
]]></example>
<p>Each recipient's client would then show the message with a special presentation, such as:</p>
<example caption="Presentation of /me Command">
<span style='margin-left: 5%; font-style: italic; color: green;'>* Atlas shrugs in disgust</span>
* Atlas shrugs in disgust
</example>
<p>If the receiving client does not find a match on the string "/me " in the first four characters of the message body, it SHOULD NOT present the text in a special way. For example, the following message bodies do not match:</p>
<example caption="Some Non-Commands"><![CDATA[
@ -110,7 +110,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>&xep0045; rooms send XMPP presence stanzas when people leave and join the room, and receiving clients typically show these presence changes as the equivalent of in-room messages, such as the following transformation of a presence stanza of type unavailable:</p>
<example caption="Presentation of In-Room Presence Notification">
<span style='margin-left: 5%; font-style: italic; color: green;'>*** Atlas has left the room</span>
*** Atlas has left the room
</example>
<p>A sender could attempt to spoof such a leave message by sending an XMPP groupchat message stanza whose body text is "/me has left the room". Although the presentation of presence joins and leaves is determined by the receiving client and therefore such a notification cannot be universally spoofed for all receivers, a client SHOULD differentiate between presence notifications and /me commands (e.g., with different colors and different prepended characters, such as several asterisks for presence notifications and one asterisk for /me commands).</p>
</section1>

10
xep-0248.xml
View File

@ -77,19 +77,29 @@
<di>
<dt>Collection Node</dt>
<dd>A type of node that contains other nodes but no published items (<em>c.f.</em> Leaf Node).</dd>
</di>
<di>
<dt>Leaf Node</dt>
<dd>A type of node that contains published items but no other nodes (<em>c.f.</em> Collection Node).</dd>
</di>
<di>
<dt>Node Graph</dt>
<dd>The network of nodes emitting from a given node which contains all its descendants.</dd>
</di>
<di>
<dt>Root Node</dt>
<dd>An anonymous collection node used as the <em>de facto</em> beginning of a service's node graph.</dd>
</di>
<di>
<dt>Subscription Depth</dt>
<dd>How deep the collection node graph will be traversed when determining whether notifications will be sent. May be any integer, 0 or greater, or "all".</dd>
</di>
<di>
<dt>Subscription Type</dt>
<dd>The type of notification, either "nodes", "items", or "all" which the subscriber is interested in.</dd>
</di>

34
xep-0252.xml
View File

@ -101,23 +101,23 @@ Content-Length: 0
</section2>
<section2 topic='Changes to the Response Syntax' anchor='script-response'>
<p>Connection managers MUST make the following changes to convert their responses to Script Syntax:</p>
<ol>
<li><p>Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
<table caption='Character Substitutions'>
<tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
<tr><td>"</td><td>U+0022</td><td>\"</td></tr>
<tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
<tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
<tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
<tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
<tr><td>\</td><td>U+005C</td><td>\\</td></tr>
</table>
<p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p></li>
<li><p>The following eight characters MUST be prepended to the &lt;body/&gt; element: <code>_BOSH_("</code></p></li>
<li><p>The following two characters MUST be appended to the &lt;body/&gt; element: <code>")</code></p></li>
<li><p>If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p></li>
<li><p>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li>
</ol>
<p>1. Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
<table caption='Character Substitutions'>
<tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
<tr><td>"</td><td>U+0022</td><td>\"</td></tr>
<tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
<tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
<tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
<tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
<tr><td>\</td><td>U+005C</td><td>\\</td></tr>
</table>
<p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p>
<p>2. The following eight characters MUST be prepended to the &lt;body/&gt; element:</p>
<code>_BOSH_("</code>
<p>3. The following two characters MUST be appended to the &lt;body/&gt; element:</p>
<code>")</code>
<p>4. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p>
<p>5. Include extra HTTP headers to prevent caching or storage by any intermediary.</p>
<p>Note: All line breaks in the bodies of the HTTP responses in the following two examples are included only to improve readability. In practice there MUST be no line breaks.</p>
<example caption="Session creation response in Script Syntax">
<![CDATA[HTTP/1.1 200 OK

113
xep-0255.xml
View File

@ -395,32 +395,31 @@
</section1>
<section1 topic='Data Format' anchor='format'>
<p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <i>get</i>. The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <i>result</i>. The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see <a href="../xep-0080.html">XEP-0080</a>).</p>
<p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <em>get</em>. The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <em>result</em>. The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see <link url="xep-0080.html">XEP-0080</link>).</p>
<table caption='Location Query Child Elements'>
<tr class="body">
<tr>
<th>Element Name</th>
<th>Datatype</th>
<th>Definition</th>
<th>Example</th>
<th>Notes</th>
</tr>
<tr class="body">
<tr>
<td>timestamp</td>
<td>xs:datetime</td>
<td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
<td>2004-02-19T21:12Z</td>
<td>Optional. If individual location references contain own timing information, this time-stamp shall represent GPS time only, otherwise it shall represent all provided info in the query. If not set, the server may assume current time.</td>
</tr>
<tr class="body">
<tr>
<td>publish</td>
<td>xs:boolean</td>
<td>A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user.</td>
<td>true</td>
<td>Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty &lt;iq&gt; stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a &lt;iq&gt; with type set to "result". Default is "false"</td>
</tr>
<tr class="body">
<tr>
<td>lat</td>
<td>xs:decimal</td>
<td>Latitude in decimal degrees
@ -428,14 +427,14 @@
<td>39.75</td>
<td>Required if no location references present, otherwise optional. If present, this shall also be present in the result stanza. If not present, the location server SHOULD estimate a value based on submitted reference data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on reference data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi references are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.</td>
</tr>
<tr class="body">
<tr>
<td>lon</td>
<td>xs:decimal</td>
<td>Longitude in decimal degrees East</td>
<td>-104.99</td>
<td>See notes for <i>lat</i></td>
<td>See notes for <em>lat</em></td>
</tr>
<tr class="body">
<tr>
<td>alt</td>
<td>xs:decimal</td>
<td>Altitude in meters above or below sea level</td>
@ -443,48 +442,48 @@
<td>Optional. If present, this shall also be present in the result stanza with identical value.</td>
</tr>
<tr class="body">
<tr>
<td>bearing</td>
<td>xs:decimal</td>
<td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
<td> </td>
<td>See notes for <i>alt</i></td>
<td>See notes for <em>alt</em></td>
</tr>
<tr class="body">
<tr>
<td>datum</td>
<td>xs:string</td>
<td>GPS datum (See XEP-0080)</td>
<td> </td>
<td>See notes for <i>alt</i></td>
<td>See notes for <em>alt</em></td>
</tr>
<tr class="body">
<tr>
<td>accuracy</td>
<td>xs:decimal</td>
<td>Horizontal GPS accuracy in meters</td>
<td>10</td>
<td>See notes for <i>lat</i></td>
<td>See notes for <em>lat</em></td>
</tr>
<tr class="body">
<tr>
<td>speed</td>
<td>xs:decimal</td>
<td>The speed at which the entity is moving, in meters per second</td>
<td>52.69</td>
<td>See notes for <i>alt</i></td>
<td>See notes for <em>alt</em></td>
</tr>
<tr class="body">
<tr>
<td>references</td>
<td>locationquery:reference</td>
<td>A list of identifiable location references observed by the entity</td>
<td> </td>
<td>Required if no <i>lat</i> and <i>lon</i> values specified, otherwise optional. See Table 2 for type definition.</td>
<td>Required if no <em>lat</em> and <em>lon</em> values specified, otherwise optional. See Table 2 for type definition.</td>
</tr>
</table>
<table caption='Reference Child Elements'>
<tr class="body">
<tr>
<th>Element Name</th>
<th>Datatype</th>
<th>Definition</th>
@ -492,28 +491,28 @@
<th>Notes</th>
</tr>
<tr class="body">
<tr>
<td>id</td>
<td>xs:string</td>
<td>A world-wide unique reference identifier. This SHALL be composed as follows: <br/><br/>For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID.<br/><br/>For wireless access points and Bluetooth devices: The device MAC address.<br/><br/>For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
<td>A world-wide unique reference identifier. This SHALL be composed as follows: For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID. For wireless access points and Bluetooth devices: The device MAC address. For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
<td>207:02:12643:78596</td>
<td>Required</td>
</tr>
<tr class="body">
<tr>
<td>type</td>
<td>xs:string</td>
<td>Reference type as maintained in the registry specified under <link url='#registrar-reftypes'>Reference Types Registry</link></td>
<td>"cell"</td>
<td>Required.</td>
</tr>
<tr class="body">
<tr>
<td>signalstrength</td>
<td>xs:int</td>
<td>Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, Bluetooth devices)</td>
<td>-64</td>
<td>Optional.</td>
</tr>
<tr class="body">
<tr>
<td>timestamp</td>
<td>xs:datetime</td>
<td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
@ -523,22 +522,22 @@
</table>
<table caption='Location Result Child Elements (Copied from XEP-0080 with notes added)'>
<tr class="body">
<tr>
<th>Element Name</th>
<th>Datatype</th>
<th>Definition</th>
<th>Example</th>
<th>Notes</th>
</tr>
<tr class="body">
<tr>
<td>alt</td>
<td>xs:decimal</td>
<td>Altitude in meters above or below sea level</td>
<td>1609</td>
<td>Piped directly through from query <i>alt</i> field if set.</td>
<td>Piped directly through from query <em>alt</em> field if set.</td>
</tr>
<tr class="body">
<tr>
<td>area</td>
<td>xs:string</td>
<td>A named area such as a campus or neighborhood</td>
@ -546,15 +545,15 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>bearing</td>
<td>xs:decimal</td>
<td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
<td> </td>
<td>Piped directly through from query <i>bearing</i> field if set.</td>
<td>Piped directly through from query <em>bearing</em> field if set.</td>
</tr>
<tr class="body">
<tr>
<td>building</td>
<td>xs:string</td>
<td>A specific building on a street or in an area</td>
@ -562,7 +561,7 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>country</td>
<td>xs:string</td>
<td>The nation where the user is located</td>
@ -570,14 +569,14 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>datum</td>
<td>xs:string</td>
<td>GPS datum (See notes for XEP-0080)</td>
<td></td>
<td>Piped directly through from query <i>datum</i> field if set.</td>
<td>Piped directly through from query <em>datum</em> field if set.</td>
</tr>
<tr class="body">
<tr>
<td>description</td>
<td>xs:string</td>
<td>A natural-language name for or description of the location</td>
@ -585,15 +584,15 @@
<td>If location is mapped to a place in a place oriented service, this should hold the place description.</td>
</tr>
<tr class="body">
<tr>
<td>accuracy</td>
<td>xs:decimal</td>
<td>Horizontal GPS accuracy in meters</td>
<td>10</td>
<td>Piped directly through from query <i>accuracy</i> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
<td>Piped directly through from query <em>accuracy</em> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
</tr>
<tr class="body">
<tr>
<td>floor</td>
<td>xs:string</td>
<td>A particular floor in a building</td>
@ -601,16 +600,16 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>lat</td>
<td>xs:decimal</td>
<td>Latitude in decimal degrees
North</td>
<td>39.75</td>
<td>Piped directly through from query <i>lat</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
<td>Piped directly through from query <em>lat</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
</tr>
<tr class="body">
<tr>
<td>locality</td>
<td>xs:string</td>
<td>A locality within the administrative region, such as a town or city</td>
@ -618,15 +617,15 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>lon</td>
<td>xs:decimal</td>
<td>Longitude in decimal degrees East</td>
<td>-104.99</td>
<td>Piped directly through from query <i>lon</i> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
<td>Piped directly through from query <em>lon</em> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
</tr>
<tr class="body">
<tr>
<td>postalcode</td>
<td>xs:string</td>
<td>A code used for postal delivery</td>
@ -634,7 +633,7 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>region</td>
<td>xs:string</td>
<td>An administrative region of the nation, such as a state or province</td>
@ -642,7 +641,7 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>room</td>
<td>xs:string</td>
<td>A particular room in a building</td>
@ -650,15 +649,15 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>speed</td>
<td>The speed at which the entity is moving, in meters per second</td>
<td>52.69</td>
<td>xs:decimal</td>
<td>Piped directly through from query <i>speed</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
<td>Piped directly through from query <em>speed</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
</tr>
<tr class="body">
<tr>
<td>street</td>
<td>xs:string</td>
<td>A thoroughfare within the locality, or a crossing of two thoroughfares</td>
@ -666,7 +665,7 @@
<td> </td>
</tr>
<tr class="body">
<tr>
<td>text</td>
<td>xs:string</td>
<td>A catch-all element that captures any other information about the location</td>
@ -674,15 +673,15 @@
<td>Best practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)</td>
</tr>
<tr class="body">
<tr>
<td>timestamp</td>
<td>xs:datetime</td>
<td>UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of <cite>XEP-0082</cite>)</td>
<td>2004-02-19T21:12Z</td>
<td>Piped directly through from query <i>timestamp</i> field.</td>
<td>Piped directly through from query <em>timestamp</em> field.</td>
</tr>
<tr class="body">
<tr>
<td>uri</td>
<td>A URI or URL pointing to
information about the location</td>
@ -694,7 +693,7 @@
</table>
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section1>
<section1 topic='Recommended Transport' anchor='transport'>
@ -714,7 +713,7 @@
</section2>
<section2 topic='Client Implementation Notes' anchor='client_impl'>
<p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.<br/><br/> For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
<p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver. For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
</section2>
</section1>
@ -729,7 +728,7 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span> [<a href="notes_iana">7</a>].</p>
<p>This document requires no interaction with the &IANA;.</p>
</section1>

55
xep-0258.xml
View File

@ -198,14 +198,16 @@
<p>The document details when security label meta-data should or should not be provided, and
how this meta-data is to be processed.</p>
<p>This document does not provide: <ul>
<li>any mechanism for a client to discover the security policy in force at its home
server, or any other server;</li>
<li>any mechanism for a client to discover the user's clearance, or the clearance of
associated with any resource; nor</li>
<li>any administrative mechanism for a client to configure configure policy,
clearance, and labels of any resource.</li>
</ul> Such mechanisms may be introduced in subsequent documents.</p>
<p>This document does not provide:</p>
<ul>
<li>any mechanism for a client to discover the security policy in force at its home
server, or any other server;</li>
<li>any mechanism for a client to discover the user's clearance, or the clearance of
associated with any resource; nor</li>
<li>any administrative mechanism for a client to configure configure policy,
clearance, and labels of any resource.</li>
</ul>
<p>Such mechanisms may be introduced in subsequent documents.</p>
<p>This document does not discuss how one might securely bind a security label to a stanza.
It is expected a subsequent document will tackle this topic.</p>
@ -320,10 +322,10 @@
(based upon the user's authorization) in a particular context (such as in chat room). A
catalog may not include the complete set of labels available for the use by the client
in the context.</p>
<blockquote>Note: the single catalog per context approach used here is likely inadequate in
<p><em>Note:</em> the single catalog per context approach used here is likely inadequate in
environments where there are a large number of labels in use. It is expected that a more
sophisticated approach will be introduced in a subsequent revision of this
specification.</blockquote>
specification.</p>
<p>As each service domain may have different support for security labels, servers should
advertise and clients should perform appropriate discovery lookups on a per service
basis.</p>
@ -334,17 +336,14 @@
attribute represents the item's placement in a hierarchical organization of the items.
If one item has a <tt>selector=</tt> attribute, all items should have a
<tt>selector=</tt> attribute. The value of the <tt>selector=</tt> attribute conforms
to the <tt>selector-value</tt> ABNF production: <blockquote><tt>
<![CDATA[
selector-value = (<item>"|")*<item>
]]>
</tt></blockquote>
to the <tt>selector-value</tt> ABNF production:
</p>
<code><![CDATA[selector-value = (<item>"|")*<item>]]></code>
<p>where &ITEM; is a sequence of characters not including "|".</p>
<p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
subset of items. This information may be used, for instance, in generating label
selection menus in graphical user interfaces.</p>
<blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
<p><em>Note:</em> use of unnecessarily deep hierarchies should be avoided.</p>
<example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get'
to='example.com'
@ -648,7 +647,6 @@ selector-value = (<item>"|")*<item>
</section1>
<section1 topic="XML Schemas" anchor="schema">
<section2 topic="Extension Schema" anchor="schema-sl">
<p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0"
@ -748,12 +746,12 @@ selector-value = (<item>"|")*<item>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code> A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label.xsd">
http://xmpp.org/schemas/sec-label.xsd</link>. </p>
]]></code>
<p>A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label.xsd">
http://xmpp.org/schemas/sec-label.xsd</link>.</p>
</section2>
<section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog">
<p>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0"
@ -850,12 +848,12 @@ selector-value = (<item>"|")*<item>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code> A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label-catalog.xsd">
http://xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
]]></code>
<p>A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label-catalog.xsd">
http://xmpp.org/schemas/sec-label-catalog.xsd</link>.</p>
</section2>
<section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess">
<p>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0"
@ -876,9 +874,10 @@ selector-value = (<item>"|")*<item>
</xs:annotation>
</xs:element>
</xs:schema>
]]></code> A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label-ess.xsd">
http://xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
]]></code>
<p>A copy of this schema is available at <link
url="http://xmpp.org/schemas/sec-label-ess.xsd">
http://xmpp.org/schemas/sec-label-ess.xsd</link>.</p>
</section2>
</section1>
</xep>

2
xep-0260.xml
View File

@ -127,7 +127,7 @@
</section1>
<section1 topic='Protocol' anchor='protocol'>
<para>The basic flow is as follows.</para>
<p>The basic flow is as follows.</p>
<code><![CDATA[
Initiator Responder
| |

156
xep-0272.xml
View File

@ -52,79 +52,89 @@
</header>
<section1 topic='Introduction' anchor='intro'>
&xep0166; is used to negotiate peer to peer media sessions.
Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions between a group of people.
Muji conferences are held in &xep0045; rooms.
<p>
&xep0166; is used to negotiate peer to peer media sessions.
Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions
between a group of people.
Muji conferences are held in &xep0045; rooms.
</p>
</section1>
<section1 topic="How it Works" anchor="howitworks">
A Muji conference has a number of contents, each of which has unique name.
content type, and an encoding. Each participant may provide a stream for each
content, and communicates which contents they are willing to provide streams
for, along with encoding information, in their MUC presence. This serves two
purposes. Firstly, so that each participant knows which contents every other
participant provides. Secondly, so that there is a global payload type (PT)
mapping for the various contents, so that clients only need to encode and
payload each content that they provide once.
<p>
A Muji conference has a number of contents, each of which has unique name,
content type, and an encoding.
Each participant may provide a stream for each content, and communicates
which contents they are willing to provide streams for, along with encoding
information, in their MUC presence.
This serves two purposes. Firstly, so that each participant knows which
contents every other participant provides.
Secondly, so that there is a global payload type (PT) mapping for the
various contents, so that clients only need to encode and payload each
content that they provide once.
</p>
<p>
Participants are not required to participate all the contents that are
available.
For example, a Muji client might choose to only request audio streams.
</p>
Participants are not required to participate all the contents that are
available. For example, a Muji client might choose to only request audio
streams.
</section1>
<section1 topic='Joining a Conference' anchor='joining'>
<p>
Joining a conference is done in two stages. The first step is to
declare that preparations are being done to either join or start a muji
session inside the MUC. This is indicated by the client sending a presence
stanza to the MUC with a preparing element in muji section.
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@chat.shakespeare.lit/oldhag'>
<c xmlns="http://jabber.org/protocol/caps"
node="http://telepathy.freedesktop.org/wiki/Muji"
ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
hash="sha-1" />
<muji xmlns='http://telepathy.freedesktop.org/muji'>
<preparing />
</muji>
</presence>
]]></code>
The client MUST then wait until the MUC rebroadcasts its presence message,
after which it MUST wait for all other participants that had a preparing
element in their presence to finish preparation. Afterwards it should finish
it's own preparation by updating its presence with the contents it wants to
take part in.
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@chat.shakespeare.lit/oldhag'>
<c xmlns="http://jabber.org/protocol/caps"
node="http://telepathy.freedesktop.org/wiki/Muji"
ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
hash="sha-1" />
<muji xmlns='http://telepathy.freedesktop.org/muji'>
<content name='video'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
<payload-type id='97' name='theora' clockrate='90000'/>
</description>
</content>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
</description>
</content>
</muji>
</presence>
]]></code>
Joining a conference is done in two stages. The first step is to
declare that preparations are being done to either join or start a muji
session inside the MUC. This is indicated by the client sending a presence
stanza to the MUC with a preparing element in muji section.
</p>
<p>
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@chat.shakespeare.lit/oldhag'>
<c xmlns="http://jabber.org/protocol/caps"
node="http://telepathy.freedesktop.org/wiki/Muji"
ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
hash="sha-1" />
<muji xmlns='http://telepathy.freedesktop.org/muji'>
<preparing />
</muji>
</presence>
]]></code>
<p>
The client MUST then wait until the MUC rebroadcasts its presence message,
after which it MUST wait for all other participants that had a preparing
element in their presence to finish preparation. Afterwards it should finish
it's own preparation by updating its presence with the contents it wants to
take part in.
</p>
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
to='darkcave@chat.shakespeare.lit/oldhag'>
<c xmlns="http://jabber.org/protocol/caps"
node="http://telepathy.freedesktop.org/wiki/Muji"
ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
hash="sha-1" />
<muji xmlns='http://telepathy.freedesktop.org/muji'>
<content name='video'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
<payload-type id='97' name='theora' clockrate='90000'/>
</description>
</content>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
</description>
</content>
</muji>
</presence>
]]></code>
<p>
When a client adds a payload ID to a content description, it MUST have the
same codec name and receiving parameters as the corresponding entries in
other participants' payload maps for that content. For instance, if Alice
@ -171,9 +181,10 @@ streams.
<section1 topic='Adding a Content Type' anchor='addcontent'>
<p>
Adding a stream follows a process similar to the joining a conference. As a
first step an updated presence stanza MUST be send which contains a preparing
element as part of the Muji section.
Adding a stream follows a process similar to the joining a conference. As a
first step an updated presence stanza MUST be send which contains a
preparing element as part of the Muji section.
</p>
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
@ -194,13 +205,17 @@ streams.
</presence>
]]></code>
The client MUST then wait until the MUC rebroadcasts its presence message,
after which it MUST wait for all other participants that had a preparing
element in their presence to finish their changes.
<p>
The client MUST then wait until the MUC rebroadcasts its presence message,
after which it MUST wait for all other participants that had a preparing
element in their presence to finish their changes.
</p>
Afterwards the client should add the new content to the muji section of its
presence and add the content to all the Jingle sessions it had with
participants it shared the content with.
<p>
Afterwards the client should add the new content to the muji section of its
presence and add the content to all the Jingle sessions it had with
participants it shared the content with.
</p>
<code><![CDATA[
<presence from='wiccarocks@shakespeare.lit/laptop'
@ -224,7 +239,6 @@ streams.
</muji>
</presence>
]]></code>
</p>
</section1>
<section1 topic='Removing a Content Type' anchor='removecontent'>