moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 01:32:22 -05:00
Code Issues Releases Wiki Activity

xhtml fixes

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@590 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-16 05:20:39 +00:00
parent 01d8760976
commit fc8efac7b1
28 changed files with 131 additions and 196 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
xep-0031.xml
View File

@ -1505,7 +1505,6 @@ The key's identifier, convId, is assembled.
The payload, which consists of the confidentiality key and the integrity key, is wrapped
in instances of xenc:EncryptedKey as follows:
</p>
</li>
<ul>
<li>
<p>
@ -1537,6 +1536,7 @@ The xenc:CipherData element MUST be present, and it MUST use the CipherValue cho
</p>
</li>
</ul>
</li>
<li>
<p>
The HMAC is computed using SKi of the security session over the following values:
@ -1726,7 +1726,6 @@ this specification is '1.0'. The value of convId MUST correspond to an existing,
<p>
The actual message body is encoded into a character string corresponding to a Jabber message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:
</p>
</li>
<ul>
<li>
<p>
@ -1757,6 +1756,7 @@ The xenc:CipherData element MUST be present, and it MUST use the CipherValue cho
</p>
</li>
</ul>
</li>
<li>
<p>
Using the HMAC key indicated by the convId attribute, the HMAC is computed
@ -2101,12 +2101,12 @@ Support for Elliptic Curve Cryptography
<p>
Additional symmetric algorithms
</p>
</li>
<li>
<p>
Additional hash algorithms
</p>
</li>
</li>
</ul>
<p>

86
xep-0043.xml
View File

@ -64,36 +64,39 @@
<section2 topic='Elements'>
<ul>
<li>version - specify the version of the protocol that the client/server supports</li>
<li>database - specify the database/catalog has the following attributes:</li>
<ul>
<li>name - name of the database/catalog</li>
<li>sql - embed native SQL queries directly</li>
</ul>
<ul>
<li>table - the element scopes the children into the table. has the following attributes:</li>
<ul>
<li>name - name of the table</li>
<li>permission - what the user can do with the data</li>
<li>col - describes the column. has the following attributes</li>
<ul>
<li>name - name of the column</li>
<li>type - SQL99 datatype of the column</li>
<li>size - size of the datatype if required</li>
<li>op - comparison operator, used only if child of where element</li>
</ul>
<li>where - scopes col elements into a 'sql-like' where clause</li>
<ul>
<li>col - see above</li>
</ul>
</ul>
<li>proc - element scopes the children into a procedure has the following attributes:</li>
<ul>
<li>name - name of the sproc</li>
<li>permission - what the user can do with the data</li>
<li>col - see above</li>
<li>result - indicated return value by running the procedure (restricted to integer)</li>
</ul>
</ul>
<li>database - specify the database/catalog has the following attributes:
<ul>
<li>name - name of the database/catalog</li>
<li>sql - embed native SQL queries directly</li>
<li>table - the element scopes the children into the table. has the following attributes:
<ul>
<li>name - name of the table</li>
<li>permission - what the user can do with the data</li>
<li>col - describes the column. has the following attributes
<ul>
<li>name - name of the column</li>
<li>type - SQL99 datatype of the column</li>
<li>size - size of the datatype if required</li>
<li>op - comparison operator, used only if child of where element</li>
</ul>
</li>
<li>where - scopes col elements into a 'sql-like' where clause
<ul>
<li>col - see above</li>
</ul>
</li>
</ul>
</li>
<li>proc - element scopes the children into a procedure has the following attributes:
<ul>
<li>name - name of the sproc</li>
<li>permission - what the user can do with the data</li>
<li>col - see above</li>
<li>result - indicated return value by running the procedure (restricted to integer)</li>
</ul>
</li>
</ul>
</li>
</ul>
</section2>
<section2 topic='Data Types'>
@ -332,7 +335,7 @@
<p>Attributes only used in the &lt;col&gt; element within a
&lt;where&gt; element are the op (for operator) and conj for
(conjunction). The op is used for comparison operators such
as &lt;, &gt;, =, &lt;&gt;, &lt;=, &gt;=
as &lt;, &gt;, =, &lt;&gt;, &lt;=, &gt;=</p>
<ul>
<li>eq - equivalent =</li>
@ -343,16 +346,14 @@
<li>get - greater than or equivalent &gt;=</li>
<li>null - IS NULL (the column is null in the database sense of the word)</li>
</ul>
</p>
<p>The conjuction attribute is used to combined constraints in the where clause
<p>The conjuction attribute is used to combined constraints in the where clause</p>
<ul>
<li>not - to negate a result</li>
<li>or - logical OR ||</li>
<li>and - logical AND &amp;&amp;</li>
</ul>
</p>
<p><strong>Result</strong></p>
@ -696,8 +697,9 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<p>Three responses are possible from the server.</p>
<ol>
<li>It supports that version number and responds with:
<p><code>
<li>
<p>It supports that version number and responds with:</p>
<code>
&lt;iq id="000" type="result" from="db.host"&gt;
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
@ -705,20 +707,20 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/database&gt;
&lt;/iq&gt;
</code>
The type of 'result' indicates that the version request was
<p>The type of 'result' indicates that the version request was
successful and if the client is satisfied with the version number,
may continue with schema requests or whatever.</p></li>
<li>It does not support that version number and responds with:
<p><code>
<li><p>It does not support that version number and responds with:</p>
<code>
&lt;iq id="000" type="error" from="db.host"&gt;
&lt;database
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;/iq&gt;
</code>
The type of 'error' indicates a failure in conforming to the
<p>The type of 'error' indicates a failure in conforming to the
desired version number. The server may optionally send an
alternative option.
alternative option.</p>
<code>
&lt;iq id="000" type="error" from="db.host"&gt;
&lt;database
@ -726,7 +728,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;version&gt;0.2&lt;/version&gt;
&lt;/database&gt;
&lt;/iq&gt;
</code></p></li>
</code></li>
<li>If the server has no idea what the client is talking
about it should send the appropriate Jabber error code.</li>
</ol>

