moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 02:02:16 -05:00
Code Issues Releases Wiki Activity

Merge branch 'feature/typos'

Browse Source
This commit is contained in:
Jonas Schäfer 2018-11-03 15:15:05 +01:00
commit f3b18b969c
29 changed files with 253 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ref.xsl
View File

@ -25,7 +25,7 @@ THE SOFTWARE.
-->
<!-- Author: stpeter
Description: transforms XEP meta-data into IETF reference
Description: transforms XEP metadata into IETF reference
-->
<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' version='1.0'>

22
xep-0052.xml
View File

@ -44,6 +44,12 @@
<email>justin@affinix.com</email>
<jid>justin@andbit.net</jid>
</author>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-09-30</date>
@ -80,7 +86,7 @@
<p>Primary Flow:</p>
<ol>
<li>Determine if the receiver supports FT through disco/browse. [E1]</li>
<li>Sender sends meta-data and available methods to receiver</li>
<li>Sender sends metadata and available methods to receiver</li>
<li>Receiver sends the accepted method to Sender and any range/offset
information. [E2],[E3]</li>
<li>Sender and Receiver establish the negotiated method[E4]</li>
@ -214,7 +220,7 @@
<p>
At this point the sender will setup the stream method and begin to transfer
data. The stream itself can use the file transfer namespace to tie the
meta-data to the actual data sent, this is illustrated below using iq:oob.
metadata to the actual data sent, this is illustrated below using iq:oob.
</p>
<example caption='Starting an iq:oob transfer'>
@ -252,7 +258,7 @@
</example>
<p>
If the transfer does not complete, for any reason after the meta-data
If the transfer does not complete, for any reason after the metadata
negotiation, the party that has the error SHOULD send an error 500 and
the file id to the other party.
</p>
@ -266,9 +272,9 @@
</section1>
<section1 topic='Stream Relation'>
<p>By staying in just the realm of negotiating the meta-data to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the meta-data to the actual data transfer, to help accomodate this the stream may use the &lt;file/&gt; with an action of start and the correct id. The &lt;file/&gt; could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.</p>
<p>By staying in just the realm of negotiating the metadata to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the metadata to the actual data transfer, to help accomodate this the stream may use the &lt;file/&gt; with an action of start and the correct id. The &lt;file/&gt; could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.</p>
<section2 topic='"iq:oob" Relation'>
<p>For an "iq:oob" transfer to be related to it's meta-data, a &lt;file/&gt; is transported along side the &lt;query/&gt;. The id used on the &lt;file/&gt; is the id for the meta-data of the actual data that is being sent. The action on the &lt;file/&gt; is "start". An example of this can be found in the Basic Usage section.</p>
<p>For an "iq:oob" transfer to be related to its metadata, a &lt;file/&gt; is transported along side the &lt;query/&gt;. The id used on the &lt;file/&gt; is the id for the metadata of the actual data that is being sent. The action on the &lt;file/&gt; is "start". An example of this can be found in the Basic Usage section.</p>
</section2>
</section1>
<section1 topic='Formal Description'>
@ -292,7 +298,7 @@
]]></code>
</section2>
<section2 topic='&lt;file/&gt; Element'>
<p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt; (&xep0020;) elements.</p>
<p>The &lt;file/&gt; element is the "workhorse" element. This element is used to convey metadata and report file transfer actions. This elemnt contains attributes for file metadata and actions, and MAY contain a &lt;desc/&gt;, a &lt;range/&gt;, and zero or more &lt;feature xmlns='jabber:iq:negotiate'/&gt; (&xep0020;) elements.</p>
<p>The "id" attribute specifies the identifier for this particular file transfer. This attribute MUST be present at all times. There are no value requirements other than it MUST be unique between the sender and receiver.</p>
<p>The "action" attribute specifies the action to undertake with the given file. This attribute SHOULD be present in most cases. If not present, the value "offer" is implied. The value of "action" MUST be one of the following:</p>
<table caption='Possible "action" values'>
@ -310,7 +316,7 @@
</tr>
<tr>
<td>offer</td>
<td>The file transfer is offered (meta-data MUST be present)</td>
<td>The file transfer is offered (metadata MUST be present)</td>
</tr>
<tr>
<td>start</td>
@ -342,7 +348,7 @@
conditions, error codes and descriptions:</p>
<ul>
<li>
<em>Declining Transfer (403)</em>: During the meta-data negotiation
<em>Declining Transfer (403)</em>: During the metadata negotiation
the receiver may decline the transfer by sending the 403 error. The
&lt;error/&gt; CDATA MAY contain a descriptive reason why, but is not
necessary.

8
xep-0056.xml
View File

@ -23,6 +23,12 @@
<email>chicago5@gmx.de</email>
<jid>uls@jabber.org</jid>
</author>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-11-18</date>
@ -76,7 +82,7 @@ ebXML Messages SHALL be transmitted within Jabber IQ chunks. The value of the 't
EbXML information is always transmitted in this envelope. No transformation of native ebXML tags into native Jabber tags is performed (e.g., ebXML reception receipt into Jabber reception receipt). The business logic, on top of Jabber transport logic, has to parse incoming IQ chunks and forward received ebXML information to the ebXML Messaging Service. The business logic has as well to pack the ebXML messages into IQ chunks and invoke the message delivery.
</p>
<p>
Although a complex business transaction between two or more Trading Partners might require a payload that contains an array of business documents, binary images, or other related Business Information' <note>Walsh. 2002. <em>ebXML: The Technical Specifications</em>; p. 69</note>, only one ebXML message can be (at the moment) transmitted at a time in one message. However, the ebXML Message MAY contain payload in it's own payload envelope.
Although a complex business transaction between two or more Trading Partners might require a payload that contains an array of business documents, binary images, or other related Business Information' <note>Walsh. 2002. <em>ebXML: The Technical Specifications</em>; p. 69</note>, only one ebXML message can be (at the moment) transmitted at a time in one message. However, the ebXML Message MAY contain payload in its own payload envelope.
</p>
<p>It has to be noted: The karma restriction of XMPP, implied on clients, makes transmission of large amounts of payload (at the moment) to services or other clients from client side nearly impossible. However, components' karma is not restrained.
</p>

