mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
Fix some it's/its typos
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
Maxime “pep” Buquet
parent
1496bd3a01
commit
d1c1a358e8
@ -268,7 +268,7 @@
|
||||
<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 <file/> with an action of start and the correct id. The <file/> 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 <file/> is transported along side the <query/>. The id used on the <file/> is the id for the meta-data of the actual data that is being sent. The action on the <file/> 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 meta-data, a <file/> is transported along side the <query/>. The id used on the <file/> is the id for the meta-data of the actual data that is being sent. The action on the <file/> is "start". An example of this can be found in the Basic Usage section.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Formal Description'>
|
||||
|
||||
@ -76,7 +76,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>
|
||||
|
||||
@ -183,7 +183,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'>
|
||||
|
||||
@ -32,7 +32,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
|
||||
|
||||
@ -44,7 +44,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>
|
||||
|
||||
10
xep-0109.xml
10
xep-0109.xml
@ -91,7 +91,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 +141,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 +183,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 +204,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 +226,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>
|
||||
|
||||
@ -927,7 +927,7 @@ S: </message>
|
||||
<li>Use the <identity> type='workgroup'.</li>
|
||||
<li>Use the <feature> 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 <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> 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 <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> tags are again presented to identify them as workgroups along with (optional) associated meta-data.</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'/>
|
||||
|
||||
@ -658,7 +658,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 ¬allowed; error with a pubsub-specific error condition of <max-nodes-exceeded/>.</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 ¬allowed; error with a pubsub-specific error condition of <max-nodes-exceeded/>.</p>
|
||||
|
||||
<example caption='Node would contain too many children'><![CDATA[
|
||||
<iq type='error'
|
||||
@ -796,7 +796,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 ¬allowed; error with a pubsub-specific error condition of <max-nodes-exceeded/>.</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 ¬allowed; error with a pubsub-specific error condition of <max-nodes-exceeded/>.</p>
|
||||
|
||||
<example caption='Node would contain too many children'><![CDATA[
|
||||
<iq type='error'
|
||||
|
||||
@ -708,7 +708,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>
|
||||
|
||||
|
||||
@ -108,7 +108,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[
|
||||
|
||||
@ -250,7 +250,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
|
||||
|
||||
@ -217,7 +217,7 @@ milliseconds for this media session. It corresponds to the
|
||||
|
||||
<section1 topic='Mapping to Session Description Protocol' anchor='sdp-mapping'>
|
||||
<p>The <rtcp-fb/> 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 (<rtcp-fb-trr-int/>) in XMPP. The payload types
|
||||
are also not explicitly written in the <rtcp-fb/> and
|
||||
<rtcp-fb-trr-int/> elements. Instead, each payload type has its own
|
||||
|
||||
@ -175,7 +175,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'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'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'>
|
||||
|
||||
@ -130,7 +130,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>
|
||||
|
||||
@ -285,7 +285,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[
|
||||
|
||||
@ -193,7 +193,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'>
|
||||
|
||||
@ -132,7 +132,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>
|
||||
|
||||
@ -538,7 +538,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>
|
||||
|
||||
|
||||
@ -160,7 +160,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 <retract> element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The <retract> 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 <retract> element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The <retract> 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[
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user