6
xep-0052.xml
View File

@ -329,9 +329,8 @@
<p>The "offset" attribute defines the range offset, in bytes. This attribute MAY be present if the containing &lt;file/&gt; has an action value of "get", otherwise it SHOULD NOT be present. If this attribute is not present, a value of 0 is implied. The value of this attribute MUST be an integer, MUST NOT be less than 0, and MUST be less than (size - length).</p>
</section2>
<section2 topic='Error Descriptions'>
<p>
There are three main error conditions in file transfer. Following are the
conditions, error codes and descriptions:
<p>There are three main error conditions in file transfer. Following are the
conditions, error codes and descriptions:</p>
<ul>
<li>
<em>Declining Transfer (403)</em>: During the meta-data negotiation
@ -357,7 +356,6 @@
sender. The &lt;error/&gt; CDATA is not important.
</li>
</ul>
</p>
</section2>
</section1>

2
xep-0065.xml
View File

@ -170,7 +170,7 @@
<li><p>Initiator and Target may begin using the bytestream.</p></li>
</ol>
</section2>
<section2 topic='Mediated Connection' anchor='narr-direct'>
<section2 topic='Mediated Connection' anchor='narr-mediated'>
<p>Mediated connection is slightly more complicated. In this situation, the StreamHost is not the Initiator but a Proxy, which means that the Initiator must discover the network address of the StreamHost before sending the initial IQ-set, must negotiate a connection with the StreamHost in the same way that the Target does, and must request that the StreamHost activate the bytestream before it can be used. The process for establishing bytestreams in this case is as follows:</p>
<ol>
<li><p>Optionally, Initiator discovers the network address of StreamHost in-band.</p></li>

12
xep-0079.xml
View File

@ -409,7 +409,7 @@
<p>The following actions are defined by this document.</p>
<section3 topic='alert' anchor='actions-def-alert'>
<p>The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element &lt;amp status='alert'/&gt;, which itself contains the &lt;rule/&gt; that triggered this action. In all other respects, this action behaves as "drop".</p>
<example caption='Alert Response'><code><![CDATA[
<example caption='Alert Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
@ -420,14 +420,14 @@
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>
]]></code></example>
]]></example>
</section3>
<section3 topic='drop' anchor='actions-def-drop'>
<p>The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.</p>
</section3>
<section3 topic='error' anchor='actions-def-error'>
<p>The "error" action triggers a reply &MESSAGE; stanza of type "error" to the sending entity. The &MESSAGE; stanza's &lt;error/&gt; child MUST contain a &lt;failed-rules xmlns='http://jabber.org/protocol/amp#errors'/&gt; error condition, which itself contains the rules that triggered this action.</p>
<example caption='Error Response'><code><![CDATA[
<example caption='Error Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
type='error'
@ -445,12 +445,12 @@
</failed-rules>
</error>
</message>
]]></code></example>
]]></example>
<p>Note that the error SHOULD be of type "modify", and the general error condition SHOULD be &lt;undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/&gt;.</p>
</section3>
<section3 topic='notify' anchor='actions-def-notify'>
<p>The "notify" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element &lt;amp status='notify'/&gt;, which itself contains the &lt;rule/&gt; that triggered this action. Unlike the other actions, this action does not override the default behavior for a server. Instead, the server then executes its default behavior after sending the notify.</p>
<example caption='Notify Response'><code><![CDATA[
<example caption='Notify Response'><![CDATA[
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
@ -461,7 +461,7 @@
<rule action='notify' condition='deliver' value='stored'/>
</amp>
</message>
]]></code></example>
]]></example>
</section3>
</section2>
<section2 topic='Description of Condition/Action Combinations' anchor='description'>

13
xep-0087.xml
View File

