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

Spelling/grammar change

Browse Source 
* issueing -> issuing
* was -> were (subjunctive mood)
* Add commas around subordinate clause "per XMPP Core"
* Make "for example to increase the privacy" a parenthetical, remove word "the".
* "ordering of children in disco#info... elements does, however, not matter" -> "elements, however, does not matter"
This commit is contained in:
Brian Cully 2017-03-17 10:36:12 -04:00 committed by Sam Whited
parent 1a4e2844ac
commit aadd04dc43
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
inbox/ecaps2.xml
View File

@ -729,7 +729,7 @@ cDp0aW1lHxw=</code>
</ul>
<section3 topic='Caching' anchor='rules-processing-caching'>
<p>A &hash; MAY be stored alongside with its disco#info in a &hashcache;. A received &hash; which has not been verified MUST NOT be stored.</p>
<p>Instead of issueing a &xep0030; disco#info &lt;query/&gt; with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the &lt;query/&gt; would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.</p>
<p>Instead of issuing a &xep0030; disco#info &lt;query/&gt; with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the &lt;query/&gt; would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.</p>
<p>An entity MUST NOT use &hashes; which were not included in the most recent &hashset; received from the target entity.</p>
<p>An entity MAY use external data sources to fill the &hashcache;.</p>
</section3>
@ -738,7 +738,7 @@ cDp0aW1lHxw=</code>
<section2 topic='Additional Rules for Clients and Servers implementing Caps Optimizations' anchor='rules-optimize'>
<ul>
<li>Servers MAY strip off the &lt;c/&gt; element if it has not changed since the previous presence broadcast.</li>
<li>Servers MUST ensure that the first presence notification sent to each subscriber contains the most recent &lt;c/&gt; element, if any was sent in the current presence session.</li>
<li>Servers MUST ensure that the first presence notification sent to each subscriber contains the most recent &lt;c/&gt; element, if any were sent in the current presence session.</li>
<li>Servers MUST ensure that every change in the &lt;c/&gt; element is sent to all subscribers.</li>
<li>Clients MAY omit the &lt;c/&gt; element if it has not changed since the last presence <em>iff</em> they determined that their server supports Caps Optimization.</li>
<li>Servers MAY answer disco#info requests for &hashnodes; on behalf of their and others clients if the disco#info response belonging to that &hash; is known to them.</li>
@ -758,7 +758,7 @@ cDp0aW1lHxw=</code>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Hash Function Input Data Separators' anchor='security-separators'>
<p>The codepoints used for separating the different parts in the <link url='#algorithm-input'>Hash Function Input Algortihm</link> (&sepl4; through &sepl1;) are not allowed in well-formed XML character data. As entities are per &xmppcore; required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.</p>
<p>The codepoints used for separating the different parts in the <link url='#algorithm-input'>Hash Function Input Algortihm</link> (&sepl4; through &sepl1;) are not allowed in well-formed XML character data. As entities are, per &xmppcore;, required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.</p>
</section2>
<section2 topic='Caching' anchor='security-caching'>
@ -768,7 +768,7 @@ cDp0aW1lHxw=</code>
</section2>
<section2 topic='Directed Presence' anchor='security-directed-presence'>
<p>Entities MAY choose to not send &hashsets; with directed presence for example to increase the privacy. In that case, entities SHOULD also refuse direct &xep0030; queries.</p>
<p>Entities MAY choose to not send &hashsets; with directed presence (for example to increase privacy). In that case, entities SHOULD also refuse direct &xep0030; queries.</p>
</section2>
</section1>
@ -778,7 +778,7 @@ cDp0aW1lHxw=</code>
<p>A common way to canonicalize XML which could be used is &w3canon;. It was decided not to use <cite>Canonical XML</cite> for the following reasons:</p>
<ul>
<li>Implementing it is quite some effort and not all XML libraries come with an implementation.</li>
<li>It is sensitive to the relative ordering of the elements. The relative ordering of children in disco#info &lt;query/&gt; elements does, however, not matter.</li>
<li>It is sensitive to the relative ordering of the elements. The relative ordering of children in disco#info &lt;query/&gt; elements, however, does not matter.</li>
<li>Several children of &xep0128; data forms are deliberately ignored, like instructions and other descriptive text. The descriptive text is not relevant for the information is being conveyed.</li>
</ul>
<p>Thus, using <cite>Canonical XML</cite> would require additional, non-trivial software support and still require non-trivial additional canonicalization rules.</p>