43
xep-0060.xml
View File

@ -49,7 +49,12 @@
&pgmillard;
&stpeter;
&ralphm;
<revision>
<version>1.15.3</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>1.15.2</version>
<date>2018-05-14</date>
@ -171,7 +176,7 @@
<li>Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.</li>
<li>Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.</li>
<li>Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the &lt;default/&gt; element (also added the &lt;default/&gt; element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
<li>Removed informational mapping of node meta-data to Dublin Core.</li>
<li>Removed informational mapping of node metadata to Dublin Core.</li>
</ul>
</remark>
</revision>
@ -256,7 +261,7 @@
<li>Changed retrieval of default node configuration options to use &lt;default/&gt; element, not &lt;configure/&gt; element</li>
<li>Allowed caching of last published item</li>
<li>Added pubsub#deliver subscription option</li>
<li>Added meta-data fields for pubsub#owners and pubsub#contact</li>
<li>Added metadata fields for pubsub#owners and pubsub#contact</li>
<li>Changed element for retrieval of default node configuration options from &lt;configure/&gt; to &lt;default/&gt; to prevent ambiguity related to configuration of root collection node</li>
<li>Specified pubsub#node_type configuration field</li>
<li>Specified pubsub#collection SHIM header</li>
@ -285,7 +290,7 @@
<li>Added type attribute for the &lt;create/&gt; and &lt;configure/&gt; elements to differentiate between leaf nodes and collection nodes</li>
<li>In Section 8.1.7, changed affiliations retrieval support to SHOULD and added pubsub#retrieve-affiliations feature</li>
<li>In Section 8.1.10, removed two duplicate examples</li>
<li>In Section 8.1.12, clarified relationship between normal disco#info data and node meta-data (which uses a service discovery extension)</li>
<li>In Section 8.1.12, clarified relationship between normal disco#info data and node metadata (which uses a service discovery extension)</li>
<li>In Section 8.2.4, specified that node purgation MUST result in one event notification, not a notification per item</li>
<li>In Section 8.1.8, further specified handling of SubIDs</li>
<li>Clarified nature of the pubsub#type field</li>
@ -301,7 +306,7 @@
<version>1.6</version>
<date>2004-07-13</date>
<initials>pgm/psa</initials>
<remark><p>Added service discovery features for pubsub#meta-data, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.</p></remark>
<remark><p>Added service discovery features for pubsub#metadata, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.</p></remark>
</revision>
<revision>
<version>1.5</version>
@ -367,7 +372,7 @@
<version>0.12</version>
<date>2003-08-13</date>
<initials>pgm/psa</initials>
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed &lt;x/&gt; to &lt;event/&gt; for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.</p></remark>
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed &lt;x/&gt; to &lt;event/&gt; for #events namespace; added metadata about meta-nodes; fully defined XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.11</version>
@ -584,7 +589,7 @@ And by opposing end them?
<li>A node MAY be configured to persist published items to some persistent storage mechanism.</li>
<li>A node MAY be configured to persist only a limited number of items.</li>
<li>A service MAY support collections as described in <cite>XEP-0248</cite>.</li>
<li>A service or node MAY support extended service discovery information (meta-data).</li>
<li>A service or node MAY support extended service discovery information (metadata).</li>
</ul>
</section1>
@ -981,7 +986,7 @@ And by opposing end them?
]]></example>
</section2>
<section2 topic='Discover Node Metadata' anchor='entity-metadata'>
<p>The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
<p>The "disco#info" result MAY include detailed metadata about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#metadata" in accordance with &xep0068;. If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
<example caption='Entity queries a node for information'><![CDATA[
<iq type='get'
from='francisco@denmark.lit/barracks'
@ -991,7 +996,7 @@ And by opposing end them?
node='princely_musings'/>
</iq>
]]></example>
<example caption='Service responds with information and meta-data'><![CDATA[
<example caption='Service responds with information and metadata'><![CDATA[
<iq type='result'
from='pubsub.shakespeare.lit'
to='francisco@denmark.lit/barracks'
@ -1002,7 +1007,7 @@ And by opposing end them?
<feature var='http://jabber.org/protocol/pubsub'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#type' label='Payload type' type='text-single'>
<value>http://www.w3.org/2005/Atom</value>
@ -1041,7 +1046,7 @@ And by opposing end them?
</query>
</iq>
]]></example>
<p>Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.</p>
<p>Note: Node metadata can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node metadata SHOULD be provided as fields in the node configuration form.</p>
<p>Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.</p>
</section2>
@ -5118,8 +5123,8 @@ And by opposing end them?
<td><link url='#affiliations'>Affiliations</link></td>
</tr>
<tr>
<td>meta-data</td>
<td>Node meta-data is supported.</td>
<td>metadata</td>
<td>Node metadata is supported.</td>
<td>RECOMMENDED</td>
<td>&#160;</td>
</tr>
@ -6013,8 +6018,8 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<doc>XEP-0060</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<desc>Node meta-data is supported.</desc>
<name>http://jabber.org/protocol/pubsub#metadata</name>
<desc>Node metadata is supported.</desc>
<doc>XEP-0060</doc>
</var>
<var>
@ -6136,7 +6141,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<li>Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.</li>
<li>Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.</li>
<li>Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.</li>
<li>Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.</li>
<li>Setting of metadata information using the 'http://jabber.org/protocol/pubsub#metadata' namespace.</li>
</ol>
<p>The registry submissions associated with these namespaces are defined below.</p>
<p>Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of <cite>XEP-0068</cite>, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.</p>
@ -6240,10 +6245,10 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
</form_type>
]]></code>
</section3>
<section3 topic='pubsub#meta-data FORM_TYPE' anchor='registrar-formtypes-metadata'>
<section3 topic='pubsub#metadata FORM_TYPE' anchor='registrar-formtypes-metadata'>
<code><![CDATA[
<form_type>
<name>http://jabber.org/protocol/pubsub#meta-data</name>
<name>http://jabber.org/protocol/pubsub#metadata</name>
<doc>XEP-0060</doc>
<desc>Forms enabling setting of metadata information about pubsub nodes</desc>
<field var='pubsub#contact'
@ -6863,7 +6868,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
<xs:enumeration value='leased-subscription'/>
<xs:enumeration value='manage-subscriptions'/>
<xs:enumeration value='member-affiliation'/>
<xs:enumeration value='meta-data'/>
<xs:enumeration value='metadata'/>
<xs:enumeration value='modify-affiliations'/>
<xs:enumeration value='multi-collection'/>
<xs:enumeration value='multi-items'/>

8
xep-0062.xml
View File

@ -29,6 +29,12 @@
<email>rob@cataclysm.cx</email>
<jid>rob@cataclysm.cx</jid>
</author>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-09-30</date>
@ -183,7 +189,7 @@
</p>
<section2 topic='Module discovery'>
<p>An entity may find out if a service supports filtering, and the modules its supports, by issuing a discovery request to the service:</p>
<p>An entity may find out if a service supports filtering, and the modules it supports, by issuing a discovery request to the service:</p>
<example caption='Module discovery'><![CDATA[
<iq type='get' to='jabber.org' 'disco1'>

8
xep-0099.xml
View File

@ -23,6 +23,12 @@
<email>iain@jivesoftware.com</email>
<jid>smirk@jabber.com</jid>
</author>
<revision>
<version>0.1.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-06-25</date>
@ -32,7 +38,7 @@
</header>
<section1 topic='Introduction'>
<p>There is a need for consistent query behavior amongst XMPP &IQ; protocols. Currently
each protocol invents it's own, slightly different behavior for conducting
each protocol invents its own, slightly different behavior for conducting
query behavior to create, read, update, and delete (CRUD) recipient node data. This document defines a generic
query acton protocol to standardize behavior across &IQ; protocols. In addition, we hope
this standard will make other protocols easier to understand and implement by using a common

8
xep-0101.xml
View File

@ -28,6 +28,12 @@
<email>richard@dobson-i.net</email>
<jid>richard@dobson-i.net</jid>
</author>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2004-01-18</date>
@ -44,7 +50,7 @@
<section1 topic='Introduction'>
<p>Jabber Ticket Authentication is a method of authenticating with HTTP servers using your jabber identification.</p>
<p>This allows you to login to websites using your jabber address in a single sign-on fashion similar to .NET Passport, but unlike .NET Passport is not locked into a single authentication provider.</p>
<p>Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.</p>
<p>Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because it's not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.</p>
</section1>
<section1 topic='Requirements'>
<p>The motivations for this document are:</p>

8
xep-0103.xml
View File

@ -22,6 +22,12 @@
<supersededby/>
<shortname>url-data</shortname>
&linuxwolf;
<revision>
<version>0.4.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2004-01-20</date>
@ -60,7 +66,7 @@
<p>The requirements this protocol fulfills are:</p>
<ul>
<li>Simple usage that can be easily extended</li>
<li>Provide any meta-data necessary for using the URL</li>
<li>Provide any metadata necessary for using the URL</li>
<li>Compatibility with &xep0095;</li>
</ul>
</section1>

10
xep-0105.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Tree Transfer Stream Initiation Profile</title>
<abstract>A profile describing meta-data for transferring trees of files using stream inititation.</abstract>
<abstract>A profile describing metadata for transferring trees of files using stream inititation.</abstract>
&LEGALNOTICE;
<number>0105</number>
<status>Deferred</status>
@ -21,6 +21,12 @@
<supersededby/>
<shortname>si-treetransfer</shortname>
&reatmon;
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-09-22</date>
@ -41,7 +47,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>File transfers of entire trees require a lot more meta-data and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that meta-data so that directory trees can be transfered.</p>
<p>File transfers of entire trees require a lot more metadata and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that metadata so that directory trees can be transfered.</p>
</section1>
<section1 topic='Requirements'>
<ul>

16
xep-0109.xml
View File

@ -32,6 +32,12 @@
<email>rob@cataclysm.cx</email>
<jid>rob@cataclysm.cx</jid>
</author>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2010-05-24</date>
@ -91,7 +97,7 @@
<start>2003-07-06T10:30:00+10:00</start>
<end>2003-07-13T08:00:00+10:00</end>
<message>I'm attending OSCON in sunny Portland and won't be able to
read your message until I get back. If its urgent, please
read your message until I get back. If it's urgent, please
send email to rob@cataclysm.cx.</message>
]]></example>
@ -141,7 +147,7 @@
<start>2003-07-06T10:30:00+10:00</start>
<end>2003-07-13T08:00:00+10:00</end>
<message>I'm attending OSCON in sunny Portland and won't be able to
read your message until I get back. If its urgent, please
read your message until I get back. If it's urgent, please
send email to rob@cataclysm.cx.</message>
</ooo>
</item>
@ -183,7 +189,7 @@
<start>2003-07-06T10:30:00+10:00</start>
<end>2003-07-13T08:00:00+10:00</end>
<message>I'm attending OSCON in sunny Portland and won't be able to
read your message until I get back. If its urgent, please
read your message until I get back. If it's urgent, please
send email to rob@cataclysm.cx.</message>
</ooo>
</item>
@ -204,7 +210,7 @@
<start>2003-07-06T10:30:00+10:00</start>
<end>2003-07-13T08:00:00+10:00</end>
<message>I'm attending OSCON in sunny Portland and won't be able to
read your message until I get back. If its urgent, please
read your message until I get back. If it's urgent, please
send email to rob@cataclysm.cx.</message>
</ooo>
</item>
@ -226,7 +232,7 @@
<start>2003-07-06T10:30:00+10:00</start>
<end>2003-07-13T08:00:00+10:00</end>
<message>I'm attending OSCON in sunny Portland and won't be able to
read your message until I get back. If its urgent, please
read your message until I get back. If it's urgent, please
send email to rob@cataclysm.cx.</message>
</ooo>
</item>

24
xep-0142.xml
View File

@ -27,6 +27,12 @@
<email>matt@jivesoftware.com</email>
<jid>jivematt@jabber.org</jid>
</author>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2005-05-09</date>
@ -163,7 +169,7 @@ U: <queue-notifications/>
U: </join-queue>
U: </iq>
]]></example>
<p>The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the &lt;join-queue&gt; element MAY contain a standard &lt;queue-notifications/&gt; element, which indicates that the user would like to receive user status updates about their state in the queue.</p>
<p>The request may contain application-specific metadata to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the &lt;join-queue&gt; element MAY contain a standard &lt;queue-notifications/&gt; element, which indicates that the user would like to receive user status updates about their state in the queue.</p>
<p>A successful join results in a success response:</p>
<example caption='Response Element'><![CDATA[
S: <iq to='user@example.net/home' from='support@workgroup.example.com' id='id1' type='result'/>
@ -213,7 +219,7 @@ S: from='support@workgroup.example.com'
S: to='user@example.net/home'
S: id='id1'/>
]]></example>
<p>The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the &lt;crm/&gt; element in this example would be defined outside the context of this specification).</p>
<p>The following XML is another example where metadata is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the &lt;crm/&gt; element in this example would be defined outside the context of this specification).</p>
<example caption='Join With Meta-Data'><![CDATA[
U: <iq type='set'
U: from='user@example.net/home'
@ -498,7 +504,7 @@ S: </message>
<section1 topic='Agent Protocol' anchor='agent'>
<section2 topic='Agent States' anchor='proto-agent-states'>
<p>Agents join a workgroup to indicate they are capable of handling conversations with users. Agent membership in the workgroup is expected to be a long term, persistent relationship similar to roster membership. For example, a customer support agent may join the support@workgroup.example.com workgroup when they begin working at example.com and will only depart when they leave that position. The wide variety of relationships, processes and permissions associated with joining and leaving workgroups lies outside the scope of this document.</p>
<p>Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional meta-data to help routing of chat requests to agents. Some meta-data will be standard and defined later in this document. It is expected that other deployment specific meta-data will also be needed to make routing decisions.</p>
<p>Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional metadata to help routing of chat requests to agents. Some metadata will be standard and defined later in this document. It is expected that other deployment specific metadata will also be needed to make routing decisions.</p>
<p>The general agent workgroup state diagram is shown below:</p>
<code><![CDATA[
+-----------+
@ -546,7 +552,7 @@ Agent Service
|----------------------------->|
| |
]]></example>
<p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p>
<p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional metadata. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p>
<example caption='Presence Update'><![CDATA[
U: <presence from='alice@example.com/work' to='support@workgroup.example.com'>
U: <agent-status xmlns='http://jabber.org/protocol/workgroup'>
@ -561,7 +567,7 @@ U: </presence>
<li>xa - The agent is physically away from their terminal and should not have a chat routed to them.</li>
<li>dnd - The agent is busy and should not be disturbed. However, special case, or extreme urgency chats may still be offered to the agent although offer rejection or offer timeouts are highly likely.</li>
</ul>
<p>Agents MAY also embed meta-data to help the workgroup service route chat requests, using the &lt;max-chats&gt; element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. <note>The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.</note></p>
<p>Agents MAY also embed metadata to help the workgroup service route chat requests, using the &lt;max-chats&gt; element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. <note>The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.</note></p>
<section4 topic='Error Conditions' anchor='proto-agent-presence-errors'>
<p>There are no defined error conditions for presence updates.</p>
</section4>
@ -750,7 +756,7 @@ S: <timeout>seconds</timeout>
S: </offer>
S: </iq>
]]></example>
<p>Application specific meta-data will normally be added as a sub-element of &lt;offer&gt; to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional &lt;timeout&gt; sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p>
<p>Application specific metadata will normally be added as a sub-element of &lt;offer&gt; to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional &lt;timeout&gt; sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p>
<example caption='Offer Response'><![CDATA[
A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/>
]]></example>
@ -773,7 +779,7 @@ A: from='alice@example.com/work'
A: id='id1'
A: type='result'/>
]]></example>
<p>The following is a more typical offer containing meta-data about the user. The offer will be revoked in 30 seconds.</p>
<p>The following is a more typical offer containing metadata about the user. The offer will be revoked in 30 seconds.</p>
<example caption='Offer Including Meta-Data'><![CDATA[
S: <iq to='alice@example.com/work'
S: from='support@workgroup.example.com'
@ -893,7 +899,7 @@ Agent Service
| |
]]></example>
<p>The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the &lt;invite/&gt; element MUST be set to the JID of the workgroup.</p>
<p>In order to match invitations to offers, all invitations SHOULD include meta-data in the &lt;offer/&gt; element, with the JID of the user specified via the 'jid' attribute. The typical meta-data fragment would appear as:</p>
<p>In order to match invitations to offers, all invitations SHOULD include metadata in the &lt;offer/&gt; element, with the JID of the user specified via the 'jid' attribute. The typical metadata fragment would appear as:</p>
<example caption='Invitation Meta-Data'><![CDATA[
<offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'>
]]></example>
@ -927,7 +933,7 @@ S: </message>
<li>Use the &lt;identity&gt; type='workgroup'.</li>
<li>Use the &lt;feature&gt; var='http://jabber.org/protocol/workgroup'.</li>
</ul>
<p>An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by it's JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the &lt;identity&gt; and &lt;feature&gt; tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the &lt;identity&gt; and &lt;feature&gt; tags are again presented to identify them as workgroups along with (optional) associated meta-data.</p>
<p>An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by its JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the &lt;identity&gt; and &lt;feature&gt; tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the &lt;identity&gt; and &lt;feature&gt; tags are again presented to identify them as workgroups along with (optional) associated metadata.</p>
<example caption='Workgroup Service Discovery'><![CDATA[
U: <iq to='example.com' from='user@example.net/home' id='id1' type='get'>
U: <query xmlns='http://jabber.org/protocol/disco#items'/>

16
xep-0214.xml
View File

@ -31,6 +31,12 @@
<email>nickbp@gmail.com</email>
<jid>nickp@jabber.org</jid>
</author>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2009-01-05</date>
@ -127,7 +133,7 @@
<configure node='juliets_sonnets'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#title'><value>Juliet's Sonnets</value></field>
<field var='pubsub#description'><value>Optional Description</value></field>
@ -163,7 +169,7 @@
<configure node='35227eec194a4f3971a5f3771e9c2271'/>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#title'><value>Sonnets About Romeo</value></field>
<field var='pubsub#description'><value>Optional Description</value></field>
@ -218,7 +224,7 @@
<configure node='a6190c5d38e22452041d1c5798eff3f5'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#title'><value>sonnet.txt</value></field>
<field var='pubsub#description'><value>Sonnet 42</value></field>
@ -234,7 +240,7 @@
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='a6190c5d38e22452041d1c5798eff3f5'>
<item id='1'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_meta-data'>
<entry xmlns='http://jabber.org/protocol/fileshare#item_metadata'>
<size>5623</size>
<modified>2006-12-13T18:30:02Z</modified>
<checksum type="sha1">59282c5db190bdc3b152c5b38363442bfda8ebdd</checksum>
@ -332,7 +338,7 @@
<configuration node='a6190c5d38e22452041d1c5798eff3f5'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#description'><var>Sonnet 42</var></field>
<field var='pubsub#title'><var>sonnet.txt</var></field>

14
xep-0248.xml
View File

@ -31,6 +31,12 @@
<email>bjc@kublai.com</email>
<jid>bjc@kublai.com</jid>
</author>
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2010-09-28</date>
@ -248,7 +254,7 @@
]]></example>
<section4 topic='Including Node Meta-Data' anchor='notify-metadata'>
<p>The notification event MAY also include the node meta-data, formatted using the &xep0004; protocol.</p>
<p>The notification event MAY also include the node metadata, formatted using the &xep0004; protocol.</p>
<example caption='Notification of node association'><![CDATA[
<message from='pubsub.shakespeare.lit'
@ -259,7 +265,7 @@
<associate node='new-node-id'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
<value>http://jabber.org/protocol/pubsub#metadata</value>
</field>
<field var='pubsub#creation_date'>
<value>2003-07-29T22:56Z</value>
@ -658,7 +664,7 @@
</section4>
<section4 topic='Maximum Number of Children Exceeded' anchor='error-max-children'>
<p>If the configuration would exceed the maximum number of children allowed on a node, either because the node's "pubsub#children" exceeds it's own "pubsub#children_max" value or because adding this node to a parent via "pubsub#collection" would exceed the parent's "pubsub#children_max" value, the service MUST return a &notallowed; error with a pubsub-specific error condition of &lt;max-nodes-exceeded/&gt;.</p>
<p>If the configuration would exceed the maximum number of children allowed on a node, either because the node's "pubsub#children" exceeds its own "pubsub#children_max" value or because adding this node to a parent via "pubsub#collection" would exceed the parent's "pubsub#children_max" value, the service MUST return a &notallowed; error with a pubsub-specific error condition of &lt;max-nodes-exceeded/&gt;.</p>
<example caption='Node would contain too many children'><![CDATA[
<iq type='error'
@ -796,7 +802,7 @@
</section4>
<section4 topic='Maximum Number of Children Exceeded' anchor='error-assoc-too-many-nodes'>
<p>If the configuration would exceed the maximum number of children allowed on a node, either because the node's "pubsub#children" exceeds it's own "pubsub#children_max" value or because adding this node to a parent via "pubsub#collection" would exceed the parent's "pubsub#children_max" value, the service MUST return a &notallowed; error with a pubsub-specific error condition of &lt;max-nodes-exceeded/&gt;.</p>
<p>If the configuration would exceed the maximum number of children allowed on a node, either because the node's "pubsub#children" exceeds its own "pubsub#children_max" value or because adding this node to a parent via "pubsub#collection" would exceed the parent's "pubsub#children_max" value, the service MUST return a &notallowed; error with a pubsub-specific error condition of &lt;max-nodes-exceeded/&gt;.</p>
<example caption='Node would contain too many children'><![CDATA[
<iq type='error'

8
xep-0255.xml
View File

@ -38,6 +38,12 @@
<email>ross@buddycloud.com</email>
<jid>ross@buddycloud.com</jid>
</author>
<revision>
<version>0.6.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.6</version>
<date>2009-04-09</date>
@ -708,7 +714,7 @@
<p>If no GPS coordinate and accuracy information is submitted in the query, and the server determines location coordinates from submitted reference data, a value for the returned geoloc 'accuracy' field SHOULD be returned. The magnitude of this should be derived based on the ranges of the location references used to determine the location, if known. </p>
<p>The server should make no assumptions about how often a entity submits a query. It should support occasional manually triggered queries as well as periodic automated queries. In the latter case it should analyze changes over time, as this can greatly increase the fidelity of the result. </p>
<p>Furthermore, no assumptions should be made about the number and types of location references being logged in each query. Some handset manufacturers limit the access programmers have to cell tower and access point information. Some may only offer the currently connected cell ID, such that even if the handset can "see" many cell towers, only the one to which the handset is connected at the moment can be read. In this case the cell tower readings may not be constant, even if the querying entity is not moving. Rather it may jump round-robin style to each visible cell with variable time spent on each. The location server should account for this to avoid yielding results indicating that a user is running around in cell-sized circles when he is in fact stationary. Again, analysis of variation of submitted queries over time is recommended.</p>
<p>As no guarantees can be made that a given location reference stays at one fixed physical location throughout it's lifetime, the server should implement means to detect this. Generally it can be assumed that cell towers seldom move (could happen when a network operator changes the way it allocates cell IDs or when a tower is physically moved to a different location). Wireless access points move a bit more frequently (for instance when their owners move, or if they are installed in moving vehicles such as busses or trains). Bluetooth devices can generally be assumed to be mobile and should, unless specific knowledge to the contrary exists, not be used to locate an entity to a specific physical location. Rather, Bluetooth devices (and other mobile references) can be used to co-locate entities to other entities for which a physical location is known. An example: Entity A submits query with GPS coordinates and the ID of some Bluetooth device. It is located based on its submitted coordinates. Entity B submits a query with the same Bluetooth device ID, but no GPS coordinates. Given this, and the fact that Bluetooth transmitters have a very limited range, the server can then derive that A and B are at the same physical location (it may add 10-20 m to the accuracy of the location of B to account for the Bluetooth range).</p>
<p>As no guarantees can be made that a given location reference stays at one fixed physical location throughout its lifetime, the server should implement means to detect this. Generally it can be assumed that cell towers seldom move (could happen when a network operator changes the way it allocates cell IDs or when a tower is physically moved to a different location). Wireless access points move a bit more frequently (for instance when their owners move, or if they are installed in moving vehicles such as busses or trains). Bluetooth devices can generally be assumed to be mobile and should, unless specific knowledge to the contrary exists, not be used to locate an entity to a specific physical location. Rather, Bluetooth devices (and other mobile references) can be used to co-locate entities to other entities for which a physical location is known. An example: Entity A submits query with GPS coordinates and the ID of some Bluetooth device. It is located based on its submitted coordinates. Entity B submits a query with the same Bluetooth device ID, but no GPS coordinates. Given this, and the fact that Bluetooth transmitters have a very limited range, the server can then derive that A and B are at the same physical location (it may add 10-20 m to the accuracy of the location of B to account for the Bluetooth range).</p>
<p>The "radio landscape" is by no means constant. New cells and access points are added continuously, and old ones are phased out. A location server will have to adapt to this shifting landscape, either by means of operator-supplied databases (in case of cell towers) or by means of user generated information. This standard was written with the latter in mind, and it is recommended that location servers utilize any queries with both GPS coordinates and location references to "learn" the approximate physical location of the provided references. For server implementation that rely on user generated information only, it is also recommended to supply additional means for the users to feed back location context in cases where the client does not have any GPS access, or when the server produces the wrong results. One way to do this would be to let the users define "placemarks" (a name, street, city etc) that can be associated with the references seen by this user at the time of definition. This is however beyond the scope of this XEP. </p>
</section2>

20
xep-0258.xml
View File

@ -16,8 +16,8 @@
<header>
<title>Security Labels in XMPP</title>
<abstract>This document describes the use of security labels in XMPP. The document specifies
how security label meta-data is carried in XMPP, when this meta-data should or should
not be provided, and how the meta-data is to be processed.</abstract> &LEGALNOTICE;
how security label metadata is carried in XMPP, when this metadata should or should
not be provided, and how the metadata is to be processed.</abstract> &LEGALNOTICE;
<number>0258</number>
<status>Draft</status>
<type>Standards Track</type>
@ -48,6 +48,12 @@
<email>Kurt.Zeilenga@Isode.COM</email>
<jid>Kurt.Zeilenga@Isode.COM</jid>
</author>
<revision>
<version>1.1.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>1.1</version>
<date>2013-04-08</date>
@ -167,7 +173,7 @@
standardized formats for security labels, clearances, and security policy are
generalized and do have application in non-government networks.</p>
<p>This document describes the use of security labels in &xmpp;. The document specifies how
security label meta-data is carried in XMPP. It standardizes a mechanism for carrying
security label metadata is carried in XMPP. It standardizes a mechanism for carrying
ESS Security Labels in XMPP, as well as provides for use of other label formats. ESS
Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in
conjunction with &X.500; clearances and either X.841 or &SDN.801c; security
@ -195,8 +201,8 @@
]]></example>
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
<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>The document details when security label metadata should or should not be provided, and
how this metadata is to be processed.</p>
<p>This document does not provide:</p>
<ul>
@ -248,7 +254,7 @@
</section1>
<section1 topic="Protocol" anchor="protocol">
<p>An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
includes a security label, zero or more equivalent security labels, and optionally
display marking data.</p>
<example caption="Labeled Message"><![CDATA[
@ -267,7 +273,7 @@
</securitylabel>
</message>
]]></example>
<p>The security label meta-data is carried in an &SECURITYLABEL; element. The
<p>The security label metadata is carried in an &SECURITYLABEL; element. The
&SECURITYLABEL; element which contains one and only one &LABEL; element, zero or more
&EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
<p>The &LABEL; provides the primary security label. It is commonly issued by the sender

8
xep-0272.xml
View File

@ -37,6 +37,12 @@
<email>dafydd.harries@collabora.co.uk</email>
<jid>dafydd.harries@collabora.co.uk</jid>
</author>
<revision>
<version>0.1.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2009-09-11</date>
@ -108,7 +114,7 @@
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
its own preparation by updating its presence with the contents it wants to
take part in.
</p>
<code><![CDATA[

8
xep-0274.xml
View File

@ -35,6 +35,12 @@
<supersededby/>
<shortname>N/A</shortname>
&kdz;
<revision>
<version>0.4.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2011-01-28</date>
@ -250,7 +256,7 @@
<section2 topic="XMPP E2E" anchor="xmpp-e2e">
<p>The &IETF; standardized a signing and encryption facility for XMPP known as &xmppe2e;. XMPP
E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the
Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an
Cryptographic Message Syntax (&CMS;). As its name implies, XMPP E2E is intended to be an
end-to-end solution. That is, it enables a sender to sign content sent to a specific
recipient.</p>
<p>An advantage of the XMPP E2E approach is that it uses an encapsulating signature which

8
xep-0293.xml
View File

@ -34,6 +34,12 @@
<email>olivier.crete@collabora.co.uk</email>
<jid>olivier.crete@collabora.co.uk</jid>
</author>
<revision>
<version>1.0.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>1.0</version>
<date>2015-08-11</date>
@ -217,7 +223,7 @@ milliseconds for this media session. It corresponds to the
<section1 topic='Mapping to Session Description Protocol' anchor='sdp-mapping'>
<p>The &lt;rtcp-fb/&gt; element maps to the a:rtcp-fb= SDP line with
the exception of the 'trr-int' parameter which is mapped into it's
the exception of the 'trr-int' parameter which is mapped into its
own element (&lt;rtcp-fb-trr-int/&gt;) in XMPP. The payload types
are also not explicitly written in the &lt;rtcp-fb/&gt; and
&lt;rtcp-fb-trr-int/&gt; elements. Instead, each payload type has its own

8
xep-0321.xml
View File

@ -35,6 +35,12 @@
<email>hanzz.k@gmail.com</email>
<jid>hanzz@njs.netlab.cz</jid>
</author>
<revision>
<version>0.1.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-04-16</date>
@ -175,7 +181,7 @@
</iq>]]></example>
</section2>
<section2 topic='The user updates roster' anchor='user_update'>
<p>If client updates roster and this update affects the remote entity&apos;s contacts (i.e. belongs to it's hostname) then the server MUST forward these items to the remote entity:</p>
<p>If client updates roster and this update affects the remote entity&apos;s contacts (i.e. belongs to its hostname) then the server MUST forward these items to the remote entity:</p>
<example caption='The user updates roster'><![CDATA[
<iq from='juliet@example.com/chamber' type='set' id='roster_3'>
<query xmlns='jabber:iq:roster'>

12
xep-0327.xml
View File

@ -34,6 +34,12 @@
<jid>jdecastro@tropo.com</jid>
<uri>http://tropo.com</uri>
</author>
<revision>
<version>0.8.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.8</version>
<date>2017-09-11</date>
@ -430,7 +436,7 @@
<p>Sessions may be established either at the request of the Rayo client (an outbound call) or as a result of a 3rd party request (an inbound call). Each scenario differs in the Rayo protocol only up to the point at which the session is established and media begins to flow. First we shall examine the sequence of stanzas passed between server and client in each of these scenarios.</p>
<section3 topic='Outbound Call' anchor='session-establishment-outbound'>
<p>In order for a client to establish a new outbound call, it MUST first send a <link url="#def-dial">dial command</link> to the server, indicating the proposed target for the call, its apparent source, and any meta-data to send to the target as headers.</p>
<p>In order for a client to establish a new outbound call, it MUST first send a <link url="#def-dial">dial command</link> to the server, indicating the proposed target for the call, its apparent source, and any metadata to send to the target as headers.</p>
<example caption="Client requests establishment of a new outbound session"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
@ -1778,7 +1784,7 @@
</li>
</ul>
<p>The server MUST present the recording for consumption by the client by way of recording meta-data on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration &amp; size data as specified on the <link url='#def-component-record-recording'>recording element</link>.</p>
<p>The server MUST present the recording for consumption by the client by way of recording metadata on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration &amp; size data as specified on the <link url='#def-component-record-recording'>recording element</link>.</p>
<example caption="Component indicates it has completed due to being stopped, providing the recording"><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28'
to='juliet@capulet.lit/courtyard'
@ -3620,7 +3626,7 @@ Art thou not Romeo, and a Montague?
<any minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation>
May be any component specific meta-data elements, such as <recording>.
May be any component specific metadata elements, such as <recording>.
</documentation>
</annotation>
</any>

8
xep-0342.xml
View File

@ -29,6 +29,12 @@
<jid>ben@langfeld.me</jid>
<uri>http://langfeld.me</uri>
</author>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2017-09-11</date>
@ -87,7 +93,7 @@
<section3 topic='Completion' anchor='session-receiving-completion'>
<p>The receivefax completion reason MUST be one of the <link url='#def-components-complete-reason'>core Rayo reasons</link> or <link url='#def-finish'>finish</link> (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received.</p>
<p>The server MUST present the fax for consumption by the client by way of fax meta-data on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size &amp; page count data as specified on the <link url='#def-fax'>fax element</link>. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.</p>
<p>The server MUST present the fax for consumption by the client by way of fax metadata on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size &amp; page count data as specified on the <link url='#def-fax'>fax element</link>. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.</p>
<example caption="Component indicates it has completed due to being finished, providing the fax"><![CDATA[
<presence from='9f00061@call.shakespeare.lit/eh3u28'
to='juliet@capulet.lit/courtyard'

14
xep-0347.xml
View File

@ -41,6 +41,12 @@
<jid>TBD</jid>
<uri>http://www-rnks.informatik.tu-cottbus.de/~rklauck</uri>
</author>
<revision>
<version>0.5.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2017-09-11</date>
@ -68,7 +74,7 @@
<initials>pw</initials>
<remark>
<p>
Added the possibility for <link url='#ownerupdate'>owners to update meta-data about its things</link>.
Added the possibility for <link url='#ownerupdate'>owners to update metadata about its things</link>.
This is done through the optional attribute <strong>jid</strong> on the <strong>update</strong> element.
</p>
<p>Added <strong>ROOM</strong> to the <link url='#tags'>list of predefined tag names</link>.</p>
@ -1134,7 +1140,7 @@
</section2>
<section2 topic='Owner updating Meta Information about Thing in Registry' anchor='ownerupdate'>
<p>
An owner of a thing can also update the meta-data of a thing it has claimed. To do this, you simply add a <strong>jid</strong> attribute containing the JID of the thing to the
An owner of a thing can also update the metadata of a thing it has claimed. To do this, you simply add a <strong>jid</strong> attribute containing the JID of the thing to the
<strong>update</strong> element. (If this attribute is not present, the JID is assumed to be that of the sender of the message.)
</p>
<example caption='Owner requests an update of Meta Data of Thing'>
@ -1157,7 +1163,7 @@
</iq>]]>
</example>
<p>
The owner can update meta-data of things behind concentrators also. To do this, the corresponding attributes <strong>nodeId</strong>, <strong>sourceId</strong>
The owner can update metadata of things behind concentrators also. To do this, the corresponding attributes <strong>nodeId</strong>, <strong>sourceId</strong>
and <strong>cacheType</strong> must be used to identify the thing, as follows:
</p>
<example caption='Owner requests an update of Meta Data of Thing behind concentrator'>
@ -1895,7 +1901,7 @@
<section2 topic='External services for creating QR-codes' anchor='externalqr'>
<p>
If using external services when creating QR-codes, like the Google Charts API used in this document, make sure HTTPS is used and certificates validated. If HTTP is used,
meta-data tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.
metadata tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.
</p>
</section2>
<section2 topic='DHCP Security Considerations' anchor='dhcpsec'>

8
xep-0355.xml
View File

@ -28,6 +28,12 @@
<email>goffi@goffi.org</email>
<jid>goffi@jabber.fr</jid>
</author>
<revision>
<version>0.4.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.4</version>
<date>2017-09-11</date>
@ -130,7 +136,7 @@
<p>Namespaces delegations are granted in the server configuration. Only &IQ; stanza namespaces can be delegated.</p>
<p>A feature is delegated using:</p>
<ol>
<li>it's namespace: e.g. <em>'urn:xmpp:mam:0'</em></li>
<li>its namespace: e.g. <em>'urn:xmpp:mam:0'</em></li>
<li>zero or more filtering attribute (attributes which must be present in the initial &IQ; child element): e.g. <em>'node'</em></li>
<li>the jid of the managing entity: e.g. <em>'managing.capulet.lit'</em></li>
</ol>

8
xep-0364.xml
View File

@ -25,6 +25,12 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&sam;
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2017-01-28</date>
@ -285,7 +291,7 @@
&rfc5122; defines a Uniform Resource Identifier (URI) and
Internationalized Resource Identifier (IRI) scheme for XMPP entities, and
&xep0147; defines various query components for use with XMPP URI's. When
an entity has an associated OTR fingerprint it's URI is often formed with
an entity has an associated OTR fingerprint its URI is often formed with
"otr-fingerprint" in the query string. Eg.
</p>
<example caption='OTR Fingerprint'><![CDATA[

10
xep-0379.xml
View File

@ -28,6 +28,12 @@
<email>georg@op-co.de</email>
<jid>georg@yax.im</jid>
</author>
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3.0</version>
<date>2018-10-01</date>
@ -165,7 +171,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
<ol>
<li><strong>XSF:</strong> a central place would provide a common ground
for a curated client list and ensure long-term availability. However,
the operator would be able to collect meta-data and abuse authentication tokens.</li>
the operator would be able to collect metadata and abuse authentication tokens.</li>
<li><strong>Client developer:</strong> the developer of Romeo's client can
provide a landing page for invitation requests created with this
client. This is a feasible short-term solution and allows to recommend
@ -175,7 +181,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
down, invitation links created with the client will cease working.</li>
<li><strong>User's server:</strong> this is the optimal long-term
solution, as the user's server is already entrusted with the relevant
meta-data and will exist at least as long as the user's account on that
metadata and will exist at least as long as the user's account on that
server. However, this requires an additional server component to query
for invitation URIs and a web server hosting the landing page.
Furthermore, the server operator needs to maintain the list of

8
xep-0384.xml
View File

@ -27,6 +27,12 @@
<email>andy@strb.org</email>
<jid>andy@strb.org</jid>
</author>
<revision>
<version>0.2.2</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2.1</version>
<date>2018-05-21</date>
@ -193,7 +199,7 @@
</pubsub>
</iq>]]></example>
<p>This step presents the risk of introducing a race condition: Two devices might simultaneously try to announce themselves, unaware of the other's existence. The second device would overwrite the first one. To mitigate this, devices MUST check that their own device ID is contained in the list whenever they receive a PEP update from their own account. If they have been removed, they MUST reannounce themselves.</p>
<p>Furthermore, a device MUST announce it's IdentityKey, a signed PreKey, and a list of PreKeys in a separate, per-device PEP node. The list SHOULD contain 100 PreKeys, but MUST contain no less than 20.</p>
<p>Furthermore, a device MUST announce its IdentityKey, a signed PreKey, and a list of PreKeys in a separate, per-device PEP node. The list SHOULD contain 100 PreKeys, but MUST contain no less than 20.</p>
<example caption='Announcing bundle information'><![CDATA[
<iq from='juliet@capulet.lit' type='set' id='announce2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>

8
xep-0403.xml
View File

@ -38,6 +38,12 @@
<shortname>MIX-PRESENCE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.3.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.3.0</version>
<date>2018-06-06</date>
@ -132,7 +138,7 @@
MIX channels store presence of each online client for a user that chooses to publish presence, in the format that is distributed as presence. Presence is stored in the presence node with an item for each client that is publishing presence. Each item is named with an encoded JID and contains the presence information that is distributed. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.
</p>
<p>
A client participating in a MUC channel MAY send it's presences status to the MIX channel using standard presence. The mechanisms to do this are summarized in the next section and standardized in &xep0405;.
A client participating in a MUC channel MAY send its presences status to the MIX channel using standard presence. The mechanisms to do this are summarized in the next section and standardized in &xep0405;.
</p>
<p>

8
xep-0405.xml
View File

@ -38,6 +38,12 @@
<shortname>MIX-PAM</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.2.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.2.0</version>
<date>2018-06-06</date>
@ -538,7 +544,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
]]></example>
<p>
Once a client has made an IQ request to return additional MIX information, the server MUST return this information on all subsequent roster updates that are sent by the server to the client. The server MUST NOT send additional MIX information when this has not been explicitly requested. It is anticipated that a client will fetch the roster after connection has been established and will set it's preference for this MIX capability information at that time.
Once a client has made an IQ request to return additional MIX information, the server MUST return this information on all subsequent roster updates that are sent by the server to the client. The server MUST NOT send additional MIX information when this has not been explicitly requested. It is anticipated that a client will fetch the roster after connection has been established and will set its preference for this MIX capability information at that time.
</p>
</section2>

8
xep-0407.xml
View File

@ -36,6 +36,12 @@
<shortname>MIX-MISC</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.1</version>
<date>2018-11-03</date>
<initials>pep</initials>
<remark>Fix a bunch of typos, batch-style.</remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2018-05-14</date>
@ -160,7 +166,7 @@
<section1 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and its retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[