@ -293,10 +293,11 @@
</p>
<p>
Creating a profile is fairly simple. First, a name is chosen, the
complete name is formatted like:
complete name is formatted like:</p>
<code>
http://jabber.org/protocol/si/profile/profile-name
</code>
<p>
The complete name is what is presented in information discovery requests
in order to show that the profile is supported. It is also used for the
&lt;si&gt; profile attribute. Next, the information for the headers is
@ -321,7 +322,7 @@
streams must link the Stream Initiation to the stream. The id
attribute of the &lt;si&gt; node is intended to provide this link. It is
out of scope of this document to define how streams will make use of this
facility, but it does suggest some methods:
facility, but it does suggest some methods:</p>
<ul>
<li>
Transport the Stream Initiation id with the stream negotitation as a
@ -346,11 +347,10 @@
</code>
</li>
</ul>
</p>
</section2>
<section2 topic='&lt;si&gt; Explanation'>
<p>
The attributes and data of &lt;si&gt; are fairly simple:
The attributes and data of &lt;si&gt; are fairly simple:</p>
<ul>
<li>
<em>id</em> - An opaque identifier generated by the Sender.
@ -363,7 +363,7 @@
<em>profile</em> - The profile's fulle name, selected by Sender.
</li>
</ul>
The data of the node is a mixture of a feature negotiation for the stream
<p>The data of the node is a mixture of a feature negotiation for the stream
and the profiles headers.
</p>
<p>
@ -382,7 +382,7 @@
<section2 topic='Error Codes'>
<p>
There are two error codes that are used. Following are the conditions,
meanings and data:
meanings and data:</p>
<ul>
<li>
<em>Declining Transfer (403)</em>: During the Stream Initiation
@ -396,7 +396,6 @@
they send a 406 error. The &lt;error/&gt; CDATA is not important.
</li>
</ul>
</p>
</section2>
</section1>
<section1 topic='Security Considerations'>

10
xep-0096.xml
View File

@ -105,7 +105,7 @@
<ul>
<li>Enable seamless file transfer, including fall-back mechanisms as appropriate.</li>
<li>Ensure that the profile will work even when one or both parties are behind a firewall.</li>
<li>Define a full-featured set of metadata for file transfers, including the following:
<li><p>Define a full-featured set of metadata for file transfers, including the following:</p>
<ul>
<li>description</li>
<li>size</li>
@ -126,7 +126,7 @@
</p>
<p>
The root element is &lt;file&gt; and has four attributes. The attributes
are used only during the offer stage of stream initiation:
are used only during the offer stage of stream initiation:</p>
<ul>
<li><em>size</em> - The size, in bytes, of the data to be sent.</li>
<li><em>name</em> - The name of the file that the Sender wishes to send.</li>
@ -134,7 +134,7 @@
specified using the DateTime profile as described in &xep0082;.</li>
<li><em>hash</em> - The MD5 sum of the file contents.</li>
</ul>
The <em>size</em> and <em>name</em> attributes MUST be present in the
<p>The <em>size</em> and <em>name</em> attributes MUST be present in the
profile. The other attributes MAY be present.
</p>
<p>
@ -150,7 +150,7 @@
When &lt;range&gt; is sent in the offer, it should have no
attributes. This signifies that the
sender can do ranged transfers. When a Stream Initiation result is sent
with the &lt;range&gt; element, it uses these attributes:
with the &lt;range&gt; element, it uses these attributes:</p>
<ul>
<li>
<em>offset</em> - Specifies the position, in bytes, to start
@ -163,7 +163,7 @@
end.
</li>
</ul>
Both attributes are OPTIONAL on the &lt;range&gt; element. Sending no
<p>Both attributes are OPTIONAL on the &lt;range&gt; element. Sending no
attributes is synonymous with not sending the &lt;range&gt;
element. When no &lt;range&gt; element is sent in the
Stream Initiation result, the Sender MUST send the complete file starting at

22
xep-0100.xml
View File

@ -317,7 +317,7 @@
</section3>
<section3 topic='Alternate Flows' anchor='usecases-jabber-register-alt'>
<ol>
<li><p>User information not verified:
<li><p>User information not verified:</p>
<ol>
<li>
<p>Gateway returns &notacceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &xep0086;.)</p>
@ -339,7 +339,7 @@
</li>
<li><p>Use Case Ends unsuccessfully.</p></li>
</ol>
</p></li>
</li>
</ol>
</section3>
</section2>
@ -400,7 +400,7 @@
</section3>
<section3 topic='Alternate Flows' anchor='usecases-jabber-edit-alt'>
<ol>
<li><p>Edit unsuccessful:
<li><p>Edit unsuccessful:</p>
<ol>
<li>
<p>Gateway returns &notacceptable; error to Jabber User.</p>
@ -422,7 +422,7 @@
</li>
<li><p>Use Case Ends unsuccessfully.</p></li>
</ol>
</p></li>
</li>
</ol>
</section3>
</section2>
@ -533,7 +533,7 @@
</section3>
<section3 topic='Alternate Flows' anchor='usecases-jabber-login-alt'>
<ol>
<li><p>Login fails:
<li><p>Login fails:</p>
<ol>
<li>
<p>Gateway sends appropriate presence error to Jabber User (&notauthorized; if password is bad, &timeout; if Legacy Service is down, etc.).</p>
@ -549,7 +549,7 @@
</li>
<li><p>Use Case Ends unsuccessfully.</p></li>
</ol>
</p></li>
</li>
</ol>
</section3>
</section2>
@ -583,7 +583,7 @@
</section3>
<section3 topic='Alternate Flows' anchor='usecases-jabber-logout-alt'>
<ol>
<li><p>Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User:
<li><p>Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User:</p>
<ol>
<li>
<p>Gateway passes through directed unavailable presence to Legacy User.</p>
@ -595,7 +595,7 @@
</li>
<li><p>Use Case Ends.</p></li>
</ol>
</p></li>
</li>
</ol>
</section3>
</section2>
@ -793,7 +793,7 @@
</section3>
<section3 topic='Alternate Flows' anchor='usecases-legacy-add-alt'>
<ol>
<li><p>Jabber User denies subscription request:
<li><p>Jabber User denies subscription request:</p>
<ol>
<li>
<p>Jabber User sends presence stanza of type "unsubscribed" to Legacy User.</p>
@ -806,7 +806,7 @@
<li><p>Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.</p></li>
<li><p>Use Case Ends unsuccessfully.</p></li>
</ol>
</p></li>
</li>
</ol>
</section3>
</section2>
@ -877,7 +877,7 @@
</ol>
<p>Gateways and clients SHOULD implement at least one of these protocols; at a minimum, it is RECOMMENDED for gateways and clients to implement the 'jabber:iq:gateway' protocol.</p>
</section2>
<section2 topic='The jabber:iq:gateway Protocol' anchor='addressing-gateway'>
<section2 topic='The jabber:iq:gateway Protocol' anchor='addressing-iqgateway'>
<p>The 'jabber:iq:gateway' protocol performs two functions:</p>
<ol>
<li><p>It enables a client to determine the text for the "prompt" to show to a Jabber User when the user wants to add a legacy contact to the user's roster (e.g., "Please enter the AOL Screen Name of the person you would like to contact"), as well as the preferred name for the prompted item (e.g., "Screen Name"). To do so, the client sends an empty &lt;query/&gt; element and the gateway returns a &lt;prompt/&gt; element (the name for the prompted item) and optionally a &lt;desc/&gt; element (the text of the prompt itself).</p></li>

22
xep-0102.xml
View File

@ -285,7 +285,7 @@
<p> xmody means: x is divided by y and the remainder is returned </p>
<p>Suppose two nodes want to agree on a shared secret key to exchange information securely, they will exchange their public keys in order to encrypt that information. To this goal, the transport XMPP packet SHOULD include an extension of the form:</p>
<example caption="Key agreement Application">
<code><![CDATA[
<![CDATA[
<x xmlns="xmpp:sec">
<KeyAgreement length="1024">
<DHKeyValue>
@ -293,7 +293,7 @@
</DHKeyValue>
</KeyAgreement>
</x>
]]></code>
]]>
</example>
<p>In this extension, the only negotiable parameter is the key length that is passed in the length attribute of the &lt;KeyAgreement/&gt; tag. The length attribute is used to retrieve the DH parameter group and the associated prime and generator values. We are using DH groups derived from the Internet Key Exchange protocol (IKE) which is used by IPSec. A summary of these groups and the associated parameters are described later in this document.</p>
<section3 topic="Secure password registration">
@ -301,7 +301,7 @@
<p>The client uses an empty &lt;x/&gt; element in the request to signal that it supports the XMPP security extension.</p>
<p>The flow between client and server will look like:</p>
<example caption="Client requests register parameters">
<code><![CDATA[
<![CDATA[
<iq to="domain" type="get" id="req-0">
<x xmlns="jabber:iq:register">
<x xmlns="xmpp:sec">
@ -309,11 +309,11 @@
</x>
</query>
</iq>
]]></code>
]]>
</example>
<p>The server will reply to the request by sending out its own ephemeral public key inside the &lt;x/&gt; extension.</p>
<example caption="Server respond with register parameters">
<code><![CDATA[
<![CDATA[
<iq from="domain" type="result" id="req-0">
<x xmlns="jabber:iq:register">
<username/>
@ -327,12 +327,12 @@
</x>
</query>
</iq>
]]></code>
]]>
</example>
<p>The client then generate its own public key, calcultate the shared secret according to the DH method and uses it to encrypt the password accordingly. It includes its own ephemeral public key into the reply to the server inside the &lt;x/&gt; extension.</p>
<example caption="Client sends register parameters">
<code><![CDATA[
<![CDATA[
<iq to="domain" type="set" id="req-1">
<x xmlns="jabber:iq:register">
<username>username</username>
@ -346,15 +346,15 @@
</x>
</query>
</iq>
]]></code>
]]>
</example>
<p>The server now calculates the shared secret according to the DH method and uses its private key to decrypt the password.</p>
<example caption="Server acknowledge register">
<code><![CDATA[
<![CDATA[
<iq to="domain" type="result" id="req-1"/>
]]></code>
]]>
</example>
</section3>
</section2>
@ -1354,7 +1354,7 @@ The real body is protected.
<section1 topic="PKCS #3: Diffie-Hellman Key-Agreement Standard">
<p>An RSA Laboratories Technical Note
Version 1.4
Revised November 1, 1993<footnote label="*"><p>Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-19. PKCS documents are available by electronic mail to &lt;pkcs@rsa.com&gt;.</p></footnote></p>
Revised November 1, 1993<note>upersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-19. PKCS documents are available by electronic mail to &lt;pkcs@rsa.com&gt;.</note></p>
<section2 topic="Scope">
<p>This standard describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret key that is known only to them (and, in particular, is not known to an eavesdropper listening to the dialogue by which the parties agree on the key). This secret key can then be used, for example, to encrypt further communications between the parties.</p>
<p>The intended application of this standard is in protocols for establishing secure connections, such as those proposed for OSI's transport and network layers [ISO90a][ISO90b].</p>

2
xep-0117.xml
View File

@ -78,7 +78,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in <cite>XEP-0073</cite> by specifying an Intermediate IM Protocol Suite.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='intro'>
<section1 topic='Requirements and Approach' anchor='approach'>
<p>This document follows the same approach as <cite>XEP-0073</cite>. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.</p>
<p>A protocol is deemed worthy of inclusion in this protocol suite if:</p>
<ul>

6
xep-0126.xml
View File

@ -408,14 +408,14 @@
<p>In general it is probably easiest for users to become visible/invisible either globally or based on roster group, since these models are conceptually simple. Although, naturally, a client developer cannot tell users what to do, it probably best to encourage the use of conceptually simple models for privacy lists.</p>
<p>Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.</p>
</section1>
<section1 topic='Security Considerations' anchor='impl'>
<section1 topic='Security Considerations' anchor='security'>
<p>For security concerns related to privacy lists, refer to <cite>RFC 3921</cite>. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the <link url='#impl'>Implementation Notes</link> section of this document.</p>
<p>It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using &xep0012;, &xep0030;, &xep0090;, or &xep0092; and receive a reply, thus providing information that reveals the user's availability. In addition, <cite>Last Activity</cite> requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in &xep0022; or &xep0085;.</p>
</section1>
<section1 topic='IANA Considerations' anchor='impl'>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='impl'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this specification.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>

2
xep-0132.xml
View File

@ -29,7 +29,7 @@
<remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='schema'>
<section1 topic='Introduction' anchor='intro'>
<p>&xmppcore; and &xmppim; define methods for exchanging information about a person's network availability via the XML &lt;presence/&gt; stanza. In general, such presence information is generated only when a person initiates interaction with a client, although it can be generated programmatically through features such as auto-away. However, sometimes a user is present in the vicinity of a client but is not actively engaged with the client interface. In such circumstances, it would be helpful to have a mechanism that is sometimes referred to as &lt;presence type='probe-irl'/&gt;: the ability to invoke a real-life means of determining the physical presence of the user. This document defines just such a mechanism.</p>
</section1>
<section1 topic='Approach' anchor='approach'>

8
xep-0136.xml
View File

@ -238,7 +238,7 @@
<li><p>If administrator policies require that at least the &lt;body/&gt; elements (or the full content) of every message are logged automatically, and the client sets the value of the 'save' attribute to 'false' (or 'body').</p></li>
</ul>
</section2>
<section2 topic='Setting Modes for a Contact' anchor='pref-jid'>
<section2 topic='Setting Modes for a Contact' anchor='pref-contact'>
<p>A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID (&BAREJID;).</p>
<example caption='Client Sets Modes for a Contact'><![CDATA[
<iq type='set' id='pref3'>
@ -265,7 +265,7 @@
]]></example>
<p>The same error cases apply as when <link url='#auto'>Setting Default Modes</link>.</p>
</section2>
<section2 topic='Setting Archiving Method Preferences' anchor='pref-jid'>
<section2 topic='Setting Archiving Method Preferences' anchor='pref-archive'>
<example caption='Client Sets Method Preferences'><![CDATA[
<iq type='set' id='pref4'>
<pref xmlns='http://www.xmpp.org/extensions/xep-0136.html#ns'>
@ -475,7 +475,7 @@
</iq>
]]></example>
</section2>
<section2 topic='Offline Messages' anchor='impl-muc'>
<section2 topic='Offline Messages' anchor='impl-offline'>
<p>The client MAY specify an absolute time for any message by providing a longer 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in <cite>Jabber Date and Time Profiles</cite>) instead of a 'secs' attribute. The absolute time MAY be before the start time of the collection:</p>
<example caption='Storing offline messages in a collection'><![CDATA[
<iq type='set' id='up2'>
@ -708,7 +708,7 @@
]]></example>
<p>As soon as the server has finished archiving a collection, it MUST securely destroy all copies of the symmetric key it used to encrypt the messages. Note: If the security of the server is compromised, then only the collections being recorded during the attack will be revealed (i.e. only those messages that would have been compromised even if they had not been archived).</p>
</section2>
<section2 topic='Not-Implemented Responses' anchor='auto-crypt'>
<section2 topic='Not-Implemented Responses' anchor='auto-notimpl'>
<p>The server MUST return a &lt;feature-not-implemented/&gt; error in the following cases:</p>
<ul>
<li><p>If the client is trying to enable automatic archiving, but the server does not allow the saving of full message stanza content, and the user has specified the 'message' Save Mode in one of its <link url='#pref'>Archiving Preferences</link>.</p></li>

4
xep-0142.xml
View File

@ -897,10 +897,10 @@ Agent Service
<example caption='Invitation Meta-Data'><![CDATA[
<offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'>
]]></example>
<section4 topic='Error Conditions' anchor='proto-user-invite-errors'>
<section4 topic='Error Conditions' anchor='proto-agent-invite-errors'>
<p>There are no defined error conditions for agent invitations.</p>
</section4>
<section4 topic='Example' anchor='proto-user-invite-example'>
<section4 topic='Example' anchor='proto-agent-invite-example'>
<p>An invitation from the server on behalf of the support@example.net workgroup:</p>
<example caption='An Invitation'><![CDATA[
S: <message

2
xep-0153.xml
View File

@ -179,8 +179,8 @@
</presence>
]]></example>
<p>If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the &lt;photo/&gt; element.</p>
<p>Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).</p>
</li>
<p>Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).</p>
</ol>
</section2>
<section2 topic='Downloading and Uploading the vCard' anchor='bizrules-vcard'>

2
xep-0154.xml
View File

@ -788,7 +788,7 @@
</field>
]]></example>
</section3>
<section3 topic='Longitude' anchor='lat'>
<section3 topic='Longitude' anchor='lon'>
<p>Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.</p>
<p>The Data Forms field that represents longitude is "lon".</p>
<p>This field maps to:</p>

22
xep-0159.xml
View File

@ -107,14 +107,14 @@
]]></example>
</section1>
<section1 topic='SPIM Blocking' anchor='usage'>
<section1 topic='SPIM Blocking' anchor='spim'>
<p>This section specifies <em>server</em> functionality <em>not</em> defined in <cite>RFC 3921</cite>. This document will not reach Draft status until <cite>Server-Based Privacy Rules</cite> has been modified to permit this functionality.</p>
<section2 topic='Correspondents Lists' anchor='usage-correspondents'>
<section2 topic='Correspondents Lists' anchor='spim-correspondents'>
<p>A server that supports this protocol MAY maintain a separate <note>If the server were to maintain a single unified list of the correspondents of all its users, then SPIMers would only need to pass a single SPIM recognition test before being allowed to send SPIM to <em>all</em> the server's users.</note> list of each user's correspondents. Each list contains all the bare JIDs the user has either sent a stanza to or received a stanza from (over the past few weeks or months).</p>
<p>Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.</p>
<p>Note: The lists of correspondents have a very different function from rosters. Edits are initiated by the server not the client, allowing the lists to be completely transparent to clients.</p>
</section2>
<section2 topic='Fall-Through Procedure' anchor='usage-action'>
<section2 topic='Fall-Through Procedure' anchor='spim-action'>
<p>The server SHOULD perform the following procedures whenever it receives a stanza that falls through the active privacy list of the user it is addressed to without being either allowed or denied:</p>
<ol>
<li>If the server maintains correspondents lists, and if the bare JID in the 'from' attribute of the received stanza is on the addressed user's correspondents list, then the server SHOULD allow the stanza to be delivered to the user.</li>
@ -122,7 +122,7 @@
<li>Depending on the result of those procedures, it SHOULD then either allow, deny or delay the delivery of the stanza without informing the sender.</li>
</ol>
</section2>
<section2 topic='Delay Procedure' anchor='usage-action'>
<section2 topic='Delay Procedure' anchor='spim-delay'>
<p>When a SPIM recognition procedure delays delivery of a stanza the server SHOULD store it temporarily.</p>
<p>While delivery is being delayed:</p>
<ul>
@ -134,16 +134,16 @@
</section2>
</section1>
<section1 topic='Configuring Privacy Lists' anchor='usage'>
<section1 topic='Configuring Privacy Lists' anchor='privacy'>
<p>This informative section requires no client or server functionality beyond that defined in <cite>RFC 3921</cite>.</p>
<section2 topic='Exempting Trusted Groups from SPIM Blocking' anchor='usage-exempt'>
<section3 topic='Users on Roster' anchor='usage-exempt'>
<section2 topic='Exempting Trusted Groups from SPIM Blocking' anchor='privacy-exempt'>
<section3 topic='Users on Roster' anchor='privacy-exempt-users'>
<p>The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from SPIM blocking (see the items with order 20, 30 and 40 in the example below).</p>
</section3>
<section3 topic='Transports' anchor='usage-exempt'>
<section3 topic='Transports' anchor='privacy-exempt-transports'>
<p>At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive SPIM recognition techniques (like <cite>Robot Challenges</cite>). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).</p>
</section3>
<section3 topic='Users of Trusted Servers' anchor='usage-exempt'>
<section3 topic='Users of Trusted Servers' anchor='privacy-exempt-servers'>
<p>If a user believes SPIM will not be sent by users of a particular server (e.g. the user's own corporate server), then the client MAY use the 'jid' type to exclude all these users from SPIM blocking (see the item with order 60 in the example below).</p>
</section3>
<example caption='Exempting Users from SPIM Blocking'><![CDATA[
@ -190,7 +190,7 @@
</ul>
</section2>
<section2 topic='Explicitly Blocking SPIM' anchor='usage-block'>
<section2 topic='Explicitly Blocking SPIM' anchor='privacy-block'>
<p>If stanzas from a SPIM robot running on a zombie domain somehow manage to get past the server's SPIM recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (<cite>RFC 3921</cite> already enables this functionality.)</p>
<example caption='Blocking SPIM from a Specific Domain'><![CDATA[
<iq type='set' from='victim@mydomain.com/laptop'>
@ -208,7 +208,7 @@
]]></example>
</section2>
<section2 topic='Completely Disabling SPIM Blocking' anchor='usage-disable'>
<section2 topic='Completely Disabling SPIM Blocking' anchor='privacy-disable'>
<p>A client MAY disable server-side SPIM blocking by ensuring the default fall-through action is never applied. It does this simply by including an explicit fall-through item in its active privacy list.</p>
<example caption='Client Disables SPIM Blocking'><![CDATA[
<iq type='set' from='victim@mydomain.com/laptop'>

67
xep-0167.xml
View File

@ -158,73 +158,6 @@
]]></code>
<p>Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see &lt;<link url='http://www.iana.org/assignments/sdp-parameters'>http://www.iana.org/assignments/sdp-parameters</link>&gt;).</p>
</section1>
<section1 topic='Negotiating a Jingle-Audio Session' anchor='negotiating'>
<p>Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a receiver iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:</p>
<ul>
<li>If the receiver does not support the offered encoding, it MUST NOT include the encoding in its response.</li>
<li>If the receiver does support the offered encoding, it SHOULD include the encoding in the response, preserving the offered payload type.</li>
<li>If the receiver is unable to support the offered encoding with the offered payload type, it MAY provide an alternate payload type in its response. This typically will happen only when translating from other signalling protocols.</li>
<li>The receiver SHOULD preserve the order of the offered encodings, which represents the priority assigned to them by the initator.</li>
</ul>
<p>If, after applying these rules, the receiver determines it does not support any of the offering encodings, the receiver MUST reject the session by sending a &lt;unsupported-codecs/&gt; error in response to the initiator's "initiate" action. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the receiver MUST then propose the change in a "description-modify" action as defined in <cite>XEP-0166</cite>. If the description is identical, the receiver MUST send a "description-accept" action (either explicitly, or implicitly as part of a "session-accept" or "content-accept" action).</p>
<p>Following is an example of this negotiation:</p>
<example caption="Initiation Example"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingleaudio1' type='set'>
<jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
action='session-initiate'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://www.xmpp.org/extensions/xep-0167.html#ns'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='0' name='PCMU'/>
</description>
<transport xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns/transport/ice'>
...
</transport>
</content>
</jingle>
</iq>
]]></example>
<p>The receiver now follows the rules provided in this section and determines it can only support PCMU. It provisionally accepts the session:</p>
<example caption="Receiver Provisionally Accepts Session"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio1' type='result'/>
]]></example>
<p>It then offers the new content description in a 'description-modify' action:</p>
<example caption="Initiation Example"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio2' type='set'>
<jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
action='description-modify'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://www.xmpp.org/extensions/xep-0167.html#ns'>
<payload-type id='0' name='PCMU'/>
</description>
</content>
</jingle>
</iq>
]]></example>
<p>The initiator acknowledges the 'description-modify' with an empty IQ result, and sends a 'description-accept' to accept the new Jingle Audio content description.</p>
<example caption="Initiator Accepts New Content Description"><![CDATA[
<iq to='juliet@capulet.com/balcony' from='romeo@montegue.net/orchard' id='jingleaudio2' type='result'/>
<iq to='juliet@capulet.com/balcony' from='romeo@montegue.net/orchard' id='jingleaudio3' type='set'/>
<jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
action='description-accept' initiator='romeo@montague.net/orchard' sid='a73sjjvkla37jfea'>
<content name='audio'>
<description xmlns='http://www.xmpp.org/extensions/xep-0167.html#ns'>
<payload-type id='0' name='PCMU'/>
</description>
</content>
</jingle>
</iq>
]]></example>
<p>Finally, the target acknowledges the 'description-accept'.</p>
<example caption="Receiver Provisionally Accepts Session"><![CDATA[
<iq to='romeo@montague.net/orchard' from='juliet@capulet.com/balcony' id='jingleaudio3' type='result'/>
]]></example>
</section1>
<section1 topic='Negotiating a Jingle-Audio Session' anchor='negotiating'>
<p>Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a target entity iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:</p>
<ul>

2
xep-0168.xml
View File

@ -133,7 +133,7 @@
<li><p>A client MUST NOT generate a &lt;rap/&gt; element that has an 'app' attribute whose value is "messaging" or that has no 'app' attribute (since the default 'app' is "messaging").</p></li>
</ol>
</section1>
<section1 topic='Flagging the Primary Resource for a Given Application Type' anchor='primary'>
<section1 topic='Flagging the Primary Resource for a Given Application Type' anchor='flag'>
<p>The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her "desktop" resource only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile at all other times, and so on.</p>
<p>To flag the primary resource related to a specific application type, the server shall add a &lt;primary/&gt; child to the relevant RAP element. Here is an example:</p>
<example caption='Primary resource flag'><![CDATA[

8
xep-0176.xml
View File

@ -37,25 +37,25 @@
<version>0.5</version>
<date>2006-10-31</date>
<initials>psa</initials>
<remark><p><p>Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.</p></p></remark>
<remark><p>Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2006-09-13</date>
<initials>psa</initials>
<remark><p><p>Updated to track ICE-10; added section on service discovery.</p></p></remark>
<remark><p>Updated to track ICE-10; added section on service discovery.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2006-07-12</date>
<initials>se/psa</initials>
<remark><p><p>Specified that DTMF must use in-band signalling (XEP-0181).</p></p></remark>
<remark><p>Specified that DTMF must use in-band signalling (XEP-0181).</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2006-03-24</date>
<initials>psa</initials>
<remark><p><p>Recommended use of RTP-native methods for DTMF.</p></p></remark>
<remark><p>Recommended use of RTP-native methods for DTMF.</p></remark>
</revision>
<revision>
<version>0.1</version>

2
xep-0181.xml
View File

@ -97,7 +97,7 @@
]]></example>
<p>If the receiving entity does not understand or cannot process the payload, it MUST return an appropriate XMPP error (such as &unavailable; or &unexpected;).</p>
</section1>
<section1 topic='Negotiating RFC 4733' anchor='4733'>
<section1 topic='Negotiating RFC 4733' anchor='rfc4733'>
<p>Some applications may want to stream Jingle voice RTP directly to a non-XMPP entity, such as a SIP phone. In this scenario, DTMF needs to be sent in the content channel. Jingle DTMF enables Jingle entities to negotiate whether to send RTP over the XMPP signalling channel as described above, or over the content channel using &rfc4733;.</p>
<p>To request that the voice session switches to RFC 4733, a client sends a &lt;dtmf-method/&gt; element, qualified by the 'http://jabber.org/protocol/info/dmtf' namespace as the payload of a Jingle content-info message:</p>
<example caption="Client requests using RFC 4733"><![CDATA[

2
xep-0183.xml
View File

@ -134,7 +134,7 @@
</section1>
<section1 topic='XML Schemas' anchor='schema'>
<section2 topic='Transport Method' anchor='schema-info'>
<section2 topic='Transport Method' anchor='schema-transport'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

4
xep-0188.xml
View File

@ -203,13 +203,13 @@
<section3 topic='Flexibility' anchor='reqs-flexible'>
<p>The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.</p>
</section3>
<section3 topic='Interoperability' anchor='reqs-usable'>
<section3 topic='Interoperability' anchor='reqs-interop'>
<p>Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.</p>
</section3>
<section3 topic='Offline Sessions' anchor='reqs-offline'>
<p>Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.</p>
</section3>
<section3 topic='Object Encryption' anchor='reqs-offline'>
<section3 topic='Object Encryption' anchor='reqs-object'>
<p>For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".</p>
</section3>
</section2>

6
xep-0190.xml
View File

@ -59,11 +59,11 @@
<section1 topic='How to Close an Idle Stream' anchor='do'>
<section2 topic='Handshake Stream Shutdown'>
<p>As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending
<p>As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending</p>
<code><![CDATA[ </stream:stream> ]]></code>
then wait for the other entity to close its stream, like this:
<p>then wait for the other entity to close its stream, like this:</p>
<code><![CDATA[ </stream:stream> ]]></code>
and shut down the underlying TCP connection.</p>
<p>and shut down the underlying TCP connection.</p>
<p>This will ensure that, should the other entity have transmitted any data, it will arrive and be processed before the TCP connection is terminated.</p>
<p>Special care MUST be taken that under no circumstance further packets may be written to the socket after the stream was closed, until the other side shuts down the socket.</p>
<p>On the outgoing TCP connection, an implementation MAY do a read-only shutdown of the socket, as long as the other side will safely be able to send its stream termination token.</p>

2
xep-0198.xml
View File

@ -179,7 +179,7 @@
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>Upon approval of this XEP, the Jabber Registrar shall add 'http://jabber.org/features/ack' to its registry of stream features.</p>
</section2>
<section2 topic='Protocol Namespaces' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Upon approval of this XEP, the &REGISTRAR; shall add 'http://jabber.org/protocol/ack' to its registry of protocol namespaces.</p>
</section2>
</section1>

2
xep-0202.xml
View File

@ -105,7 +105,7 @@
<p>This protocol was designed in a way that makes migration from <cite>XEP-0090</cite> straightforward. This document specifies a different format for the XML character data of the &lt;utc&gt; element (compliant with <cite>XEP-0082</cite>) and specifies a new &lt;tzo&gt; element for the numeric offset from UTC, while removing the formerly optional and effectively useless &lt;display/&gt; and &lt;tz/&gt; elements.</p>
<p>Implementations that support <cite>XEP-0090</cite> should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in <cite>XEP-0090</cite> for backwards compatibility until the status of that specification is changed to Obsolete.</p>
</section1>
<section1 topic='Security Considerations' anchor='registrar'>
<section1 topic='Security Considerations' anchor='security'>
<p>Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

2
xep-0205.xml
View File

@ -78,7 +78,7 @@
<p>A server implementation SHOULD enable a server administrator to limit the number of connections that it will from a given IP address at any one time. <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note> The maximum number of connections per IP address is a matter of deployment policy, and no recommendations are provided herein.</p>
<p>If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.</p>
</section2>
<section2 topic='Connection Attempts' anchor='rec-connections'>
<section2 topic='Connection Attempts' anchor='rec-attempts'>
<p>A server implementation SHOULD enable a server administrator to limit the number of connection attempts that it will from a given IP address in a given time period (e.g., one hour). <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note> It is RECOMMENDED for a deployment to set the maximum number of connection attempts per IP address to 120 per hour.</p>
<p>If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.</p>
</section2>

3
xep.xsl
View File

@ -712,7 +712,10 @@
<xsl:template match='img'>
<img>
<xsl:attribute name='alt'><xsl:value-of select='@alt'/></xsl:attribute>
<xsl:attribute name='height'><xsl:value-of select='@height'/></xsl:attribute>
<xsl:attribute name='src'><xsl:value-of select='@src'/></xsl:attribute>
<xsl:attribute name='width'><xsl:value-of select='@width'/></xsl:attribute>
</img>
</xsl:template>