aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEmmanuel Gil Peyrot <linkmauve@linkmauve.fr>2017-02-14 22:10:01 +0000
committerSam Whited <sam@samwhited.com>2017-02-16 19:37:21 -0600
commit3c5f20a4ca6ea51d63c3e3ec1fe0797ffc5fdbf6 (patch)
treebdb1becc8d8aa3b1cec2da124b517199fd2f66bc
parent856c7427d638fe13204dacfcd96abfa74603f221 (diff)
Remove all trailing whitespace from every XEP.
sed -i 's/\s\+$//' xep-*.xml
-rw-r--r--xep-0001.xml40
-rw-r--r--xep-0004.xml16
-rw-r--r--xep-0007.xml2
-rw-r--r--xep-0009.xml58
-rw-r--r--xep-0012.xml24
-rw-r--r--xep-0013.xml32
-rw-r--r--xep-0018.xml2
-rw-r--r--xep-0019.xml2
-rw-r--r--xep-0021.xml14
-rw-r--r--xep-0024.xml96
-rw-r--r--xep-0025.xml6
-rw-r--r--xep-0026.xml16
-rw-r--r--xep-0029.xml22
-rw-r--r--xep-0030.xml26
-rw-r--r--xep-0031.xml532
-rw-r--r--xep-0032.xml14
-rw-r--r--xep-0033.xml32
-rw-r--r--xep-0034.xml4
-rw-r--r--xep-0035.xml2
-rw-r--r--xep-0036.xml2
-rw-r--r--xep-0037.xml80
-rw-r--r--xep-0040.xml32
-rw-r--r--xep-0042.xml122
-rw-r--r--xep-0043.xml332
-rw-r--r--xep-0046.xml2
-rw-r--r--xep-0047.xml10
-rw-r--r--xep-0048.xml12
-rw-r--r--xep-0049.xml2
-rw-r--r--xep-0051.xml8
-rw-r--r--xep-0052.xml26
-rw-r--r--xep-0054.xml200
-rw-r--r--xep-0056.xml10
-rw-r--r--xep-0057.xml8
-rw-r--r--xep-0058.xml2
-rw-r--r--xep-0061.xml14
-rw-r--r--xep-0063.xml10
-rw-r--r--xep-0064.xml6
-rw-r--r--xep-0065.xml12
-rw-r--r--xep-0066.xml6
-rw-r--r--xep-0067.xml10
-rw-r--r--xep-0068.xml28
-rw-r--r--xep-0070.xml44
-rw-r--r--xep-0071.xml70
-rw-r--r--xep-0072.xml82
-rw-r--r--xep-0073.xml6
-rw-r--r--xep-0074.xml16
-rw-r--r--xep-0075.xml18
-rw-r--r--xep-0076.xml10
-rw-r--r--xep-0077.xml4
-rw-r--r--xep-0078.xml12
-rw-r--r--xep-0079.xml8
-rw-r--r--xep-0080.xml16
-rw-r--r--xep-0081.xml18
-rw-r--r--xep-0084.xml6
-rw-r--r--xep-0085.xml46
-rw-r--r--xep-0086.xml2
-rw-r--r--xep-0087.xml42
-rw-r--r--xep-0088.xml6
-rw-r--r--xep-0090.xml2
-rw-r--r--xep-0091.xml2
-rw-r--r--xep-0093.xml2
-rw-r--r--xep-0095.xml12
-rw-r--r--xep-0096.xml22
-rw-r--r--xep-0097.xml4
-rw-r--r--xep-0098.xml88
-rw-r--r--xep-0099.xml122
-rw-r--r--xep-0102.xml228
-rw-r--r--xep-0103.xml2
-rw-r--r--xep-0104.xml6
-rw-r--r--xep-0105.xml16
-rw-r--r--xep-0107.xml4
-rw-r--r--xep-0108.xml10
-rw-r--r--xep-0109.xml26
-rw-r--r--xep-0111.xml36
-rw-r--r--xep-0112.xml6
-rw-r--r--xep-0113.xml44
-rw-r--r--xep-0114.xml4
-rw-r--r--xep-0115.xml28
-rw-r--r--xep-0117.xml2
-rw-r--r--xep-0119.xml4
-rw-r--r--xep-0120.xml2
-rw-r--r--xep-0122.xml44
-rw-r--r--xep-0124.xml4
-rw-r--r--xep-0127.xml38
-rw-r--r--xep-0129.xml6
-rw-r--r--xep-0130.xml22
-rw-r--r--xep-0131.xml4
-rw-r--r--xep-0132.xml26
-rw-r--r--xep-0133.xml226
-rw-r--r--xep-0134.xml2
-rw-r--r--xep-0135.xml80
-rw-r--r--xep-0136.xml8
-rw-r--r--xep-0139.xml10
-rw-r--r--xep-0140.xml6
-rw-r--r--xep-0141.xml42
-rw-r--r--xep-0142.xml8
-rw-r--r--xep-0143.xml12
-rw-r--r--xep-0144.xml22
-rw-r--r--xep-0145.xml2
-rw-r--r--xep-0146.xml182
-rw-r--r--xep-0147.xml6
-rw-r--r--xep-0148.xml8
-rw-r--r--xep-0149.xml12
-rw-r--r--xep-0150.xml32
-rw-r--r--xep-0151.xml54
-rw-r--r--xep-0152.xml10
-rw-r--r--xep-0153.xml10
-rw-r--r--xep-0154.xml10
-rw-r--r--xep-0160.xml2
-rw-r--r--xep-0161.xml10
-rw-r--r--xep-0162.xml12
-rw-r--r--xep-0163.xml10
-rw-r--r--xep-0164.xml8
-rw-r--r--xep-0165.xml4
-rw-r--r--xep-0166.xml20
-rw-r--r--xep-0167.xml42
-rw-r--r--xep-0168.xml32
-rw-r--r--xep-0169.xml110
-rw-r--r--xep-0172.xml14
-rw-r--r--xep-0174.xml138
-rw-r--r--xep-0175.xml18
-rw-r--r--xep-0176.xml18
-rw-r--r--xep-0177.xml2
-rw-r--r--xep-0178.xml90
-rw-r--r--xep-0179.xml14
-rw-r--r--xep-0181.xml6
-rw-r--r--xep-0182.xml2
-rw-r--r--xep-0183.xml12
-rw-r--r--xep-0185.xml40
-rw-r--r--xep-0192.xml2
-rw-r--r--xep-0193.xml2
-rw-r--r--xep-0199.xml10
-rw-r--r--xep-0202.xml2
-rw-r--r--xep-0204.xml416
-rw-r--r--xep-0205.xml4
-rw-r--r--xep-0206.xml8
-rw-r--r--xep-0209.xml2
-rw-r--r--xep-0211.xml4
-rw-r--r--xep-0212.xml4
-rw-r--r--xep-0213.xml4
-rw-r--r--xep-0214.xml8
-rw-r--r--xep-0215.xml22
-rw-r--r--xep-0216.xml4
-rw-r--r--xep-0219.xml60
-rw-r--r--xep-0221.xml2
-rw-r--r--xep-0224.xml4
-rw-r--r--xep-0225.xml4
-rw-r--r--xep-0227.xml16
-rw-r--r--xep-0229.xml2
-rw-r--r--xep-0230.xml8
-rw-r--r--xep-0231.xml8
-rw-r--r--xep-0232.xml2
-rw-r--r--xep-0234.xml36
-rw-r--r--xep-0237.xml2
-rw-r--r--xep-0238.xml12
-rw-r--r--xep-0240.xml2
-rw-r--r--xep-0241.xml4
-rw-r--r--xep-0242.xml4
-rw-r--r--xep-0243.xml4
-rw-r--r--xep-0244.xml56
-rw-r--r--xep-0245.xml4
-rw-r--r--xep-0246.xml12
-rw-r--r--xep-0247.xml28
-rw-r--r--xep-0249.xml4
-rw-r--r--xep-0251.xml2
-rw-r--r--xep-0253.xml14
-rw-r--r--xep-0254.xml12
-rw-r--r--xep-0255.xml154
-rw-r--r--xep-0259.xml4
-rw-r--r--xep-0260.xml26
-rw-r--r--xep-0261.xml24
-rw-r--r--xep-0262.xml4
-rw-r--r--xep-0263.xml2
-rw-r--r--xep-0264.xml2
-rw-r--r--xep-0267.xml10
-rw-r--r--xep-0268.xml2
-rw-r--r--xep-0269.xml6
-rw-r--r--xep-0270.xml4
-rw-r--r--xep-0271.xml2
-rw-r--r--xep-0272.xml4
-rw-r--r--xep-0273.xml36
-rw-r--r--xep-0275.xml4
-rw-r--r--xep-0277.xml8
-rw-r--r--xep-0278.xml20
-rw-r--r--xep-0281.xml10
-rw-r--r--xep-0282.xml108
-rw-r--r--xep-0283.xml146
-rw-r--r--xep-0284.xml44
-rw-r--r--xep-0285.xml10
-rw-r--r--xep-0290.xml8
-rw-r--r--xep-0292.xml84
-rw-r--r--xep-0293.xml14
-rw-r--r--xep-0294.xml12
-rw-r--r--xep-0297.xml4
-rw-r--r--xep-0301.xml42
-rw-r--r--xep-0302.xml4
-rw-r--r--xep-0304.xml24
-rw-r--r--xep-0305.xml2
-rw-r--r--xep-0306.xml2
-rw-r--r--xep-0307.xml4
-rw-r--r--xep-0309.xml2
-rw-r--r--xep-0311.xml2
-rw-r--r--xep-0312.xml4
-rw-r--r--xep-0313.xml4
-rw-r--r--xep-0314.xml8
-rw-r--r--xep-0315.xml2
-rw-r--r--xep-0316.xml12
-rw-r--r--xep-0317.xml12
-rw-r--r--xep-0318.xml4
-rw-r--r--xep-0320.xml4
-rw-r--r--xep-0323.xml126
-rw-r--r--xep-0324.xml200
-rw-r--r--xep-0325.xml114
-rw-r--r--xep-0326.xml664
-rw-r--r--xep-0328.xml2
-rw-r--r--xep-0331.xml18
-rw-r--r--xep-0333.xml42
-rw-r--r--xep-0336.xml78
-rw-r--r--xep-0337.xml16
-rw-r--r--xep-0338.xml4
-rw-r--r--xep-0339.xml8
-rw-r--r--xep-0340.xml80
-rw-r--r--xep-0343.xml2
-rw-r--r--xep-0344.xml130
-rw-r--r--xep-0347.xml74
-rw-r--r--xep-0348.xml2
-rw-r--r--xep-0350.xml16
-rw-r--r--xep-0355.xml4
-rw-r--r--xep-0356.xml4
-rw-r--r--xep-0357.xml78
-rw-r--r--xep-0358.xml18
-rw-r--r--xep-0361.xml26
-rw-r--r--xep-0362.xml8
-rw-r--r--xep-0363.xml6
-rw-r--r--xep-0365.xml36
-rw-r--r--xep-0369.xml136
-rw-r--r--xep-0370.xml6
-rw-r--r--xep-0371.xml22
-rw-r--r--xep-0375.xml2
239 files changed, 4021 insertions, 4021 deletions
diff --git a/xep-0001.xml b/xep-0001.xml
index 0495050..62de3a3 100644
--- a/xep-0001.xml
+++ b/xep-0001.xml
@@ -211,7 +211,7 @@
<ol start='1'>
<li>To produce practical, technically excellent solutions to important problems of real-time communication based on the set of streaming XML technologies known as XMPP.</li>
<li>To document XMPP extensions in a clear, concise manner so that the task of implementing the protocols is straightforward.</li>
- <li>To ensure interoperability among the disparate technologies used on XMPP networks.</li>
+ <li>To ensure interoperability among the disparate technologies used on XMPP networks.</li>
<li>To guarantee that any person or entity can implement the protocols without encumbrance.</li>
<li>To work in an fair, open, objective manner.</li>
</ol>
@@ -350,8 +350,8 @@ Experimental ----> Proposed ----> Active
|
+--> Obsolete
</code>
- <p>Because such XEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the XMPP Council. However, some of these XEPs may be remanded from the Council to the XEP author and/or XMPP Extensions Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track XEPs, the XEP author may retract such a XEP when it is Experimental, and the Council may reject such a XEP when it is Proposed.</p>
- <p>Once approved, Historical, Informational, and Procedural XEPs will have a status of Active. Such a XEP may be replaced by a new XEP on the same or a similar topic, thus rendering the earlier XEP out of date; in such cases, the earlier XEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding XEP.</p>
+ <p>Because such XEPs do not seek to define standard protocols, in general they are less controversial and tend to proceed from Proposed to Active without controversy on a vote of the XMPP Council. However, some of these XEPs may be remanded from the Council to the XEP author and/or XMPP Extensions Editor for revision in order to be suitable for advancement from Proposed to Active (e.g., documentation of protocols in use must be accurate and describe any existing security concerns). As with Standards Track XEPs, the XEP author may retract such a XEP when it is Experimental, and the Council may reject such a XEP when it is Proposed.</p>
+ <p>Once approved, Historical, Informational, and Procedural XEPs will have a status of Active. Such a XEP may be replaced by a new XEP on the same or a similar topic, thus rendering the earlier XEP out of date; in such cases, the earlier XEP shall be assigned a status of Deprecated (and eventually Obsolete) with a note specifying the superseding XEP.</p>
<p>The XMPP Council may, at its discretion, decide to convert an Historical XEP into a Standards Track XEP if the protocol defined in the XEP has been in long use, is deemed stable and uncontroversial, and is unlikely to be superseded by a newer protocol. The Historical XEP shall be treated in the same way as a Standards Track XEP that has a status of Experimental, beginning with the <link url="#proposal">Proposal Process</link>. If after the Last Call and voting by the XMPP Council the XEP is approved for advancement on the standards track, its type shall be changed to Standards Track and its status shall be changed to Draft.</p>
</section2>
</section1>
@@ -370,7 +370,7 @@ Experimental ----> Proposed ----> Active
</section2>
<section2 topic='Final' anchor='states-Final'>
<p>A Standards Track XEP is in the Final state after it has been in the Draft state for at least six (6) months, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council.</p>
- <p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
+ <p><em>Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.</em></p>
</section2>
<section2 topic='Active' anchor='states-Active'>
<p>A XEP of any type other than Standards Track is advanced to a status of Active after it has been voted forward from Experimental by the XMPP Council.</p>
@@ -453,10 +453,10 @@ THE SOFTWARE.
<xs:annotation>
<xs:documentation>
- This schema defines the document format for XMPP Extension
+ This schema defines the document format for XMPP Extension
Protocols (XEPs). For further information about XEPs, visit:
- http://www.xmpp.org/extensions/
+ http://www.xmpp.org/extensions/
The canonical URL for this schema is:
@@ -481,20 +481,20 @@ THE SOFTWARE.
<xs:element name='number' type='xs:byte'/>
<xs:element ref='status'/>
<xs:element name='lastcall' minOccurs='0' type='xs:string'/>
- <xs:element name='interim' minOccurs='0' type='empty'/>
- <xs:element ref='type'/>
+ <xs:element name='interim' minOccurs='0' type='empty'/>
+ <xs:element ref='type'/>
<xs:element name='sig' type='xs:string'/>
<xs:element name='approver' type='xs:string'/>
<xs:element ref='dependencies'/>
<xs:element ref='supersedes'/>
<xs:element ref='supersededby'/>
<xs:element name='shortname' type='xs:NCName'/>
- <xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
- <xs:element name='registry' minOccurs='0' type='empty'/>
+ <xs:element ref='schemaloc' minOccurs='0' maxOccurs='unbounded'/>
+ <xs:element name='registry' minOccurs='0' type='empty'/>
<xs:element name='discuss' minOccurs='0' type='xs:string'/>
<xs:element name='expires' minOccurs='0' type='xs:string'/>
- <xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
- <xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
+ <xs:element ref='author' minOccurs='1' maxOccurs='unbounded'/>
+ <xs:element ref='revision' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
@@ -744,7 +744,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
- <xs:attribute name='source' use='required'/>
+ <xs:attribute name='source' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@@ -754,7 +754,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='url' use='required'/>
+ <xs:attribute name='url' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@@ -766,7 +766,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='caption' use='optional'/>
+ <xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@@ -776,7 +776,7 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='caption' use='optional'/>
+ <xs:attribute name='caption' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@@ -804,8 +804,8 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='colspan' use='optional'/>
- <xs:attribute name='rowspan' use='optional'/>
+ <xs:attribute name='colspan' use='optional'/>
+ <xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
@@ -815,8 +815,8 @@ THE SOFTWARE.
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='colspan' use='optional'/>
- <xs:attribute name='rowspan' use='optional'/>
+ <xs:attribute name='colspan' use='optional'/>
+ <xs:attribute name='rowspan' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
diff --git a/xep-0004.xml b/xep-0004.xml
index 0cd4379..a884ae4 100644
--- a/xep-0004.xml
+++ b/xep-0004.xml
@@ -317,7 +317,7 @@
type='get'
xml:lang='en'
id='create1'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='create'
action='execute'/>
</iq>
@@ -481,7 +481,7 @@
type='get'
xml:lang='en'
id='search1'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='search'
action='execute'/>
</iq>
@@ -492,7 +492,7 @@
type='result'
xml:lang='en'
id='search1'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='search'
status='executing'>
<x xmlns='jabber:x:data' type='form'>
@@ -512,7 +512,7 @@
type='get'
xml:lang='en'
id='search2'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='search'>
<x xmlns='jabber:x:data' type='submit'>
<field type='text-single' var='search_request'>
@@ -528,7 +528,7 @@
type='result'
xml:lang='en'
id='search2'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='search'
status='completed'>
<x xmlns='jabber:x:data' type='result'>
@@ -642,9 +642,9 @@
<xs:element name='x'>
<xs:complexType>
<xs:sequence>
- <xs:element name='instructions'
- minOccurs='0'
- maxOccurs='unbounded'
+ <xs:element name='instructions'
+ minOccurs='0'
+ maxOccurs='unbounded'
type='xs:string'/>
<xs:element name='title' minOccurs='0' type='xs:string'/>
<xs:element ref='field' minOccurs='0' maxOccurs='unbounded'/>
diff --git a/xep-0007.xml b/xep-0007.xml
index b23b109..876fe0b 100644
--- a/xep-0007.xml
+++ b/xep-0007.xml
@@ -70,7 +70,7 @@
<li>The "groupchat" protocol has no way of performing feature negotiation (e.g., specifying the additional protocol elements needed to participate in a room, or optionally allowed from participants within a room). If there were participants with clients sending custom data through the room (such as XHTML or whiteboarding), you would receive that information even without your client being able to support it, and have no way of distinguishing altered behavior due to additional features of a "groupchat" implementation.</li>
</ul>
<p>This new conferencing protocol will be designed to solve these problems.</p>
- <p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p>
+ <p>Because of the prevalence of the existing "groupchat" specification for multi-user chats, a long conversion process is anticipated. A server implementation which supports both protocols will simply not allow "groupchat"-only clients to participate in rooms with required features.</p>
</section1>
<section1 topic='Continuing Development'>
<p>As listed above, there is a fairly large number of features that could be developed on top of a well-designed framework. The Conferencing SIG will first be established to develop a framework, with features mainly being compared against the framework for feasibility of implementation. After a proposal has been formalized as a specification, the SIG will become a group for discussing and proposing new features, and for formally specifying those features.</p>
diff --git a/xep-0009.xml b/xep-0009.xml
index ce12e55..f956e8e 100644
--- a/xep-0009.xml
+++ b/xep-0009.xml
@@ -5,7 +5,7 @@
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
-<header>
+<header>
<title>Jabber-RPC</title>
<abstract>This specification defines an XMPP protocol extension for transporting XML-RPC encoded requests and responses between two XMPP entities. The protocol supports all syntax and semantics of XML-RPC except that it uses XMPP instead of HTTP as the underlying transport.</abstract>
&LEGALNOTICE;
@@ -74,9 +74,9 @@
</section1>
<section1 topic='Examples'>
<example caption='A typical request'><![CDATA[
-<iq type='set'
- from='requester@company-b.com/jrpc-client'
- to='responder@company-a.com/jrpc-server'
+<iq type='set'
+ from='requester@company-b.com/jrpc-client'
+ to='responder@company-a.com/jrpc-server'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodCall>
@@ -91,9 +91,9 @@
</iq>
]]></example>
<example caption='A typical response'><![CDATA[
-<iq type='result'
- from='responder@company-a.com/jrpc-server'
- to='requester@company-b.com/jrpc-client'
+<iq type='result'
+ from='responder@company-a.com/jrpc-server'
+ to='requester@company-b.com/jrpc-client'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodResponse>
@@ -108,9 +108,9 @@
]]></example>
<p>If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:</p>
<example caption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[
-<iq type='error'
- from='responder@company-a.com/jrpc-server'
- to='requester@company-b.com/jrpc-client'
+<iq type='error'
+ from='responder@company-a.com/jrpc-server'
+ to='requester@company-b.com/jrpc-client'
id='rpc1'>
<query xmlns='jabber:iq:rpc'>
<methodCall>
@@ -131,17 +131,17 @@
<section1 topic='Service Discovery' anchor='disco'>
<p>If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":</p>
<example caption='A disco#info query'><![CDATA[
-<iq type='get'
- from='requester@company-b.com/jrpc-client'
- to='responder@company-a.com/jrpc-server'
+<iq type='get'
+ from='requester@company-b.com/jrpc-client'
+ to='responder@company-a.com/jrpc-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
-<iq type='result'
- to='requester@company-b.com/jrpc-client'
- from='responder@company-a.com/jrpc-server'
+<iq type='result'
+ to='requester@company-b.com/jrpc-client'
+ from='responder@company-a.com/jrpc-server'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='rpc'/>
@@ -179,9 +179,9 @@
The protocol documented by this schema is defined in
XEP-0009: http://www.xmpp.org/extensions/xep-0009.html
- There is no official XML schema for XML-RPC. The main body
- of this schema has been borrowed from an unofficial schema
- representation contained in the book "Processing XML With
+ There is no official XML schema for XML-RPC. The main body
+ of this schema has been borrowed from an unofficial schema
+ representation contained in the book "Processing XML With
Java" by Elliotte Rusty Harold, as located at:
http://www.ibiblio.org/xml/books/xmljava/chapters/ch02s05.html
@@ -210,13 +210,13 @@
<xs:element name="params" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
- <xs:element name="param" type="ParamType"
+ <xs:element name="param" type="ParamType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
- </xs:complexType>
+ </xs:complexType>
</xs:element>
<xs:element name="methodResponse">
@@ -236,13 +236,13 @@
<xs:element name="value">
<xs:complexType>
<xs:sequence>
- <xs:element name="struct">
- <xs:complexType>
- <xs:sequence>
- <xs:element name="member"
+ <xs:element name="struct">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="member"
type="MemberType">
</xs:element>
- <xs:element name="member"
+ <xs:element name="member"
type="MemberType">
</xs:element>
</xs:sequence>
@@ -255,7 +255,7 @@
</xs:complexType>
</xs:element>
</xs:choice>
- </xs:complexType>
+ </xs:complexType>
</xs:element>
<xs:complexType name="ParamType">
@@ -286,7 +286,7 @@
<xs:complexType name="StructType">
<xs:sequence>
- <xs:element name="member" type="MemberType"
+ <xs:element name="member" type="MemberType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
@@ -303,7 +303,7 @@
<xs:element name="data">
<xs:complexType>
<xs:sequence>
- <xs:element name="value" type="ValueType"
+ <xs:element name="value" type="ValueType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
diff --git a/xep-0012.xml b/xep-0012.xml
index c45c106..71a110a 100644
--- a/xep-0012.xml
+++ b/xep-0012.xml
@@ -81,7 +81,7 @@
<section1 topic='Protocol' anchor='protocol'>
<p>In order to request last activity information regarding another entity, the requesting entity sends an &IQ; stanza of type "get" to the target entity, containing a &QUERY; element qualified by the 'jabber:iq:last' namespace:</p>
<example caption='Last Activity Query'><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
id='last1'
to='juliet@capulet.com'
type='get'>
@@ -90,7 +90,7 @@
]]></example>
<p>The target entity MUST return either an IQ-result or an IQ-error. When returning an IQ-result, the target entity sends an &IQ; stanza of type='result' containing a &QUERY; element with a REQUIRED 'seconds' attribute and OPTIONAL XML character data.</p>
<example caption='Last Activity Response'><![CDATA[
-<iq from='juliet@capulet.com'
+<iq from='juliet@capulet.com'
id='last1'
to='romeo@montague.net/orchard'
type='result'>
@@ -108,7 +108,7 @@
<section1 topic='Offline User Query' anchor='offline'>
<p>The primary usage of the 'jabber:iq:last' namespace is to find out how long ago a user logged out (and, additionally, what their status message was at that time). This primary usage assumes that the IQ-get is sent to a bare JID &LOCALBARE;. When used in this way, the &QUERY; element contained in the IQ-result has a 'seconds' attribute, which is the number of seconds that have passed since the user last logged out. In addition, the element MAY contain XML character data that specifies the status message of the last unavailable presence received from the user. An example is shown below:</p>
<example caption='Last Activity Query'><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
id='last1'
to='juliet@capulet.com'
type='get'>
@@ -118,9 +118,9 @@
<p>As specified in &xmppcore; and &xmppim;, an IQ stanza of type "get" sent to a bare JID &LOCALBARE; is handled by the user's server on the user's behalf, not delivered to one or more connected or available resources.</p>
<p>If the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP-IM</cite>), the user's server MUST NOT return last activity information but instead MUST return a &forbidden; error in response to the last activity request.</p>
<example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
-<iq from='juliet@capulet.com'
+<iq from='juliet@capulet.com'
id='last1'
- to='romeo@montague.net/orchard'
+ to='romeo@montague.net/orchard'
type='error'>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -152,7 +152,7 @@
<p>In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user.</p>
<p>In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP IM</cite>), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a &forbidden; error in response to the last activity request.</p>
<example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
-<iq from='juliet@capulet.com'
+<iq from='juliet@capulet.com'
id='last1'
to='romeo@montague.net/orchard'
type='error'>
@@ -163,9 +163,9 @@
]]></example>
<p>If the user's server delivers the IQ-get to one of the user's available resources, the user's client MAY respond with the idle time of the user (i.e., the last time that a human user interacted with the client application).</p>
<example caption='Last Activity Response by Client'><![CDATA[
-<iq from='juliet@capulet.com/balcony'
+<iq from='juliet@capulet.com/balcony'
id='last2'
- to='romeo@montague.net/orchard'
+ to='romeo@montague.net/orchard'
type='result'>
<query xmlns='jabber:iq:last' seconds='123'/>
</iq>
@@ -173,7 +173,7 @@
<p>In the foregoing example, the user has been idle for about two minutes.</p>
<p>Support for this functionality is OPTIONAL. A client that does not support the protocol, or that does not wish to divulge this information, MUST return a &unavailable; error.</p>
<example caption='Service Unavailable Error'><![CDATA[
-<iq from='juliet@capulet.com/balcony'
+<iq from='juliet@capulet.com/balcony'
id='last2'
to='romeo@montague.net/orchard'
type='error'>
@@ -187,15 +187,15 @@
<section1 topic='Server and Component Query' anchor='server'>
<p>When the last activity query is sent to a server or component (i.e., to a JID of the form &DOMAINBARE;), the information contained in the IQ reply reflects the uptime of the JID sending the reply. The seconds attribute specifies how long the host has been running since it was last (re-)started. The &QUERY; element SHOULD NOT contain XML character data.</p>
<example caption='Last Activity Query Sent to Server or Service'><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
id='last3'
- to='capulet.com'
+ to='capulet.com'
type='get'>
<query xmlns='jabber:iq:last'/>
</iq>
]]></example>
<example caption='Last Activity Response from Server or Service'><![CDATA[
-<iq from='capulet.com'
+<iq from='capulet.com'
id='last3'
to='romeo@montague.net/orchard'
type='result'>
diff --git a/xep-0013.xml b/xep-0013.xml
index c2a238e..9aa0efa 100644
--- a/xep-0013.xml
+++ b/xep-0013.xml
@@ -122,12 +122,12 @@
<p>In order to discover whether one's server supports this protocol, one uses &xep0030;.</p>
<example caption='User Requests Service Discovery Information'><![CDATA[
<iq type='get' to='montague.net'>
- <query xmlns='http://jabber.org/protocol/disco#info'/>
+ <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='Server Reply to Discovery Request'><![CDATA[
-<iq type='result'
- from='montague.net'
+<iq type='result'
+ from='montague.net'
to='romeo@montague.net/orchard'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jabber.org/protocol/offline'/>
@@ -141,7 +141,7 @@
<p>In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline':</p>
<example caption='User Requests Information About Offline Message Node'><![CDATA[
<iq type='get'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/offline'/>
</iq>
]]></example>
@@ -171,32 +171,32 @@
<p>In order to retrieve headers for all of the messages in the queue, the user sends a disco#items request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as 'http://jabber.org/protocol/offline'.</p>
<example caption='User Requests Offline Message Headers'><![CDATA[
<iq type='get'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'/>
</iq>
]]></example>
<p>The server now MUST return headers for all of the user's offline messages. So that the user may determine whether to view a full message, the header information provided MUST include the full Jabber ID of the sender (encoded in the 'name' attribute) and a unique identifier for the message within the user's "inbox" (encoded in the 'node' attribute), so that the user may appropriately manage (view or remove) the message.</p>
<example caption='Server Provides Offline Message Headers'><![CDATA[
<iq type='result' to='romeo@montague.net/orchard'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/offline'>
- <item
+ <item
jid='romeo@montague.net'
node='2003-02-27T22:49:17.008Z'
name='mercutio@shakespeare.lit/pda'/>
- <item
+ <item
jid='romeo@montague.net'
node='2003-02-27T22:52:37.225Z'
name='juliet@capulet.com/balcony'/>
- <item
+ <item
jid='romeo@montague.net'
node='2003-02-27T22:52:51.270Z'
name='juliet@capulet.com/balcony'/>
- <item
+ <item
jid='romeo@montague.net'
node='2003-02-27T22:53:03.421Z'
name='juliet@capulet.com/balcony'/>
- <item
+ <item
jid='romeo@montague.net'
node='2003-02-27T22:53:13.925Z'
name='juliet@capulet.com/balcony'/>
@@ -298,7 +298,7 @@ S: <stream:stream ...>
C: authentication (SASL in XMPP, non-SASL in older systems)
-S: acknowledge successful authentication
+S: acknowledge successful authentication
C: <presence/>
@@ -315,7 +315,7 @@ S: <stream:stream ...>
C: authentication (SASL in XMPP, non-SASL in older systems)
-S: acknowledge successful authentication
+S: acknowledge successful authentication
C: request message headers
@@ -325,7 +325,7 @@ NOTE: Server now MUST NOT flood Client with offline messages.
C: <presence/>
-NOTE: Server does not flood Client with offline messages, but
+NOTE: Server does not flood Client with offline messages, but
sends in-session messages as usual.
C: request and remove offline messages, send and receive messages, etc.
@@ -363,7 +363,7 @@ C: request and remove offline messages, send and receive messages, etc.
<type>
<name>message-list</name>
<desc>
- The node for the offline message queue; valid only for the node
+ The node for the offline message queue; valid only for the node
"http://jabber.org/protocol/offline"
</desc>
<doc>XEP-0013</doc>
@@ -371,7 +371,7 @@ C: request and remove offline messages, send and receive messages, etc.
<type>
<name>message-node</name>
<desc>
- A node for a specific offline message if service discovery is
+ A node for a specific offline message if service discovery is
provided for messages
</desc>
<doc>XEP-0013</doc>
diff --git a/xep-0018.xml b/xep-0018.xml
index bac72bf..ea09018 100644
--- a/xep-0018.xml
+++ b/xep-0018.xml
@@ -119,7 +119,7 @@
<example caption="Server forwards presence update to stpeter@foo.com and rynok@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="stpeter@foo.com">
<show>chat</show>
</presence>
-
+
<presence from="joe@foo.com/resource" to="rynok@foo.com/resource">
<show>chat</show>
</presence>]]></example>
diff --git a/xep-0019.xml b/xep-0019.xml
index 7a3e0cd..9652cc2 100644
--- a/xep-0019.xml
+++ b/xep-0019.xml
@@ -52,7 +52,7 @@
<ol>
<li>"Crack the whip" -- encourage and cajole the existing SIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
<li>"Wait and see" -- immediately disband the SIGs that are clearly inactive but keep the existing SIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).</li>
- <li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.</li>
+ <li>"Bite the bullet" -- recognize that, for whatever reason, the existing structure (many special-purpose interest groups) is not working and seek a better way to produce enhancements to XMPP.</li>
</ol>
<p>Given the lack of activity in the SIGs so far (and the lack of time available to those who would manage them), I am skeptical that "cracking the whip" will produce results, and I believe the onus of proof is on those who would argue that the existing SIGs can be successful. Similarly, taking a "wait and see" attitude will simply let a bad situation continue unchecked, and in my opinion will at some point require us to choose between option 1 and option 3. Rather than postpone the day of reckoning, I argue that we need to address the problem head-on and take action to streamline the SIGs and find a better way of working.</p>
<p>But what is that "better way"? In order to figure that out, we need to understand why things are not working now. I don't think it's that the current SIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good XMPP-based software. Nor do I think it's that members of the XMPP community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.</p>
diff --git a/xep-0021.xml b/xep-0021.xml
index 0e68980..8e8d6f7 100644
--- a/xep-0021.xml
+++ b/xep-0021.xml
@@ -48,14 +48,14 @@
<li>User's avatar has changed</li>
<li>The coffee machine is empty</li>
</ul>
-
+
<p>In Jabber, the role of the ENS has traditionally been filled by overloading the &lt;presence/&gt; packet type. However, this method was never designed to be used as a general publish-and-subscribe mechanism, and so has the following problems:</p>
<ul>
<li>Dispatching of &lt;presence/&gt; packets is performed by the JSM (Jabber Session Manager), and so is not easily usable by components and other entities that don't connect via a client manager (c2s, CCM).</li>
<li>An entity cannot subscribe to the presence of a specific resource of another entity, only to any presence from that entity. This lack of granularity makes its difficult to use &lt;presence/&gt; in situations where large chunks of data must be dispatched to subscribers (eg avatars).</li>
</ul>
-
+
<p>The protocol consists of two parts - the subscriber-to-ENS protocol, and the publisher-to-ENS protocol. Since there is no direct interaction between a publisher and a subscriber, it makes sense to seperate the two parts of the protocol.</p>
<p>The protocol operates in the 'http://xml.cataclysm.cx/jabber/ens/' namespace.</p>
@@ -187,7 +187,7 @@
</example>
<p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
-
+
<example caption='Event notification (publish) with payload'>
&lt;iq id='enspub2' type='set' from='ens-jid' to='subscriber-jid'&gt;
&lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='event-jid'&gt;
@@ -225,7 +225,7 @@
</example>
<p>A notification may also contain a (application-specific) &quot;payload&quot; XML fragment:</p>
-
+
<example caption='Event notification (publish) with payload'>
&lt;iq id='pub1' type='set' from='event-jid' to='ens-jid'&gt;
&lt;publish xmlns='http://xml.cataclysm.cx/jabber/ens/'&gt;
@@ -257,7 +257,7 @@
</example>
<p>The subscriber may include an &lt;auth-info/&gt; XML fragment containing some (application-specific) information that the publisher can use to authorise it:</p>
-
+
<example caption='Authorisation request with authorisation information'>
&lt;iq id='ensauth1' type='get' from='ens-jid' to='event-jid'&gt;
&lt;authorise xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'&gt;
@@ -270,7 +270,7 @@
<section2 topic='Authorisation response'>
<p>To signal to the ENS that a subscriber should be allowed to subscribe, the publisher should return a packet of the following form:</p>
-
+
<example caption='Successful authorisation response'>
&lt;iq id='ensauth1' type='result' from='event-jid' to='ens-jid'&gt;
&lt;authorised xmlns='http://xml.cataclysm.cx/jabber/ens/' jid='subscriber-jid'/&gt;
@@ -310,7 +310,7 @@
<li>Have some sort of ENS-to-ENS protocol, and have ENSs proxy publishes for other ENSs. This does not fix the problem, it just moves it away from the subscriber and into the ENS. An ENS will still need to find out which ENS the publisher is publishing to.</li>
<li>Integrate ENS into the session manager. This leaves us with a glorified presence system, and makes the ENS basically unusable by non-session-manager-based server components.</li>
</ul>
-
+
<p>This problem may be outside of the scope of this specification.</p>
</section2>
diff --git a/xep-0024.xml b/xep-0024.xml
index 0b653d2..3e4e81b 100644
--- a/xep-0024.xml
+++ b/xep-0024.xml
@@ -7,7 +7,7 @@
<xep>
<header>
<title>Publish/Subscribe</title>
- <abstract>A publish-subscribe protocol for Jabber.</abstract>
+ <abstract>A publish-subscribe protocol for Jabber.</abstract>
&PUBLICDOMAINNOTICE;
<number>0024</number>
<status>Retracted</status>
@@ -64,7 +64,7 @@ two separate but related goals:
<p>
The specification details the use of the Jabber protocol elements and
-introduces a new namespace, jabber:iq:pubsub.
+introduces a new namespace, jabber:iq:pubsub.
It also includes notes on actual implementation of such a
mechanism in Jabber.
</p>
@@ -78,7 +78,7 @@ It's clear that as Jabber is deployed over a wider spectrum of platforms
and circumstances, more and more information will be exchanged. Whether
that information is specific to Jabber (JSM) users, or components, we need
an mechanism to be able to manage the exchange of this information in an
-efficient way.
+efficient way.
</p>
<p>
@@ -301,7 +301,7 @@ You can also send an unsubscribe without specifying any namespaces:
</p>
<example caption='Publisher-specific general unsubscription'>
-SEND: &lt;iq type='set' to='pubsub.localhost'
+SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe to='publisher'/&gt;
@@ -392,7 +392,7 @@ Likewise, you can unsubscribe from certain namespaces in this non-publisher-spec
</p>
<example caption='General unsubscription to specific namespaces'>
-SEND: &lt;iq type='set' to='pubsub.localhost'
+SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe&gt;
@@ -402,7 +402,7 @@ SEND: &lt;iq type='set' to='pubsub.localhost'
&lt;/query&gt;
&lt;/iq&gt;
-RECV: &lt;iq type='result' from='pubsub.localhost'
+RECV: &lt;iq type='result' from='pubsub.localhost'
to='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe&gt;
@@ -424,14 +424,14 @@ Finally, a subscriber can wipe the slate clean like this:
</p>
<example caption='Wiping the slate'>
-SEND: &lt;iq type='set' to='pubsub.localhost'
+SEND: &lt;iq type='set' to='pubsub.localhost'
from='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe/&gt;
&lt;/query&gt;
&lt;/iq&gt;
-RECV: &lt;iq type='result' from='pubsub.localhost'
+RECV: &lt;iq type='result' from='pubsub.localhost'
to='subscriber.localhost' id='s1'&gt;
&lt;query xmlns='jabber:iq:pubsub'&gt;
&lt;unsubscribe/&gt;
@@ -644,7 +644,7 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
<!--
<p>
-Optionally, a pubsub component may respond with an empty IQ-result, to
+Optionally, a pubsub component may respond with an empty IQ-result, to
reduce traffic:
</p>
@@ -657,13 +657,13 @@ RECV: &lt;iq type='result' from='pubsub.localhost'
<p>
Each published item is wrapped in a &lt;publish/&gt; tag. This tag
-must contain the namespace of the item being publishes, in an ns
+must contain the namespace of the item being publishes, in an ns
attribute, as shown. This is distinct from the xmlns attribute of
the fragment of XML actually being published. It is theoretically
none of the pubsub component's business to go poking around in the
real published data, nor should it have to. It needs to know what
-namespace is qualifying the published information that has been
-received, so that the list of appropriate recipients can be
+namespace is qualifying the published information that has been
+received, so that the list of appropriate recipients can be
determined.
</p>
@@ -674,7 +674,7 @@ determined.
<p>
While it's the responsibility of the publishing entities to publish
information, it's the responsibility of the pubsub
-component to push out that published data to the subscribers. The
+component to push out that published data to the subscribers. The
list of recipient subscribers must be determined by the information
stored by the pubsub component as a result of receiving subscription
requests (which are described earlier).
@@ -694,7 +694,7 @@ fragments of published data.</note>
<p>
Taking the earlier example of the publishing of data in the 'foo'
namespace, the following example shows what the pubsub component
-must send to push this foo data out to a subscriber.
+must send to push this foo data out to a subscriber.
</p>
<example caption='Pushing out published information to a subscriber'>
SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
@@ -707,7 +707,7 @@ SEND: &lt;iq type='set' to='subscriber@localhost/foosink'
&lt;/iq&gt;
</example>
<p>
-The recipient is _not_ required to send an 'acknowledgement' in the
+The recipient is _not_ required to send an 'acknowledgement' in the
form of an IQ-result; the idea that this _push_ of information is
akin to how information is pushed in a live browsing context (see
jabber:iq:browse documentation for more details).
@@ -720,7 +720,7 @@ jabber:iq:browse documentation for more details).
<p>
When a pubsub service receives a publish packet like the ones above, it
needs to deliver (push) the information out according to the subscriptions
-that have been made.
+that have been made.
</p>
<p>
@@ -729,7 +729,7 @@ subscription between the pubsub service and the subscriber(s). If the
subscriber wishes only to receive information when he's online (this is
a JSM-specific issue), then he needs to set up a presence subscription
relationship with the pubsub service. The pubsub service should respond
-to presence subscriptions and unsubscriptions by
+to presence subscriptions and unsubscriptions by
</p>
<ul>
@@ -740,16 +740,16 @@ to presence subscriptions and unsubscriptions by
<p>
If the pubsub service deems that a published piece of information should
be pushed to a subscriber, and there is a presence subscription relationship
-with that subscriber, the service should only push that information to the
+with that subscriber, the service should only push that information to the
subscriber if he is available. If he is not available, the information is not
-to be sent.
+to be sent.
</p>
<p>
Thus the subscriber can control the sensitivity by initiating (or not) a
presence relationship with the service. If the subscriber wishes to receive
information regardless of availability, he should not initiate a (or cancel
-any previous) presence relationship with the service.
+any previous) presence relationship with the service.
</p>
<p>
@@ -762,7 +762,7 @@ publish/subscribe where presence is not a given.
<section2 topic='Use of Resources'>
<p>
-When in receipt of a pubsub subscription request from an entity
+When in receipt of a pubsub subscription request from an entity
where a resource is specified in the JID, the pubsub component must
honour the resource specified in the from attribute of the request.
For example, here's a typical subscription request from a JSM user:
@@ -780,7 +780,7 @@ RECV: &lt;iq type='set' to='pubsub.localhost'
</example>
<p>
When storing the subscriber/publisher/namespace relationship matrix for
-eventual querying when a publisher publishes some information, the
+eventual querying when a publisher publishes some information, the
pubsub component must use the full JID, not just the username@host part.
</p>
<p>
@@ -802,7 +802,7 @@ the full JID of the component subscriber - news.server/politics-listener,
should be used to qualify the matrix.
</p>
<p>
-This is because it allows the subscribing entities to arrange the
+This is because it allows the subscribing entities to arrange the
receipt of pushed items by resource. In the case of a JSM user, it
allows him to organise his clients, which may have different capabilities
(some being able to handle the jabber:iq:pubsub data, others not) to
@@ -828,11 +828,11 @@ the main ones are discussed briefly here too.
<section2 topic='Publisher Discovery'>
<p>
-There is no part of this pubsub specification that determines how a
+There is no part of this pubsub specification that determines how a
potential subscriber might discover publishers. After all, there are
no rules governing which pubsub component a publisher could or should
publish to. And since pubsub subscriptions are specific to a pubsub
-component, there is an information gap - "how do I find out what
+component, there is an information gap - "how do I find out what
publishers there are, and through which pubsub components they're publishing
information?"
</p>
@@ -857,7 +857,7 @@ here). The next two sections look at how these things might pan out.
<section2 topic='Cross-Server Relationships'>
<p>
-When JSM users on server1 wish to subscribe to information published
+When JSM users on server1 wish to subscribe to information published
by JSM users on server2 (let's say it's the mp3 player info, or avatars)
then there are some issues that come immediately to mind:
</p>
@@ -865,9 +865,9 @@ then there are some issues that come immediately to mind:
<li>Does a JSM user on server1 (userA@server1) send his IQ-set subscription
to the pubsub component on server2 (pubsub.server2), or server1
(pubsub.server1)?</li>
-<li>If he sends it to pubsub.server2, can we expect
-pubsub.server2 to always accept that subscription request, i.e. to
-be willing to serve userA@server1 (if pubsub.server2 knows that
+<li>If he sends it to pubsub.server2, can we expect
+pubsub.server2 to always accept that subscription request, i.e. to
+be willing to serve userA@server1 (if pubsub.server2 knows that
pubsub.server1 exists)?</li>
<li>Will there be performance (or at least server-to-server traffic)
implications if many subscription relationships exist between subscribers on
@@ -876,7 +876,7 @@ server1 and publishers on server2?</li>
<section3 topic='Proxy Subscriptions'>
<p>
-To reduce the amount of server-to-server traffic, we can employ the
+To reduce the amount of server-to-server traffic, we can employ the
concept of "proxy subscriptions". This is simply getting a pubsub component
to act on behalf of a (server-local) subscriber. Benefit comes when a pubsub
component acts on behalf of multiple (server-local) subscribers.
@@ -889,7 +889,7 @@ server-to-server traffic:
Step 1: Subscriber sends original subscription
</p>
<p>
-JSM users on server1 wish to subscribe to information published by an
+JSM users on server1 wish to subscribe to information published by an
entity on server2. Each of them sends a subscription request to the
_local_ pubsub component:
</p>
@@ -925,7 +925,7 @@ SEND: &lt;iq type='set' to='pubsub.server2'
<p>
The remote pubsub component receives and acknowledges the subscription
-request, and the local pubsub component relays the response back to
+request, and the local pubsub component relays the response back to
the original requester:
</p>
<example>
@@ -940,7 +940,7 @@ SEND: &lt;iq type='result' from='pubsub.server1'
</example>
<p>
-If the remote pubsub server was unable or unwilling to accept the
+If the remote pubsub server was unable or unwilling to accept the
subscription request, this should be reflected in the response:
</p>
<example>
@@ -959,7 +959,7 @@ SEND: &lt;iq type='error' from='pubsub.server1'
Step3: Publisher publishes information
</p>
<p>
-The publisher, publisher.server2, publishes information in the
+The publisher, publisher.server2, publishes information in the
namespace:1 namespace, to the remote pubsub component pubsub.server2:
</p>
<example>
@@ -1022,18 +1022,18 @@ where publisher entities publish their information.
This knowledge, and the mechanisms to discover this sort of information,
is not to be covered in this spec, which purely deals with the subscription
and publishing of information. As SOAP is to UDDI (to use a slightly
-controversial pair of technologies), so is jabber:iq:pubsub to this
+controversial pair of technologies), so is jabber:iq:pubsub to this
discovery mechanism as yet undefined. To include the definition of such
a discovery mechanism in this specification is wrong on two counts:
</p>
<ul>
<li>Discovery mechanisms by nature should not be tied to specific areas</li>
-<li>Trying to load too much onto jabber:iq:pubsub will only produce a
+<li>Trying to load too much onto jabber:iq:pubsub will only produce a
complex and hard-to-implement specification</li>
</ul>
<p>
After all, the jabber:iq:pubsub spec as defined here is usable out of the
-box for the simple scenarios, and scenarios where discovery is not
+box for the simple scenarios, and scenarios where discovery is not
necessary or the information can be exchanged in other ways.
</p>
@@ -1042,7 +1042,7 @@ necessary or the information can be exchanged in other ways.
<section3 topic='Willingness to Serve'>
<p>
There are some situations where it might be appropriate for a pubsub
-component to refuse particular subscription requests. Here are two
+component to refuse particular subscription requests. Here are two
examples:
</p>
<ul>
@@ -1051,11 +1051,11 @@ configured to handle local-only pubsub traffic, and a subscription request
is received, specifying a publisher that the local pubsub component knows
to be one that publishes to a remote pubsub component <note>under other
circumstances, this would trigger a 'Proxy Subscription', as described earlier, if supported</note>. In this case, the local pubsub component would be
-unwilling to provoke a server-to-server connection and therefore unwilling to
+unwilling to provoke a server-to-server connection and therefore unwilling to
honour the request.</li>
-<li>Where a pubsub component receives a subscription request from a
-remote subscriber, and that pubsub component knows that there's a
-pubsub component local to the subscriber. In this case, the (administrator
+<li>Where a pubsub component receives a subscription request from a
+remote subscriber, and that pubsub component knows that there's a
+pubsub component local to the subscriber. In this case, the (administrator
of the) remote pubsub component might want to encourage proxy subscriptions.
</li>
</ul>
@@ -1093,20 +1093,20 @@ but it's an interesting concept :-)</p>
<section2 topic='Subscriber Anonymity and Acceptance?'>
<p>
-The jabber:iq:pubsub specification makes no provision for
+The jabber:iq:pubsub specification makes no provision for
publishers to query a pubsub component to ask for a list of those entities
-that are subscribed to (namespaces) it (publishes). This is deliberate.
+that are subscribed to (namespaces) it (publishes). This is deliberate.
Do we wish to add to the specification to allow the publisher to discover
this information? If so, it must be as an optional 'opt-in' (or 'opt-out')
tag for the subscriber, to determine whether his JID will show up on the
-list.
+list.
<note>Even if there is no provision for querying the subscribers, perhaps
we should make a provision for the publisher to ask the pubsub component
for a list of namespaces that have been subscribed to (for that publisher).
</note>
</p>
<p>
-Associated with this is the semi-reciprocal issue of acceptance? The
+Associated with this is the semi-reciprocal issue of acceptance? The
specification deliberately makes no provision for a subscription acceptance
mechanism (where the publisher must first accept a subscriber's request,
via the pubsub component). If we're to prevent the publishers knowing
@@ -1115,11 +1115,11 @@ things out'?
</p>
<p>
Note that if we do, the acceptance issue is not necessarily one for the
-pubsub specification to resolve; there are other ways of introducing
+pubsub specification to resolve; there are other ways of introducing
access control, at least in a component environment; use of a mechanism
that the Jabber::Component::Proxy Perl module represents is one example:
wedge a proxy component in front of a real (pubsub) component and have
-the ability to use ACLs (access control lists) to control who gets to
+the ability to use ACLs (access control lists) to control who gets to
connect to the real component.
</p>
diff --git a/xep-0025.xml b/xep-0025.xml
index c6b2a8f..41f96c3 100644
--- a/xep-0025.xml
+++ b/xep-0025.xml
@@ -293,7 +293,7 @@
along with the last client request. If the values do not match, the
request should be ignored or logged, with an error code being
returned of -3:0. The request must not be processed, and must not
- extend the session keepalive.
+ extend the session keepalive.
</li>
<li>
The client may send a new key K(m, seed') at any point, but should
@@ -311,7 +311,7 @@ Host: webim.jabber.com
0,<stream:stream to="jabber.com"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">]]>
-
+
</example>
<example caption="Initial response">
@@ -357,7 +357,7 @@ Host: webim.jabber.com
0;VvxEk07IFy6hUmG/PPBlTLE2fiA=,<stream:stream to="jabber.com"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">]]>
-
+
</example>
<example caption="Next request (with keys)">
diff --git a/xep-0026.xml b/xep-0026.xml
index bbdb399..d32683d 100644
--- a/xep-0026.xml
+++ b/xep-0026.xml
@@ -89,7 +89,7 @@
An xml:lang tag can be put onto any XML element; for the purposes of this document, however, we will limit its usage to the four central Jabber elements: &lt;stream/&gt;, &lt;message/&gt;, &lt;iq/&gt; and &lt;presence/&gt;.
</p>
</section2>
-
+
<section2 topic='Client support'>
<p>
A client claiming to support this document has to initiate server connection slightly differently by putting an xml:lang attribute in the initial &lt;stream:stream&gt; element.
@@ -115,10 +115,10 @@
</p>
</section2>
-
+
<section2 topic='Server support'>
<p>
- A compliant server must detect the xml:lang attribute in incoming &lt;stream:stream&gt; elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
+ A compliant server must detect the xml:lang attribute in incoming &lt;stream:stream&gt; elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
</p>
<p>
Additionally, a compliant server must attach an xml:lang attribute to the reply &lt;stream:stream&gt; element sent in response to a newly initiated connection. This attribute should reflect the default language of that server, and is used to indicate to clients that the server implements this document.
@@ -134,7 +134,7 @@
</p>
</section2>
-
+
<section2 topic='Service support'>
<p>
Jabber based services that wish to comply to this document have to make sure that all information they send to clients is tagged with an xml:lang attribute corresponding to the language used in the outgoing data, if appropriate, even if the component supports no other localizations. An example for this is a search form based on <cite>XEP-0004</cite>.
@@ -152,7 +152,7 @@
&lt;x xmlns='jabber:x:data'&gt;
&lt;instructions&gt;
- To search for a user fill out at least one
+ To search for a user fill out at least one
of the fields below and submit the form.
&lt;/instructions&gt;
&lt;field type='text-single' label='First (Given)' var='first'/&gt;
@@ -179,7 +179,7 @@
&lt;iq from='users.jabber.org' type='result' id='5' xml:lang='de'&gt;
&lt;query xmlns='jabber:iq:search'&gt;
&lt;instructions&gt;
- F&#252;llen Sie ein Feld aus um nach einem beliebigen
+ F&#252;llen Sie ein Feld aus um nach einem beliebigen
passenden Jabber-Benutzer zu suchen.
&lt;/instructions&gt;
&lt;nick/&gt;
@@ -189,7 +189,7 @@
&lt;x xmlns='jabber:x:data'&gt;
&lt;instructions&gt;
- Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines
+ Um nach einem Benutzer zu suchen, f&#252;llen Sie mindestens eines
der folgenden Felder aus und schicken dann das Formular ab.
&lt;/instructions&gt;
&lt;field type='text-single' label='Vorname' var='first'/&gt;
@@ -202,7 +202,7 @@
<p>
If the component doesn't have the requested localization available, it replies with the default localization (but of course with the matching xml:lang attribute tagged to it, and not the one of the request).
</p>
-
+
</section2>
</section1>
diff --git a/xep-0029.xml b/xep-0029.xml
index a60888b..8c0a3dc 100644
--- a/xep-0029.xml
+++ b/xep-0029.xml
@@ -71,11 +71,11 @@
&lt;hname&gt; ::= &lt;let&gt;|&lt;dig&gt;[[&lt;let&gt;|&lt;dig&gt;|"-"]*&lt;let&gt;|&lt;dig&gt;]
&lt;let&gt; ::= [a-z] | [A-Z]
&lt;dig&gt; ::= [0-9]
-&lt;conforming-char&gt; ::= #x21 | [#x23-#x25] | [#x28-#x2E] |
- [#x30-#x39] | #x3B | #x3D | #x3F |
- [#x41-#x7E] | [#x80-#xD7FF] |
+&lt;conforming-char&gt; ::= #x21 | [#x23-#x25] | [#x28-#x2E] |
+ [#x30-#x39] | #x3B | #x3D | #x3F |
+ [#x41-#x7E] | [#x80-#xD7FF] |
[#xE000-#xFFFD] | [#x10000-#x10FFFF]
-&lt;any-char&gt; ::= [#x20-#xD7FF] | [#xE000-#xFFFD] |
+&lt;any-char&gt; ::= [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]
</code>
</section2>
@@ -86,16 +86,16 @@
<p>Node identifiers are restricted to 256 bytes, They may contain any Unicode character higher than #x20 with the exception of the following:</p>
<ol>
<li>#x22 (")</li>
- <li>#x26 (&amp;)</li>
+ <li>#x26 (&amp;)</li>
<li>#x27 (')</li>
<li>#x2F (/)</li>
- <li>#x3A (:)</li>
- <li>#x3C (&lt;)</li>
- <li>#x3E (&gt;)</li>
- <li>#x40 (@)</li>
+ <li>#x3A (:)</li>
+ <li>#x3C (&lt;)</li>
+ <li>#x3E (&gt;)</li>
+ <li>#x40 (@)</li>
<li>#x7F (del)</li>
- <li>#xFFFE (BOM)</li>
- <li>#xFFFF (BOM)</li>
+ <li>#xFFFE (BOM)</li>
+ <li>#xFFFF (BOM)</li>
</ol>
<p>Case is preserved, but comparisons will be made in case-normalized canonical form.</p>
</section2>
diff --git a/xep-0030.xml b/xep-0030.xml
index 23e4cc8..c5ee53f 100644
--- a/xep-0030.xml
+++ b/xep-0030.xml
@@ -410,7 +410,7 @@
from='romeo@montague.net/orchard'
to='mim.shakespeare.lit'
id='info3'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'/>
</iq>
]]></example>
@@ -420,7 +420,7 @@
from='mim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='info3'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'>
<identity
category='automation'
@@ -538,7 +538,7 @@
from='romeo@montague.net/orchard'
to='catalog.shakespeare.lit'
id='items3'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='music'/>
</iq>
]]></example>
@@ -548,7 +548,7 @@
from='catalog.shakespeare.lit'
to='romeo@montague.net/orchard'
id='items3'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='music'>
<item jid='catalog.shakespeare.lit'
node='music/A'/>
@@ -570,7 +570,7 @@
from='romeo@montague.net/orchard'
to='catalog.shakespeare.lit'
id='items4'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='music/D'/>
</iq>
]]></example>
@@ -579,7 +579,7 @@
from='catalog.shakespeare.lit'
to='romeo@montague.net/orchard'
id='items4'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='music/D'>
<item jid='catalog.shakespeare.lit'
node='music/D/dowland-firstbooke'
@@ -613,17 +613,17 @@
id='items4'
to='romeo@montague.net'
type='get'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'/>
</iq>
]]></example>
- <p>The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:</p>
+ <p>The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:</p>
<example caption='Entity returns multiple items'><![CDATA[
<iq from='romeo@montague.net'
id='items4'
to='juliet@capulet.com/chamber'
type='result'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/tune'>
<item jid='pubsub.shakespeare.lit'
name='Romeo&apos;s CD player'
@@ -661,7 +661,7 @@
from='mim.shakespeare.lit'
to='romeo@montague.net/orchard'
id='info3'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/commands'/>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -740,13 +740,13 @@
<category>
<name>hierarchy</name>
<desc>
- An entity that exists in the context of a
+ An entity that exists in the context of a
service discovery node hierarchy.
</desc>
<type>
<name>branch</name>
<desc>
- A "container node" for other entities in a
+ A "container node" for other entities in a
service discovery node hierarchy.
</desc>
<doc>XEP-0030</doc>
@@ -754,7 +754,7 @@
<type>
<name>leaf</name>
<desc>
- A "terminal node" in a service discovery
+ A "terminal node" in a service discovery
node hierarchy.
</desc>
<doc>XEP-0030</doc>
diff --git a/xep-0031.xml b/xep-0031.xml
index 25b617d..b4ba177 100644
--- a/xep-0031.xml
+++ b/xep-0031.xml
@@ -9,15 +9,15 @@
<header>
<title>A Framework For Securing Jabber Conversations</title>
<abstract>
-Although the value and utility of contemporary instant messaging
-systems, like Jabber, are now indisputable, current security
-features to protect message data are generally inadequate for
-many deployments; this is particularly true in security conscious
-environments like large, commercial enterprises and government
-agencies. These current features suffer from issues of
-scalability, usability, and supported features. Furthermore, there is a
+Although the value and utility of contemporary instant messaging
+systems, like Jabber, are now indisputable, current security
+features to protect message data are generally inadequate for
+many deployments; this is particularly true in security conscious
+environments like large, commercial enterprises and government
+agencies. These current features suffer from issues of
+scalability, usability, and supported features. Furthermore, there is a
lack of standardization.
-We present a protocol to allow communities of Jabber users to
+We present a protocol to allow communities of Jabber users to
apply cryptographic protection to selected conversation data.
</abstract>
&LEGALNOTICE;
@@ -62,25 +62,25 @@ initial version
<section1 topic="Introduction">
<p>
-Instant messaging has clearly crossed the chasm from experimental
-to mainstream in a short amount of time. It is particularly
-interesting to note the extent to which the employees and
-affiliates of large enterprises have adopted instant messaging as
-part of their daily professional lives. IM is no longer simply
-used on Friday evening to select which movie to watch; it's now
+Instant messaging has clearly crossed the chasm from experimental
+to mainstream in a short amount of time. It is particularly
+interesting to note the extent to which the employees and
+affiliates of large enterprises have adopted instant messaging as
+part of their daily professional lives. IM is no longer simply
+used on Friday evening to select which movie to watch; it's now
used on Monday morning to select which company to acquire.
</p>
<p>
-While the benefits of IM are clear and compelling, the risks
-associated with sharing sensitive information in an IM
-environment are often overlooked. We need a mechanism that
-permits communities of users to protect their IM conversations.
-This document presents an extension protocol that can be
-incorporated into the existing Jabber protocol to provide such a
+While the benefits of IM are clear and compelling, the risks
+associated with sharing sensitive information in an IM
+environment are often overlooked. We need a mechanism that
+permits communities of users to protect their IM conversations.
+This document presents an extension protocol that can be
+incorporated into the existing Jabber protocol to provide such a
mechanism. We hope that this protocol spurs both interest
-and further investigation into mechanisms to protect Jabber
-conversations. We also hope that the Jabber community can
+and further investigation into mechanisms to protect Jabber
+conversations. We also hope that the Jabber community can
accelerate the adoption of standardized security mechanisms.
</p>
@@ -91,61 +91,61 @@ other data transported via other Jabber extensions.
</p>
<p>
-We use the following terms throughout this document to describe
-the most relevant aspects of the IM environment that we wish to
+We use the following terms throughout this document to describe
+the most relevant aspects of the IM environment that we wish to
address:
</p>
<ul>
<li>
<p>
-user. A user is simply any Jabber user. Users are uniquely
-identified by a JID; they connect to Jabber hosts using a
+user. A user is simply any Jabber user. Users are uniquely
+identified by a JID; they connect to Jabber hosts using a
Jabber node.
</p>
<p>
-Users produce and consume information, and we wish to
-provide them with mechanisms that can be used to protect
+Users produce and consume information, and we wish to
+provide them with mechanisms that can be used to protect
this information.
</p>
</li>
<li>
<p>
-community. A community is a collection of users who wish to
-communicate via Jabber. No restrictions or assumptions are
-made about the size of communities or the geographical,
-organizational, or national attributes of the members.
-Communities are assumed to be dynamic and ad-hoc. Users
-typically join communities by the simple act of invitation.
+community. A community is a collection of users who wish to
+communicate via Jabber. No restrictions or assumptions are
+made about the size of communities or the geographical,
+organizational, or national attributes of the members.
+Communities are assumed to be dynamic and ad-hoc. Users
+typically join communities by the simple act of invitation.
All members of a community are assumed to be peers.
</p>
<p>
-The members of communities share information among
-themselves, and we wish to provide them with mechanisms
-that can permit information to only be shared by community
+The members of communities share information among
+themselves, and we wish to provide them with mechanisms
+that can permit information to only be shared by community
members.
</p>
</li>
<li>
<p>
-conversation. A conversation is the set of messages
-that flows among the members of a community via some
-network. Conversations consist of both the actual
-conversation data produced and consumed by the various
-users as well as the Jabber protocol elements that
-transport it. Members participate in a conversation when
+conversation. A conversation is the set of messages
+that flows among the members of a community via some
+network. Conversations consist of both the actual
+conversation data produced and consumed by the various
+users as well as the Jabber protocol elements that
+transport it. Members participate in a conversation when
they are the source or destination of this traffic.
</p>
<p>
-In hostile network environments, like the Internet,
-conversation data is vulnerable to a variety of well-known
+In hostile network environments, like the Internet,
+conversation data is vulnerable to a variety of well-known
attacks.
</p>
</li>
</ul>
<p>
-Other Jabber and IM terms are used in a traditional, intuitive
+Other Jabber and IM terms are used in a traditional, intuitive
fashion.
</p>
@@ -154,7 +154,7 @@ fashion.
<section1 topic="Requirements And Considerations">
<p>
-The proposed protocol is designed to address the specific
+The proposed protocol is designed to address the specific
requirements and considerations presented in this section.
</p>
@@ -163,14 +163,14 @@ requirements and considerations presented in this section.
<section3 topic="Data Protection Requirements">
<p>
-A secure IM system must permit conversation participants to
+A secure IM system must permit conversation participants to
preserve the following properties of their conversation data:
</p>
<ul>
<li>
<p>
-confidentiality. Conversation data must only be disclosed
+confidentiality. Conversation data must only be disclosed
to authorized recipients
</p>
</li>
@@ -181,25 +181,25 @@ integrity. Conversation data must not be altered
</li>
<li>
<p>
-data origin authentication. Recipients must be able to
-determine the identity of the sender and trust that the
-message did, in fact, come from the sender. It is important
-to note that this requirement does not include the
-requirement of a durable digital signature on conversation
+data origin authentication. Recipients must be able to
+determine the identity of the sender and trust that the
+message did, in fact, come from the sender. It is important
+to note that this requirement does not include the
+requirement of a durable digital signature on conversation
data.
</p>
</li>
<li>
<p>
-replay protection. Recipients must be able to detect and
+replay protection. Recipients must be able to detect and
ignore duplicate conversation data.
</p>
</li>
</ul>
-<p>
-These are established, traditional goals of information security
-applied to the conversation data. In the IM environment, these
+<p>
+These are established, traditional goals of information security
+applied to the conversation data. In the IM environment, these
goals protect against these attacks:
</p>
@@ -222,12 +222,12 @@ forging messages
</ul>
<p>
-Preserving the availability of conversation data is not addressed
+Preserving the availability of conversation data is not addressed
by this protocol.
</p>
<p>
-Preserving the anonymity of conversation participants is an
+Preserving the anonymity of conversation participants is an
interesting topic which we defer for future exploration.
</p>
@@ -243,8 +243,8 @@ between a Jabber node and a Jabber host.
<p>
A secure IM system must support a data classification feature through the use
of security labeling. Conversation participants must be
-able to associate a security label with each piece of
-conversation data. This label may be used to specify a data
+able to associate a security label with each piece of
+conversation data. This label may be used to specify a data
classification level for the conversation data.
</p>
@@ -253,28 +253,28 @@ classification level for the conversation data.
<section3 topic="The End To End Requirement">
<p>
-It is easy to imagine Jabber systems in which the servers play
-active, fundamental roles in the protection of conversation
+It is easy to imagine Jabber systems in which the servers play
+active, fundamental roles in the protection of conversation
data. Such systems could offer many advantages, like:
</p>
<ul>
<li>
<p>
-allowing the servers to function as credential issuing
+allowing the servers to function as credential issuing
authorities,
</p>
</li>
<li>
<p>
-allowing the servers to function as policy enforcement
+allowing the servers to function as policy enforcement
points.
</p>
</li>
</ul>
<p>
-Unfortunately, such systems have significant disadvantages when
+Unfortunately, such systems have significant disadvantages when
one considers the nature of instant messaging:
</p>
@@ -286,35 +286,35 @@ Many servers may be untrusted, public servers.
</li>
<li>
<p>
-In many conversation communities, decisions of trust and
-membership can only be adequately defined by the members
+In many conversation communities, decisions of trust and
+membership can only be adequately defined by the members
themselves.
</p>
</li>
<li>
<p>
-In many conversation communities, membership in the
-community changes in real time based upon the dynamics of
+In many conversation communities, membership in the
+community changes in real time based upon the dynamics of
the conversation.
</p>
</li>
<li>
<p>
-In many conversation communities, the data classifaction of
-the conversation changes in real time based upon the
+In many conversation communities, the data classifaction of
+the conversation changes in real time based upon the
dynamics of the conversation.
</p>
</li>
</ul>
<p>
-Furthermore, the widespread use of gateways to external IM
+Furthermore, the widespread use of gateways to external IM
systems is a further complication.
</p>
<p>
-Based on this analysis, we propose that security be entirely
-controlled in an end to end fashion by the conversation
+Based on this analysis, we propose that security be entirely
+controlled in an end to end fashion by the conversation
participants themselves via their user agent software.
</p>
@@ -323,9 +323,9 @@ participants themselves via their user agent software.
<section3 topic="Trust Issues">
<p>
-We believe that, ultimately, trust decisions are in the hands of
-the conversation participants. A security protocol and
-appropriate conforming user agents must provide a mechanism for them to make
+We believe that, ultimately, trust decisions are in the hands of
+the conversation participants. A security protocol and
+appropriate conforming user agents must provide a mechanism for them to make
informed decisions.
</p>
@@ -334,12 +334,12 @@ informed decisions.
<section3 topic="Cryptosystem Design Considerations">
<p>
-One of the accepted axioms of security is that people must avoid
-the temptation to start from scratch and produce new, untested
-algorithms and protocols. History has demonstrated that such
-approaches are likely to contain flaws and that considerable time
-and effort are required to identify and address all of these
-flaws. Any new security protocol should be based on existing,
+One of the accepted axioms of security is that people must avoid
+the temptation to start from scratch and produce new, untested
+algorithms and protocols. History has demonstrated that such
+approaches are likely to contain flaws and that considerable time
+and effort are required to identify and address all of these
+flaws. Any new security protocol should be based on existing,
established algorithms and protocols.
</p>
@@ -350,29 +350,29 @@ established algorithms and protocols.
<section2 topic="Environmental Considerations">
<p>
-Any new IM security protocol must integrate smoothly into the
-existing IM environment, and it must also recognize the nature of
-the transactions performed by conversation participants. These
+Any new IM security protocol must integrate smoothly into the
+existing IM environment, and it must also recognize the nature of
+the transactions performed by conversation participants. These
considerations are especially important:
</p>
<ul>
<li>
<p>
-dynamic communities. The members of a community are defined
+dynamic communities. The members of a community are defined
in near real time by the existing members.
</p>
</li>
<li>
<p>
-dynamic conversations. Conversations may involve any
+dynamic conversations. Conversations may involve any
possible subset of the entire set of community members.
</p>
</li>
</ul>
<p>
-Addressing these considerations becomes especially crucial when
+Addressing these considerations becomes especially crucial when
selecting a conference keying mechanism.
</p>
@@ -381,46 +381,46 @@ selecting a conference keying mechanism.
<section2 topic="Usability Requirements">
<p>
-Given the requirement to place the responsibility for the
-protection of conversation data in the hands of the participants,
+Given the requirement to place the responsibility for the
+protection of conversation data in the hands of the participants,
it is imperative to address some fundamental usability issues:
</p>
<ul>
<li>
<p>
-First, overall ease of use is a requirement. For protocol
-purposes, one implication is that some form of
-authentication via passphrases is necessary. While we
-recognize that this can have appalling consequences,
-especially when we realize that a passphrase may be shared
-by all of the community members, we also recognize the
+First, overall ease of use is a requirement. For protocol
+purposes, one implication is that some form of
+authentication via passphrases is necessary. While we
+recognize that this can have appalling consequences,
+especially when we realize that a passphrase may be shared
+by all of the community members, we also recognize the
utility.
</p>
</li>
<li>
<p>
-PKIs are well established in many large organizations, and
+PKIs are well established in many large organizations, and
some communities will prefer to rely on credentials issued
-from these authorities. To ensure ease of use, we must
-strive to allow the use of existing PKI credentials and
-trust models rather than impose closed, Jabber-specific
+from these authorities. To ensure ease of use, we must
+strive to allow the use of existing PKI credentials and
+trust models rather than impose closed, Jabber-specific
credentials.
</p>
</li>
<li>
<p>
-Finally, performance must not be negatively impacted; this
-is particularly true if we accept that most communities are
-composed of human users conversing in real time. For
-protocol purposes, one obvious implication is the desire to
+Finally, performance must not be negatively impacted; this
+is particularly true if we accept that most communities are
+composed of human users conversing in real time. For
+protocol purposes, one obvious implication is the desire to
minimize computationally expensive public key operations.
</p>
</li>
</ul>
<p>
-We note that, in practice, the design and construction of user
+We note that, in practice, the design and construction of user
agents will also have a major impact on ease of use.
</p>
@@ -429,7 +429,7 @@ agents will also have a major impact on ease of use.
<section2 topic="Development And Deployment Requirements">
<p>
-To successfully integrate into the existing Jabber environment,
+To successfully integrate into the existing Jabber environment,
an extension protocol for security must satisfy the following:
</p>
@@ -446,8 +446,8 @@ It must be transparent to existing Jabber servers.
</li>
<li>
<p>
-It must function gracefully in cases where some community
-members are not running a user agent that supports the
+It must function gracefully in cases where some community
+members are not running a user agent that supports the
protocol.
</p>
</li>
@@ -463,7 +463,7 @@ It must avoid encumbered algorithms.
</li>
<li>
<p>
-It must be straightforward to implement using widely
+It must be straightforward to implement using widely
available cryptographic toolkits.
</p>
</li>
@@ -475,7 +475,7 @@ It must not require a PKI.
</ul>
<p>
-Failure to accommodate these will impede or prohibit adoption of
+Failure to accommodate these will impede or prohibit adoption of
any security protocol.
</p>
@@ -488,18 +488,18 @@ any security protocol.
<section2 topic="Protocol Overview">
<p>
-Ultimately, conversation data is protected by the application of
-keyed cryptographic operations. One operation is used to provide
-confidentiality, and a separate operation is used to provide
-integrity and data origin authentication. The keys used to
-parameterize these operations are called conversation keys. Each
-conversation should have its own unique set of conversation keys
+Ultimately, conversation data is protected by the application of
+keyed cryptographic operations. One operation is used to provide
+confidentiality, and a separate operation is used to provide
+integrity and data origin authentication. The keys used to
+parameterize these operations are called conversation keys. Each
+conversation should have its own unique set of conversation keys
shared among the conversation participants.
</p>
<p>
-Conversation keys are transported among the conversation
-participants within a negotiated security session. A security session allows
+Conversation keys are transported among the conversation
+participants within a negotiated security session. A security session allows
pairs of conversation participants to securely share conversation keys
throught all participants in the conversation as required.
</p>
@@ -588,23 +588,23 @@ consist of Letters, Digits, and these characters: '.', '+', '-',
<section2 topic="XML Processing">
<p>
-Since cryptographic operations are applied to data that is
-transported within an XML stream, the protocol defines a set of
-rules to ensure a consistent interpretation by all conversation
+Since cryptographic operations are applied to data that is
+transported within an XML stream, the protocol defines a set of
+rules to ensure a consistent interpretation by all conversation
participants.
</p>
<section3 topic="Transporting Binary Content">
<p>
-Binary data, such as the result of an HMAC, is always transported
-in an encoded form; the two supported encoding schemes are base64
+Binary data, such as the result of an HMAC, is always transported
+in an encoded form; the two supported encoding schemes are base64
and hex.
</p>
<p>
-Senders MAY include arbitrary white space within the character
-stream. Senders SHOULD NOT include any other characters outside
+Senders MAY include arbitrary white space within the character
+stream. Senders SHOULD NOT include any other characters outside
of the encoding set.
</p>
@@ -627,8 +627,8 @@ wrapped per XML Encryption.
<section3 topic="HMAC Computation">
<p>
-HMACs are computed over a specific collection of attribute values
-and character data; when computing an HMAC the following rules
+HMACs are computed over a specific collection of attribute values
+and character data; when computing an HMAC the following rules
apply:
</p>
@@ -640,29 +640,29 @@ All characters MUST be encoded in UTF-8.
</li>
<li>
<p>
-The octets in each character MUST be processed in network
+The octets in each character MUST be processed in network
byte order.
</p>
</li>
<li>
<p>
-For a given element, the attribute values that are HMACed
-MUST be processed in the specified order regardless of the
+For a given element, the attribute values that are HMACed
+MUST be processed in the specified order regardless of the
order in which they appear in the element tag.
</p>
</li>
<li>
<p>
-For each attribute value, the computation MUST only include
-characters from the anticipated set defined in this
-specification; in particular, white space MUST always be
+For each attribute value, the computation MUST only include
+characters from the anticipated set defined in this
+specification; in particular, white space MUST always be
ignored.
</p>
</li>
<li>
<p>
-For character data that is represented in an encoded form,
-such as base64 or hex, the computation MUST only include
+For character data that is represented in an encoded form,
+such as base64 or hex, the computation MUST only include
valid characters from the encoding set.
</p>
</li>
@@ -690,7 +690,7 @@ The octets in each character MUST be processed in network byte order.
</li>
<li>
<p>
-Appropriate cryptographic algorithm parameters, such as an
+Appropriate cryptographic algorithm parameters, such as an
IV for a block cipher, are generated.
</p>
</li>
@@ -703,7 +703,7 @@ IV for a block cipher, are generated.
<section2 topic="XML Namespaces">
<p>
-In order to integrate smoothly with the existing Jabber protocol,
+In order to integrate smoothly with the existing Jabber protocol,
this protocol utilizes a new XML namespace, jabber:security.
</p>
@@ -714,7 +714,7 @@ this protocol utilizes a new XML namespace, jabber:security.
<section3 topic="Overview">
<p>
-A security session is a pair-wise relationship between two users
+A security session is a pair-wise relationship between two users
in which the users have achieved the following:
</p>
@@ -770,18 +770,18 @@ The number of participants in typical, interactive conversations is generally on
</li>
<li>
<p>
-New participants are usually invited to dynamically join a
-conversation by being invited by an existing participant;
-this existing participant is the only one who needs to
-establish a security session with the new participant,
-because this single security session can be used to
+New participants are usually invited to dynamically join a
+conversation by being invited by an existing participant;
+this existing participant is the only one who needs to
+establish a security session with the new participant,
+because this single security session can be used to
transport all of the required conversation keys.
</p>
</li>
<li>
<p>
-User agents can permit the lifetime of security sessions to
-last long enough to allow transport of conversation keys
+User agents can permit the lifetime of security sessions to
+last long enough to allow transport of conversation keys
for a variety of converstions.
</p>
</li>
@@ -793,8 +793,8 @@ Conversation keys can be established with a suitable lifetime.
</ul>
<p>
-Other approaches, including the incorporation of more
-sophisticated conference keying algorithms, are a topic for
+Other approaches, including the incorporation of more
+sophisticated conference keying algorithms, are a topic for
future exploration.
</p>
@@ -803,7 +803,7 @@ future exploration.
<section3 topic="Security Session Negotiation">
<p>
-Security sessions are negotiated using an authenticated Diffie-Hellman key agreement
+Security sessions are negotiated using an authenticated Diffie-Hellman key agreement
exchange. The two goals of the exchange are to perform the mutual authentication
and to agree to a secret that is know only to each.
</p>
@@ -935,62 +935,62 @@ The initiator's user agent employs the following algorithm to generate the sessi
<ul>
<li>
<p>
-Appropriate values for the version, initiator, responder,
-sessionId, and hmac attributes are assembled. The version of
-this specification is '1.0'. The values of initiator and
-responder MUST be the JIDs of the two participants,
+Appropriate values for the version, initiator, responder,
+sessionId, and hmac attributes are assembled. The version of
+this specification is '1.0'. The values of initiator and
+responder MUST be the JIDs of the two participants,
respectively.
</p>
</li>
<li>
<p>
-The nonce is prepared by first generating a string of 20
-random octets (160 random bits). The octets are then
-encoded into a string of 40 hex characters representing the
+The nonce is prepared by first generating a string of 20
+random octets (160 random bits). The octets are then
+encoded into a string of 40 hex characters representing the
random string.
</p>
</li>
<li>
<p>
-A Diffie-Hellman group is selected. The appropriate values
-for g and p will be used to generate the initiator's public
+A Diffie-Hellman group is selected. The appropriate values
+for g and p will be used to generate the initiator's public
key.
</p>
</li>
<li>
<p>
-An ephemeral private key, x, is generated using g and p
-for the selected group. This key MUST be generated using an
-appropriate random number source. The corresponding public
+An ephemeral private key, x, is generated using g and p
+for the selected group. This key MUST be generated using an
+appropriate random number source. The corresponding public
key, g^x, is generated and encoded.
</p>
</li>
<li>
<p>
-The desired set of confidentiality and HMAC cryptographic
-algorithms is selected. The manner in which these
-algorithms are selected and all related policy issues are
+The desired set of confidentiality and HMAC cryptographic
+algorithms is selected. The manner in which these
+algorithms are selected and all related policy issues are
outside the scope of this specification.
</p>
</li>
<li>
<p>
-The desired set of authentication algorithms is selected.
-The manner in which these algorithms are selected and all
-related policy issues are outside the scope of this
-specification. When the digital signature form of
-authentication is selected, the relevant end-entity
-certificate and, optionally, a chain of CA certificates
-representing a validation path, is assembled and encoded. A
-set of trusted CA certificates MAY optionally be included
-via caCertificate elements; if so, the set MUST include the
+The desired set of authentication algorithms is selected.
+The manner in which these algorithms are selected and all
+related policy issues are outside the scope of this
+specification. When the digital signature form of
+authentication is selected, the relevant end-entity
+certificate and, optionally, a chain of CA certificates
+representing a validation path, is assembled and encoded. A
+set of trusted CA certificates MAY optionally be included
+via caCertificate elements; if so, the set MUST include the
issuer of the initiator's end-entity certificate.
</p>
</li>
</ul>
<p>
-These values are then used to prepare the XML session1 element;
+These values are then used to prepare the XML session1 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
@@ -1013,57 +1013,57 @@ The responder's user agent employs the following algorithm to process each sessi
<ul>
<li>
<p>
-The version and hmac attributes are checked against the
-values supported by the user agent. An unsupported version
-results in an error code of 10000, and an unsupported hmac
+The version and hmac attributes are checked against the
+values supported by the user agent. An unsupported version
+results in an error code of 10000, and an unsupported hmac
results in an error code of 10001. The responder attribute MUST
match the JID of the receiver; a mismatch results in an error code of 10009
</p>
</li>
<li>
<p>
-The nonce is decoded, and its length is checked. The nonce
-may also be checked to detect replays. An invalid nonce
+The nonce is decoded, and its length is checked. The nonce
+may also be checked to detect replays. An invalid nonce
results in an error code of 10002.
</p>
</li>
<li>
<p>
-The Diffie-Hellman group is checked against the values
-supported by the user agent. An unsupported group results
+The Diffie-Hellman group is checked against the values
+supported by the user agent. An unsupported group results
in an error code of 10003
</p>
</li>
<li>
<p>
-The desired confidentiality and HMAC cryptographic
-algorithms are selected from the proposed set. The manner
-in which these algorithms are selected and all related
-policy issues are outside the scope of this specification.
-If none of the proposed algorithms are supported, an error
+The desired confidentiality and HMAC cryptographic
+algorithms are selected from the proposed set. The manner
+in which these algorithms are selected and all related
+policy issues are outside the scope of this specification.
+If none of the proposed algorithms are supported, an error
code of 10004 occurs.
</p>
</li>
<li>
<p>
-The desired authentication algorithm is selected from the
-proposed set. The manner in which this algorithm is
-selected and all related policy issues are outside the
+The desired authentication algorithm is selected from the
+proposed set. The manner in which this algorithm is
+selected and all related policy issues are outside the
scope of this specification. In the digital signature case,
-the responder's end-entity
-certificate MUST be issued by one of the trusted CAs listed
-in the session1 PDU or by the same issuer as the
-initiator's end-entity certificate. If none of the proposed
-algorithms are supported, an error code of 10005 results.
-If the responder does not have acceptable credentials, an
+the responder's end-entity
+certificate MUST be issued by one of the trusted CAs listed
+in the session1 PDU or by the same issuer as the
+initiator's end-entity certificate. If none of the proposed
+algorithms are supported, an error code of 10005 results.
+If the responder does not have acceptable credentials, an
error code of 10006 occurs.
</p>
</li>
</ul>
<p>
-If any errors occur during processing, the session negotiation
-fails, and the error is communicated via the existing Jabber iq
+If any errors occur during processing, the session negotiation
+fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
@@ -1074,7 +1074,7 @@ mechanism:
</example>
<p>
-If no errors occur, then the responder's user agent proceeds with
+If no errors occur, then the responder's user agent proceeds with
the session2 PDU.
</p>
@@ -1089,52 +1089,52 @@ The responder's user agent employs the following algorithm to generate the sessi
<ul>
<li>
<p>
-Appropriate values for the version, initiator, responder,
-sessionId, and hmac attributes are assembled. The version of
-this specification is '1.0'. The values of initiator and
-responder MUST be the JIDs of the two participants,
-respectively. The sessionId and hmac values MUST match the
+Appropriate values for the version, initiator, responder,
+sessionId, and hmac attributes are assembled. The version of
+this specification is '1.0'. The values of initiator and
+responder MUST be the JIDs of the two participants,
+respectively. The sessionId and hmac values MUST match the
sessionId and hmac values contained in the session1 PDU.
</p>
</li>
<li>
<p>
-The nonce is prepared by first generating a string of 20
-random octets (160 random bits). The octets are then
-encoded into a string of 40 hex characters representing the
+The nonce is prepared by first generating a string of 20
+random octets (160 random bits). The octets are then
+encoded into a string of 40 hex characters representing the
random string.
</p>
</li>
<li>
<p>
-An ephemeral private key, y, is generated using g and p
-for the group indicated by the session1 PDU. This key MUST
-be generated using an appropriate random number source. The
+An ephemeral private key, y, is generated using g and p
+for the group indicated by the session1 PDU. This key MUST
+be generated using an appropriate random number source. The
corresponding public key, g^y, is generated and encoded.
</p>
</li>
<li>
<p>
-The desired pair of confidentiality and HMAC cryptographic
-algorithms is selected. The manner in which this pair is
-selected and all related policy issues are outside the
+The desired pair of confidentiality and HMAC cryptographic
+algorithms is selected. The manner in which this pair is
+selected and all related policy issues are outside the
scope of this specification.
</p>
</li>
<li>
<p>
-The desired authentication algorithm is selected. The
-manner in which this algorithm is selected and all related
-policy issues are outside the scope of this specification.
-When the digital signature form of authentication is
-selected, the relevant end-entity certificate and,
-optionally, a chain of CA certificates representing a
+The desired authentication algorithm is selected. The
+manner in which this algorithm is selected and all related
+policy issues are outside the scope of this specification.
+When the digital signature form of authentication is
+selected, the relevant end-entity certificate and,
+optionally, a chain of CA certificates representing a
validation path, is assembled and encoded.
</p>
</li>
<li>
<p>
-Based on the selected authentication algorithm, the
+Based on the selected authentication algorithm, the
responder's authenticator is constructed. A digital signature algorithm
requires calculating:
</p>
@@ -1151,7 +1151,7 @@ HASH_R = hmac (HK, version | sessionId | g^y | g^x | responder's JID)
</li>
</ul>
<p>
-HASH_R is signed using the responder's private key and encoded in PKCS#1 format.
+HASH_R is signed using the responder's private key and encoded in PKCS#1 format.
The PKCS#1 octets are then further encoded in base64 or hex.
</p>
<p>
@@ -1173,15 +1173,15 @@ HASH_R = hmac (HK, version | sessionId | g^y | g^x | responder's JID)
The octets of HASH_R are simply encoded in base64 or hex.
</p>
<p>
-The manner in which the responder's user agent gains access
-to the responder's credentials is outside the scope of this
+The manner in which the responder's user agent gains access
+to the responder's credentials is outside the scope of this
specification.
</p>
</li>
</ul>
<p>
-These values are then used to prepare the XML session2 element;
+These values are then used to prepare the XML session2 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
@@ -1204,35 +1204,35 @@ The initiator's user agent employs the following algorithm to process each sessi
<ul>
<li>
<p>
-The attribute values are checked against the values sent in
-the session1 PDU. A mismatch results in an error code of
+The attribute values are checked against the values sent in
+the session1 PDU. A mismatch results in an error code of
10008.
</p>
</li>
<li>
<p>
-The nonce is decoded, and its length is checked. The nonce
-may also be checked to detect replays. An invalid nonce
+The nonce is decoded, and its length is checked. The nonce
+may also be checked to detect replays. An invalid nonce
results in an error code of 10002.
</p>
</li>
<li>
<p>
-The Diffie-Hellman group is checked against the value sent
+The Diffie-Hellman group is checked against the value sent
in the session1 PDU. A mismatch results in an error code of 10003
</p>
</li>
<li>
<p>
-The confidentiality and HMAC cryptographic algorithms are
-validated against the set proposed in the session1 PDU. A
+The confidentiality and HMAC cryptographic algorithms are
+validated against the set proposed in the session1 PDU. A
mismatch results in an error code of 10004.
</p>
</li>
<li>
<p>
-The authentication algorithm is validated against the set
-proposed in the session1 PDU. A mismatch results in an
+The authentication algorithm is validated against the set
+proposed in the session1 PDU. A mismatch results in an
error code of 10005.
</p>
</li>
@@ -1244,8 +1244,8 @@ The authenticator is verified. A failure results in an error code of 10007.
</ul>
<p>
-If any errors occur during processing, the session negotiation
-fails, and the error is communicated via the existing Jabber iq
+If any errors occur during processing, the session negotiation
+fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
@@ -1270,18 +1270,18 @@ The initiator's user agent employs the following algorithm to generate the sessi
<ul>
<li>
<p>
-Appropriate values for the version, initiator, responder,
-sessionId, and hmac attributes are assembled. The version of
-this specification is '1.0'. The values of initiator and
-responder MUST be the JIDs of the two participants,
-respectively. The sessionId and hmac values MUST match the
-sessionId and hmac values contained in both the session1 and
+Appropriate values for the version, initiator, responder,
+sessionId, and hmac attributes are assembled. The version of
+this specification is '1.0'. The values of initiator and
+responder MUST be the JIDs of the two participants,
+respectively. The sessionId and hmac values MUST match the
+sessionId and hmac values contained in both the session1 and
session2 PDUs.
</p>
</li>
<li>
<p>
-Based on the selected authentication algorithm, the
+Based on the selected authentication algorithm, the
initiator's authenticator is constructed. A digital signature algorithm
requires calculating:
</p>
@@ -1298,7 +1298,7 @@ HASH_I = hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
</li>
</ul>
<p>
-HASH_I is signed using the responder's private key and encoded in PKCS#1 format.
+HASH_I is signed using the responder's private key and encoded in PKCS#1 format.
The PKCS#1 octets are then further encoded in base64 or hex.
</p>
<p>
@@ -1320,23 +1320,23 @@ HASH_I = hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
The octets of HASH_I are simply encoded in base64 or hex.
</p>
<p>
-The manner in which the initiator's user agent gains access
-to the initiator's credentials is outside the scope of this
+The manner in which the initiator's user agent gains access
+to the initiator's credentials is outside the scope of this
specification.
</p>
</li>
<li>
<p>
-A set of conversation keys may optionally be included in
-the response. This should typically be the case since
-security sessions are negotiated for the sole purpose of
-key transport.
+A set of conversation keys may optionally be included in
+the response. This should typically be the case since
+security sessions are negotiated for the sole purpose of
+key transport.
</p>
</li>
</ul>
<p>
-These values are then used to prepare the XML session3 element;
+These values are then used to prepare the XML session3 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
@@ -1359,8 +1359,8 @@ The responder's user agent employs the following algorithm to process each sessi
<ul>
<li>
<p>
-The attribute values are checked against the values sent in
-the session2 PDU. A mismatch results in an error code of
+The attribute values are checked against the values sent in
+the session2 PDU. A mismatch results in an error code of
10008.
</p>
</li>
@@ -1377,8 +1377,8 @@ Any keys included in the PDU are processed and added to the user agent's key sto
</ul>
<p>
-If any errors occur during processing, the session negotiation
-fails, and the error is communicated via the existing Jabber iq
+If any errors occur during processing, the session negotiation
+fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
@@ -1454,9 +1454,9 @@ The sender's user agent employs the following algorithm to generate the keyTrans
<ul>
<li>
<p>
-Appropriate values for the version, initiator, responder, and
-sessionId attributes are assembled. The version of
-this specification is '1.0'. The values of initiator and
+Appropriate values for the version, initiator, responder, and
+sessionId attributes are assembled. The version of
+this specification is '1.0'. The values of initiator and
responder MUST be the JIDs of the two participants who negotiated the
security session, respectively, and they
MUST correspond to an existing security session.
@@ -1493,7 +1493,7 @@ algorithm MUST be the same as was negotiated for the security session.
</li>
<li>
<p>
-The ds:KeyInfo element MUST NOT be present. The key to use is SKc of the
+The ds:KeyInfo element MUST NOT be present. The key to use is SKc of the
security session.
</p>
</li>
@@ -1539,7 +1539,7 @@ the character string used to construct the body of the convId element
</ul>
<p>
-These values are then used to prepare the XML keyTransport element;
+These values are then used to prepare the XML keyTransport element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
@@ -1592,7 +1592,7 @@ The keys are added to the user agent's key store.
</ul>
<p>
-If any errors occur during processing, the error is communicated via the existing Jabber iq
+If any errors occur during processing, the error is communicated via the existing Jabber iq
mechanism:
</p>
@@ -1684,8 +1684,8 @@ The sender's user agent employs the following algorithm to generate the protecte
<ul>
<li>
<p>
-Appropriate values for the version, from, to, convId, and
-seqNum attributes are assembled. The version of
+Appropriate values for the version, from, to, convId, and
+seqNum attributes are assembled. The version of
this specification is '1.0'. The value of convId MUST correspond to an existing, valid key.
</p>
</li>
@@ -1762,7 +1762,7 @@ any securityLabel element
</li>
<li>
<p>
-the character string used to construct the body of the payload element
+the character string used to construct the body of the payload element
</p>
</li>
</ul>
@@ -1770,7 +1770,7 @@ the character string used to construct the body of the payload element
</ul>
<p>
-These values are then used to prepare the XML protectedMessage element;
+These values are then used to prepare the XML protectedMessage element;
this element is transmitted via the existing Jabber message mechanism:
</p>
@@ -1819,7 +1819,7 @@ The HMAC is validated. An invalid HMAC results in an error code of 10011.
</ul>
<p>
-If any errors occur during processing, the error is communicated via the existing Jabber iq
+If any errors occur during processing, the error is communicated via the existing Jabber iq
mechanism:
</p>
diff --git a/xep-0032.xml b/xep-0032.xml
index 0a31fcc..7be8611 100644
--- a/xep-0032.xml
+++ b/xep-0032.xml
@@ -67,10 +67,10 @@
</section2>
<section2 topic='Node Identifier Component'>
<p>The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of XEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:</p>
- <code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
-#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
+ <code>#x22 (") | #x26 (&amp;) | #x27 (') | #x2F (/) |
+#x3A (:) | #x3C (&lt;) | #x3E (&gt;) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
- <p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
+ <p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
<code>#x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)</code>
<p>Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:</p>
<code>#x23 (#) | #x25 (%)</code>
@@ -82,10 +82,10 @@
</section2>
<section2 topic='Query Component'>
<p>The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:</p>
- <code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
-#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) |
-#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) |
-#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) |
+ <code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
+#x26 (&amp;) | #x27 (') | #x2B (+) | #x2C (,) |
+#x2F (/) | #x3A (:) | #x3B (;) | #x3C (&lt;) |
+#x3D (=) | #x3E (&gt;) | #x3F (?) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
</section2>
</section1>
diff --git a/xep-0033.xml b/xep-0033.xml
index c4cc17a..ee0c7ca 100644
--- a/xep-0033.xml
+++ b/xep-0033.xml
@@ -6,7 +6,7 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
- <title>Extended Stanza Addressing</title>
+ <title>Extended Stanza Addressing</title>
<abstract>This specification defines an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
&LEGALNOTICE;
<number>0033</number>
@@ -55,7 +55,7 @@
<version>0.10</version>
<date>2004-03-18</date>
<initials>psa</initials>
- <remark>Disallowed &lt;addresses/&gt; as direct child
+ <remark>Disallowed &lt;addresses/&gt; as direct child
of &IQ;.</remark>
</revision>
@@ -143,12 +143,12 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>On the existing Jabber network, there are many opportunities to optimize stanza traffic. For example, clients that want to send the same stanza to multiple recipients currently must send multiple stanzas. Similarly, when a user comes online the server sends many nearly-identical presence stanzas to remote servers.</p>
-
+
<p>The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;. As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' <note><link url='http://archive.jabber.org/docs/proto-draft/envelope.html'>jabber:x:envelope</link> - Message Envelope Information Extension</note> proposal, which this XEP can supersede.</p>
</section1>
<section1 topic='Discovering Server Support' anchor='disco'>
<p>Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &xep0030;. A conforming server MUST respond to disco#info requests.</p>
-
+
<section2 topic='Disco to determine support' anchor='disco-support'>
<p>To determine if a server or service supports Extended Stanza Addressing, the requesting entity SHOULD send a disco#info request to it.</p>
@@ -210,7 +210,7 @@
relaying across server-to-server connections as a side-effect.</p>
<p>Address headers MAY be included in message or presence
- stanzas. They MUST NOT be included as the direct child of an
+ stanzas. They MUST NOT be included as the direct child of an
IQ stanza.</p>
</section1>
@@ -233,7 +233,7 @@
</addresses>
</presence>]]></example>
-
+
<p>Each address to which the sender wants the stanza to be re-sent will show up as an &lt;address/&gt; in the &lt;addresses/&gt; element. There are several different types of address, shown below.</p>
<p>An &lt;address/&gt; element MUST possess a 'type' attribute, and MUST possess at least one of the 'jid', 'uri', 'node', and 'desc' attributes. An &lt;address/&gt; element MUST NOT possess both a 'jid' attribute and a 'uri' attribute. If sending through a multicast service, an address MUST include a 'jid' or a 'uri' attribute, unless it is of type 'noreply'.</p>
@@ -294,7 +294,7 @@
</address>
<address type='replyroom' jid='jdev@conference.jabber.org'/>
</addresses>
-</message>]]></example>
+</message>]]></example>
</section2>
</section1>
@@ -325,19 +325,19 @@
service also receive the associated unavailable presence.</p>
</section2>
</section1>
-
+
<section1 topic='Multicast Usage' anchor='multicast'>
<p>The following usage scenario shows how messages flow through both address-enabled and non-address-enabled portions of the Jabber network.</p>
-
+
<p>Note: the logic associated with <em>how</em> to perform the following tasks is purely informational. A conforming service MUST generate output as if these rules had been followed, but need not (and probably <em>will not</em>) use this algorithm.</p>
<ol>
<li>User desires to send a stanza to more than one
recipient.</li>
-
+
<li>Client determines the JID of a multicast service,
using Service Discovery.</li>
-
+
<li>If no multicast service is found, the client MAY
choose to deliver each stanza individually, or it MAY
query each of the servers associated with desired
@@ -346,8 +346,8 @@
<li>If a multicast service is found, the client constructs
a stanza with an address block, and sends it to the
- multicast service. (Note: For the following rules, any
- address that was marked on the incoming address header
+ multicast service. (Note: For the following rules, any
+ address that was marked on the incoming address header
with delivered='true' is never re-delivered.)</li>
<li>The server checks to see if it can deliver to all of
@@ -372,12 +372,12 @@
in the original address header, the local server determines
whether the target server supports multicast, using Service
Discovery.</li>
-
+
<li>If the target server does not support address headers, the
local server sends a copy of the stanza to each address,
with the 'to' attribute on the outer stanza set to the JID
of the given addressee.</li>
-
+
<li>If the target server does support address headers, the server
removes the delivered='true' attributes on each of the
addresses bound for that server, and replaces the 'to'
@@ -586,7 +586,7 @@
<ol>
<li>If a noreply address is
- specified, a reply SHOULD NOT be generated.</li>
+ specified, a reply SHOULD NOT be generated.</li>
<li>If one or more replyroom addresses are specified, the client SHOULD
join the specified chat rooms instead of replying directly
diff --git a/xep-0034.xml b/xep-0034.xml
index 1645089..6b4671f 100644
--- a/xep-0034.xml
+++ b/xep-0034.xml
@@ -71,7 +71,7 @@
<section1 topic='Introduction'>
<p>The Simple Authentication and Security Layer (SASL) (see &rfc4422;) provides a generalized method for adding authentication support to connection-based protocols. This document describes a generic XML namespace profile for SASL, that conforms to section 4 of RFC 4422, "Profiling requirements".</p>
-
+
<p>This profile may be used for both client-to-server and server-to-server connections. For client connections, the service name used is &quot;jabber-client&quot;. For server connections, the service name used is &quot;jabber-server&quot;. Both these names are registered in the IANA service registry.</p>
<p>The reader is expected to have read and understood the SASL specification before reading this document.</p>
@@ -102,7 +102,7 @@
</ol>
<p>After authentication has completed, the client sends a packet to begin the session.</p>
-
+
<p>The namespace identifier for this protocol is http://www.iana.org/assignments/sasl-mechanisms.</p>
<p>The following examples show the dialogue between a client [C] and a server [S].</p>
diff --git a/xep-0035.xml b/xep-0035.xml
index 0abb1ea..8a73805 100644
--- a/xep-0035.xml
+++ b/xep-0035.xml
@@ -122,7 +122,7 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
<p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>XEP-0034</cite> for more information.</p>
-
+
<p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1>
diff --git a/xep-0036.xml b/xep-0036.xml
index e4e6ba1..0997b1f 100644
--- a/xep-0036.xml
+++ b/xep-0036.xml
@@ -7,7 +7,7 @@
<xep>
<header>
<title>Pub-Sub Subscriptions</title>
- <abstract>A proposal for the subscribe half of a publish-subscribe protocol within Jabber.</abstract>
+ <abstract>A proposal for the subscribe half of a publish-subscribe protocol within Jabber.</abstract>
&LEGALNOTICE;
<number>0036</number>
<status>Retracted</status>
diff --git a/xep-0037.xml b/xep-0037.xml
index 8e308ad..9a05758 100644
--- a/xep-0037.xml
+++ b/xep-0037.xml
@@ -107,9 +107,9 @@
&lt;iq
id='dsps1'
type='get'
- from='rob@nauseum.org/dspsclient'
+ from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a44'&gt;
- &lt;query type='create'
+ &lt;query type='create'
xmlns='jabber:iq:dsps'
minthroughput='1.5KB'
maxpublic='20'&gt;
@@ -146,9 +146,9 @@
<example>
&lt;iq
- id='dsps1'
+ id='dsps1'
type='result'
- from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+ from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='create' xmlns='jabber:iq:dsps'
wait='10'
@@ -248,7 +248,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
<section3 topic='Connecting to DSPS via SSL method {optional}'>
<p>Client must connect to DSPS on specified port and initiate handshake. This may be attempted after &quot;create&quot; result received or &quot;disconnect&quot; occurred, and prior to &quot;wait&quot; timeout expiring, then send following on stream:</p>
-
+
<example>starttls&lt;CR&gt;</example>
<p>Next, regular TLS handshake is initiated. Upon completion, Client must resume DSPS handshake as per section &quot;Connecting to DSPS via default method&quot;. On error connection closed immediately with optional error messages.</p>
@@ -335,7 +335,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
<li><strong>&lt;peer/&gt;</strong> body is full JID of the joined peer unless peer of type &quot;relay&quot;, in which case the resource is not reported.</li>
<li><strong>&quot;status&quot;</strong> is new status of peer.</li>
</ul>
-
+
<p>Possible failure messages:</p>
@@ -346,7 +346,7 @@ Content-Type: application/octet-stream&lt;CR&gt;
</table>
</section3>
-
+
</section2>
<section2 topic='Stream administration'>
@@ -361,9 +361,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<example>
&lt;iq
- id='dsps3'
+ id='dsps3'
type='set'
- from='rob@nauseum.org/dspsclient'
+ from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='admin' xmlns='jabber:iq:dsps' expire='20' wait='10'&gt;
&lt;comment&gt;welcome to the stream&lt;/comment&gt;
@@ -410,18 +410,18 @@ Content-Type: application/octet-stream&lt;CR&gt;
<tr><th>Code</th><th>Message</th><th>Description</th></tr>
<tr><td>403</td><td>Forbidden</td><td><em>(optional)</em> Returned if peer with &quot;slave&quot; rights attempts to use &quot;master&quot; admin privileges.</td></tr>
</table>
-
+
<section3 topic='Invitation to stream {optional}'>
<p>Upon invite DSPS will attempt to invite each of the peers like so:</p>
<example>
&lt;iq
- id='dsps4'
+ id='dsps4'
type='get'
- from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+ from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
- &lt;query type='acknowledge'
+ &lt;query type='acknowledge'
xmlns='jabber:iq:dsps'
status='master'
expire='20'&gt;
@@ -447,9 +447,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon drop DSPS will immediately closes the connection to the dropped peer. It then will totally forget this peer right after sending it a notification message like so:</p>
<example>
-&lt;iq
+&lt;iq
id='dsps5'
- type='set'
+ type='set'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'&gt;
@@ -469,9 +469,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<example>
&lt;iq
- id='dsps6'
+ id='dsps6'
type='set'
- from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+ from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
&lt;peer status='drop'&gt;JID&lt;/peer&gt;
@@ -487,22 +487,22 @@ Content-Type: application/octet-stream&lt;CR&gt;
</ul>
</section3>
-
+
</section2>
<section2 topic='Invitation reply'>
<p>An invited peer has the option to accept or reject an invitation to a stream.</p>
-
+
<section3 topic='Accepting an invite'>
<p>To accept an invitation to a stream, the peer must reply like so:</p>
<example>
&lt;iq
- id='dsps4'
+ id='dsps4'
type='result'
- from='foo@bar.com/moredsps'
+ from='foo@bar.com/moredsps'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='connect'/&gt;
&lt;/iq&gt;
@@ -518,16 +518,16 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon receipt of this reply the DSPS creates a unique resource for this client JID/resource pair. It then prepares the &quot;create&quot; message as described in section &quot;Connection waiting&quot;.</p>
</section3>
-
+
<section3 topic='Rejecting an invite'>
<p>Rejecting an invitation can be done in two ways. A peer can forget about the invitation and let the invitation &quot;expire&quot;, or preferably a message can be sent like so:</p>
<example>
&lt;iq
- id='dsps4'
+ id='dsps4'
type='result'
- from='foo@bar.com/moredsps'
+ from='foo@bar.com/moredsps'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33&gt;
&lt;query type='acknowledge' xmlns='jabber:iq:dsps' status='drop'/&gt;
&lt;/iq&gt;
@@ -539,10 +539,10 @@ Content-Type: application/octet-stream&lt;CR&gt;
<li><strong>&quot;status&quot;</strong> drop denotes an rejection of invitation.</li>
</ul>
- <p>Regardless of the way a rejection was achieved a notification message is sent to the inviting peer, as was described in section &quot;Stream administration&quot;. If unknown &quot;type&quot; is sent, it will be interpreted as a reject. A maximum of one &quot;acknowledge&quot; is allowed during the lifetime of an invitation. If multiple such tags are sent, the first tag takes precedence. Any rejection of a public connection will be ignored.</p>
+ <p>Regardless of the way a rejection was achieved a notification message is sent to the inviting peer, as was described in section &quot;Stream administration&quot;. If unknown &quot;type&quot; is sent, it will be interpreted as a reject. A maximum of one &quot;acknowledge&quot; is allowed during the lifetime of an invitation. If multiple such tags are sent, the first tag takes precedence. Any rejection of a public connection will be ignored.</p>
</section3>
-
+
</section2>
<section2 topic='Disconnection handling'>
@@ -554,9 +554,9 @@ Content-Type: application/octet-stream&lt;CR&gt;
<p>Upon such disconnection DSPS notifies all other members of the stream, following the rules stated for the &quot;presence&quot; message, and takes the form of:</p>
<example>
-&lt;iq
+&lt;iq
id='dsps7'
- type='set'
+ type='set'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='foo@bar.com/resource'&gt;
&lt;query type='presence' xmlns='jabber:iq:dsps'&gt;
@@ -620,9 +620,9 @@ this is the data in ASCII form
<example>
&lt;iq
- id='dsps8'
+ id='dsps8'
type='get'
- from='rob@nauseum.org/dspsclient'
+ from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='who' xmlns='jabber:iq:dsps'/&gt;
&lt;/iq&gt;
@@ -638,13 +638,13 @@ this is the data in ASCII form
<p>The query reply is formatted like so:</p>
<example>
-&lt;iq
+&lt;iq
id='dsps8'
- type='result'
+ type='result'
from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='who' xmlns='jabber:iq:dsps'&gt;
- &lt;peer
+ &lt;peer
type='master'
id='0'
status='connect'
@@ -671,9 +671,9 @@ this is the data in ASCII form
<p>To retrieve listing of all stream configuration/statistics values or public streams, any registered peer sends a message like so:</p>
<example>
-&lt;iq
+&lt;iq
id='dsps9'
- type='get'
+ type='get'
from='rob@nauseum.org/dspsclient'
to='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'&gt;
&lt;query type='stats' xmlns='jabber:iq:dsps'/&gt;
@@ -689,9 +689,9 @@ this is the data in ASCII form
<example>
&lt;iq
- id='dsps9'
+ id='dsps9'
type='result'
- from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
+ from='dsps.jabber.org/0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
to='rob@nauseum.org/dspsclient'&gt;
&lt;query type='stats' xmlns='jabber:iq:dsps'
init='00000000000000'
@@ -736,12 +736,12 @@ this is the data in ASCII form
<p>All &quot;status&quot; attributes are required. Any other undefined blocks with any multiplicity, are legal in this block as long as their tags are not identical to any tag within the protocol. Results returned do not have any strict order. If &quot;to&quot; in original request contained no resource, multiple &quot;stats&quot; blocks are allowed, where each contains at least one &lt;peer/&gt; block which has &quot;maxpublic&quot; greater than 0. To join a public stream a client must send message as per section &quot;Accepting an invite&quot;.</p>
</section3>
-
+
</section2>
<section2 topic='Stream shutdown'>
- <p>Stream exists from its &quot;create&quot;ion time to the time when there are no more &quot;master&quot; peers registered with the stream.</p>
+ <p>Stream exists from its &quot;create&quot;ion time to the time when there are no more &quot;master&quot; peers registered with the stream.</p>
<p>When last &quot;master&quot; peer is dropped from the stream, DSPS will make sure that all the data sent by all the &quot;master&quot; peers was actually copied to all the &quot;slave&quot; peers still present. For every remaining &quot;slave&quot; peer DSPS will initiate a drop event. Once stream is void of any peers it will be totally forgotten by the DSPS and all associated data is released.</p>
@@ -749,7 +749,7 @@ this is the data in ASCII form
<section2 topic='Error message format'>
- <p>Error messages look like so:</p>
+ <p>Error messages look like so:</p>
<example>
&lt;iq
diff --git a/xep-0040.xml b/xep-0040.xml
index 2c55181..1928f96 100644
--- a/xep-0040.xml
+++ b/xep-0040.xml
@@ -74,7 +74,7 @@
<p>Multiple levels of sequence numbers are envisaged and will be used in different circumstances. Multiple levels allow a rapid repair of short "transient" breaks whilst catering for longer breaks, recoveries and resynchronisations without placing too great a burden on either subscriber or pubsub component. This discussion explains the use of a dual sequence number environment: link and source.</p>
<p>Sequence numbers will be sent in each publish thus:</p>
<example>
-&lt;iq type="set"
+&lt;iq type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
@@ -96,7 +96,7 @@
<p>The operation of LINK and SOURCE sequence numbers are described below.</p>
</section2>
<section2 topic="Link Level Swquence Numbering">
- <p>This will concern itself with data sent on each channel. A
+ <p>This will concern itself with data sent on each channel. A
channel can be, but is not limited to the following:</p>
<ul>
<li>Socket connection between Subscriber (and/or resource within same) and the Jabber pubsub component.</li>
@@ -116,8 +116,8 @@ channel can be, but is not limited to the following:</p>
<section2 topic="Gap Filling">
<p>When a subscriber detects a gap on its link, it can request for the data to be resent thus:</p>
<example>
-&lt;iq
- type="get"
+&lt;iq
+ type="get"
id="plugthegap1"
from="myclient@server.net"
to="pubsub.localhost"&gt;
@@ -130,8 +130,8 @@ channel can be, but is not limited to the following:</p>
<p>Should the pubsub have lost the link context and thus is unable to plug the gaps it will return an error &lt;iq/&gt; packet.</p>
<p>All is not lost. The subscriber has a last-ditch repair scenario by sending last-received source sequence numbers. </p>
<example>
-&lt;iq
- type="get"
+&lt;iq
+ type="get"
id="plugthegap1"
from="myclient@server.net"
to="pubsub.localhost"&gt;
@@ -144,18 +144,18 @@ channel can be, but is not limited to the following:</p>
<p>Due to the non-contiguous nature of source sequence numbers from the subscriber point of view, the values sent must represent not the gap, but the last valid sequence number received. Each source may have a separate sequence number stream. This allows the pubsub component to manage and, if necessary, request gaps itself from the publisher to resynchronise the subscriber. The pubsub or publishing source should have the ability to refuse a rebuild/resynchronise.</p>
<p>It should be possible for the subscriber to send the link and source sequence numbers in the initial request. However, if link information has been discarded by the pubsub component (e.g. the connection was dropped and presence set offline) the link sequence numbers will be reset to zero (re-synchronised) thus:</p>
<example>
-&lt;iq
+&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
- &lt;publish
+ &lt;publish
ns="data topics"
linkseq="0"
sourceseq="7547392"
from="publisher.fromaplace"&gt;
&lt;/publish&gt;
- &lt;publish
+ &lt;publish
ns="data topics"
linkseq="1"
sourceseq="44211"
@@ -168,12 +168,12 @@ channel can be, but is not limited to the following:</p>
<section2 topic="Heartbeats">
<p>During times of low traffic, an active circuit can be provided with regular heartbeat transmissions. Heartbeats will increment the link level sequence numbers. Subscribers missing or detecting overdue heartbeats will thus be able to detect gaps or delays even in low traffic scenarios. If the data is simply delayed, the subscriber stub is in a position to take action (and/or alert the application/user). If data is lost or heartbeats do not arrive in time, the subscriber can decide to request retransmission, disconnect or wait.</p>
<example>
-&lt;iq
+&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
- &lt;publish
+ &lt;publish
ns="link.heartbeat"
linkseq="57374"
from="pubsub.localhost"&gt;
@@ -189,19 +189,19 @@ channel can be, but is not limited to the following:</p>
<p>When a publish packet arrives with a topic or data namespace, there is currently no way of knowing how to interpret the tags therein. Do they replace existing tag values seen? Should previously sent tags that are not in the publish be kept or discarded? Are tag values being updated or was the previous value incorrect?</p>
<p>To resolve this a type field may be added to the &lt;publish/&gt; tag.</p>
<example>
-&lt;iq
+&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
- &lt;publish
+ &lt;publish
ns="data topics"
linkseq="57372"
sourceseq="7547392"
from="publisher.fromaplace"
type="update"&gt;
&lt;/publish&gt;
- &lt;publish
+ &lt;publish
ns="data topics"
linkseq="57373"
sourceseq="44211"
@@ -242,12 +242,12 @@ channel can be, but is not limited to the following:</p>
<p>Tokenised permissioning allows sets of data can be treated en masse. By permitting the concept of "grant" and "deny" permissions simultaneously (settings that define who CAN see something or defining who CANNOT) individual publishers can manage access both broadly and down to very fine granularity.</p>
<p>Permission tokens, if used, should be sent in-band with the data. This will allow data to change its coding online and thus immediately affect permissioning without a redistribution of the permissioning information.</p>
<example>
-&lt;iq
+&lt;iq
type="set"
to="myclient@server.net"
from="pubsub.localhost"&gt;
&lt;query xmlns="jabber:iq:pubsub"&gt;
- &lt;publish
+ &lt;publish
ns="data topics"
type="update"
permtoken="6747"
diff --git a/xep-0042.xml b/xep-0042.xml
index 05f0e36..b774ef9 100644
--- a/xep-0042.xml
+++ b/xep-0042.xml
@@ -7,7 +7,7 @@
<xep>
<header>
<title>Jabber OOB Broadcast Service (JOBS)</title>
- <abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
+ <abstract>A protocol for enabling uni-directional multicast data transfers out of band.</abstract>
&LEGALNOTICE;
<number>0042</number>
<status>Retracted</status>
@@ -72,7 +72,7 @@
<p>JOBS utilizes a "two-band" authentication mechanism. This allows the end-points to know practically nothing about each other, yet still be assured that the OOB connection is really to/from the Jabber entity its intended to be. The authentication system is then backed-up with explicit authorization requests.</p>
<p>For the OOB portion, clients connect to the host/address and port of the JOBS service for a given session. Once connected, a client-initiated handshake process occurs, and (if successful), then data is routed from the sender's connection to each receiver's connection. The only point at which any error information may be conveyed over the OOB connection is during the handshake process.</p>
-
+
<table caption='Terms in Use'>
<tr>
<th>Term</th>
@@ -136,12 +136,12 @@
</section2>
<section2 topic='Creating a Session'>
<p>The JOBS protocol supports various scenarios to create sessions. Most of these scenarios allow an entity to determine the possible parameters to create a session with. To actually create a session, the (would-be) sender sends an "iq-set" with a &lt;session action="create"/&gt;. This returns the details of the newly created session, including the ID and OOB host/port.</p>
-
+
<p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
-
+
<section3 topic='Simple'>
<p>The simplest create request is:</p>
-
+
<example caption='Creation request'><![CDATA[
<iq type='set' from='sender@domain/res' to='jobs.domain' id='JOBS1'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -149,27 +149,27 @@
</iq>
]]></example>
<example caption='Creation result'><![CDATA[
-<iq
+<iq
type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
- host='jobs.domain'
+ host='jobs.domain'
id='01234567'
- port='12676'
+ port='12676'
sender='sender@domain/res'
buffer='0'
- expires='30'
+ expires='30'
receivers='1'/>
</iq>
]]></example>
-
+
<p>This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The &lt;session/&gt; element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID <note>The exact value of the ID is left to JOBS implementations.</note>.</p>
</section3>
<section3 topic='With Parameters'>
<p>When creating a session, parameters to &lt;session/&gt; can be supplied, explicitly requesting that certain parameters be met (such as buffer size, time to expire, and receiver limit). Since these parameters have lower- and upper-bounds specific to the JOBS service, a sender may need to determine these limits.</p>
-
+
<p>To determine the limits, the sender sends an "iq-get" with a &lt;session action="create"/&gt;:</p>
-
+
<example caption='Parameter statistics request'><![CDATA[
<iq id='JOBS0' type='get' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'/>
@@ -202,7 +202,7 @@
]]></example>
<p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p>
-
+
<p>To create a session with specific parameters, the sender sends an "iq-set" as in the "simple" use-case, but then specifying the parameter values desired:</p>
<example caption='Creation request, with parameters'><![CDATA[
<iq id='JOBS1' type='set' to='jobs.domain'>
@@ -214,25 +214,25 @@
<iq type='result' to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
- host='jobs.domain'
+ host='jobs.domain'
id='01234567'
- port='12676'
+ port='12676'
sender='sender@domain/res'
buffer='0'
- expires='-1'
+ expires='-1'
receivers='1'/>
</iq>
]]></example>
-
+
<p>The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.</p>
-
+
<p>Any parameters that exceed the minimums/maximums causes an error.</p>
</section3>
<section3 topic='Form-based'>
<p>In some cases, the session creation process requires an interface more suitable for human consumption. In such cases the JOBS protocol helps by allowing for contained elements governed by other namespaces. For form-based creation, a &xep0004; form can be embedded in the &lt;session/&gt;.</p>
-
+
<p>To create a session using forms, send a &lt;session action="create"/&gt; with an embedded &lt;x xmlns="jabber:x:data"/&gt;:</p>
-
+
<example caption='Creation form request'><![CDATA[
<iq type='get' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'>
@@ -243,10 +243,10 @@
<example caption='Creation form result'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
- host='jobs.domain'
- port='12676'
+ host='jobs.domain'
+ port='12676'
buffer='0'
- expires='-1'
+ expires='-1'
receivers='1'>
<x xmlns='jabber:x:data' type='form'>
<instructions>Please specify values for the given fields.</instructions>
@@ -260,10 +260,10 @@
</session>
</iq>
]]></example>
-
+
<p>The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the &lt;session/&gt; attributes.</p>
<p>Using the form-based approach, the session is then created by sending a &lt;session action='create'/&gt; with a form submission (as defined for "jabber:x:data"):</p>
-
+
<example caption='Creation request (form-based)'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs' action='create'>
@@ -280,12 +280,12 @@
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
status='pending'
- host='jobs.domain'
+ host='jobs.domain'
id='01234567'
- port='12676'
+ port='12676'
sender='sender@domain/res'
buffer='0'
- expires='300'
+ expires='300'
receivers='1'/>
</iq>
]]></example>
@@ -293,7 +293,7 @@
</section2>
<section2 topic='Inviting Receivers'>
<p>Once the session is created, the sender invites receivers to connect. The sender can invite receivers either directly, or via the JOBS service. Most invitations are distributed via &lt;message/&gt;.</p>
-
+
<section3 topic='Inviting Directly'>
<p>The sender can invite receivers directly. This is done using a &lt;message/&gt;:</p>
<example caption='Invitation message (direct)'><![CDATA[
@@ -309,7 +309,7 @@
receivers='1'/>
</message>
]]></example>
-
+
<p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p>
<ul>
<li>host</li>
@@ -414,26 +414,26 @@
<section2 topic='Connecting OOB'>
<section3 topic='Initiating and Authenticating'>
<p>When a client connects (sender or receivers), a client-initiated handshake takes place. The purpose of this handshake is to authenticate the OOB connection, in relation to the client's JID. This authentication utilizes both in-band and OOB packets.</p>
-
+
<p>To start the handshake, the client sends an "init" packet on its established connection:</p>
-
+
<example caption='Client INIT'><![CDATA[
jobs/0.4 init
session-id: 01234567
client-jid: sender@domain/res
]]></example>
-
+
<p>If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:</p>
-
+
<example caption='Server AUTH-CHALLENGE'><![CDATA[
jobs/0.4 auth-challenge
confirm: SID00001234
]]></example>
-
+
<p>Once received, the client then sends an "iq-set" containing a &lt;session action="authenticate"/&gt;, which itself contains an &lt;item type='auth' action='confirm'/&gt; with this confirm key:</p>
-
+
<example caption='Authentication request (from Client)'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -443,9 +443,9 @@ confirm: SID00001234
</session>
</iq>hehe
]]></example>
-
+
<p>The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a &lt;session action="authenticate"/&gt; containing a &lt;item type="auth" action="accept"/&gt; with the accept key:</p>
-
+
<example caption='Authentication result (from Server)'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -456,17 +456,17 @@ confirm: SID00001234
</session>
</iq>
]]></example>
-
+
<p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p>
-
+
<example caption='Client AUTH-RESPONSE'><![CDATA[
jobs/0.4 auth-response
accept: SID88884321
-
+
]]></example>
-
+
<p>If the connection is accepted, the JOBS service sends a "connected" packet:</p>
-
+
<example caption='Server CONNECTED'><![CDATA[
jobs/0.4 connected
@@ -475,9 +475,9 @@ confirm: SID00001234
</section3>
<section3 topic='Authorizing'>
<p>Authenticating ensures the OOB connection matches a particular JID. Authorizing ensures to the service that receiver is allowed to be connected to the session. To determine if the session connection should be accepted or rejected, the JOBS service first checks if the JID matches the sender. This matches against the "full" JID, including node, domain, and resource. If this connection is the sender, it is allowed. Otherwise, the service confirms the connection with the sender.</p>
-
+
<p>If a confirmation is required, the service sends an "iq-get" to the sender, with a &lt;session action="authorize"/&gt; containing an &lt;item type"connection" action="confirm"/&gt; with the full JID of the receiver:</p>
-
+
<example caption='Confirmation request'><![CDATA[
<iq type='get' to='sender@domain/res' id='JOBS5' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -509,12 +509,12 @@ confirm: SID00001234
</session>
</iq>
]]></example>
-
+
<p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p>
</section3>
<section3 topic='Dropping'>
<p>The sender may drop a connection at any time. To drop a connection, the sender sends an "iq-set" with the &lt;session/&gt; containing the "connection" to drop:</p>
-
+
<example caption='Drop request'><![CDATA[
<iq type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -524,9 +524,9 @@ confirm: SID00001234
</session>
</iq>
]]></example>
-
+
<p>If the connection is successfully dropped, the service returns an "iq-result":</p>
-
+
<example caption='Drop result'><![CDATA[
<iq type='result' from='jobs.domain' to='sender@domain/res'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -534,20 +534,20 @@ confirm: SID00001234
id='01234567'/>
</iq>
]]></example>
-
+
<p>The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).</p>
</section3>
</section2>
<section2 topic='Deleting a Session'>
<p>Sessions are deleted either by timeout or explicitly. Sessions are deleted by timeout automatically under certain conditions. Sessions can also be deleted explicity by their senders, at any time. Regardless of the method of deletion, a notice is sent to all connected.</p>
-
+
<p>This use-case can be completely ignored for true "peer-to-peer" systems.</p>
<section3 topic='Expiring'>
<p>The exact conditions that expire a session are mostly up to the implementation. At a minimum, a session SHOULD be expired when there are less than two connections, and the "expires" time is reached.</p>
</section3>
<section3 topic='Deleting Explicitly'>
<p>To explictly delete a session, the sender sends an "iq-set" containing a &lt;session action="delete"/&gt;:</p>
-
+
<example caption='Delete request'><![CDATA[
<iq id='JOBS50' type='set' to='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -566,7 +566,7 @@ confirm: SID00001234
<section2 topic='Being Notified about Events'>
<section3 topic='Connection Accepted'>
<p>When a connection is accepted, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='accept'/&gt;:</p>
-
+
<example caption='"Connection Accepted" message'><![CDATA[
<message to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -577,12 +577,12 @@ confirm: SID00001234
</session>
</message>
]]></example>
-
+
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3>
<section3 topic='Connection Rejected'>
<p>When a connection is rejected, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='reject'/&gt;:</p>
-
+
<example caption='"Connection Rejected" message'><![CDATA[
<message to='receiver@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -593,12 +593,12 @@ confirm: SID00001234
</session>
</message>
]]></example>
-
+
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3>
<section3 topic='Connection Dropped'>
<p>When a connection is dropped, the service sends a "notify" message to the sender and (if appropriate) the accepted receiver, with a &lt;item type='connection' action='drop'/&gt;:</p>
-
+
<example caption='"Connection Dropped" message'><![CDATA[
<message to='receiver@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -609,12 +609,12 @@ confirm: SID00001234
</session>
</message>
]]></example>
-
+
<p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
</section3>
<section3 topic='Session Deleted'>
<p>When a session is deleted, any clients connected to the session are immediately disconnected. The "notify" message is sent to the sender and any receivers still connected, with the &lt;session action="notify"/&gt; containing an &lt;item type="status"/&gt;:</p>
-
+
<example caption='"Session Deleted (explicitly)" message'><![CDATA[
<message to='sender@domain/res' from='jobs.domain'>
<session xmlns='http://jabber.org/protocol/jobs'
@@ -636,7 +636,7 @@ confirm: SID00001234
</session>
</message>
]]></example>
-
+
<p>The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.</p>
</section3>
</section2>
@@ -922,7 +922,7 @@ confirm: SID00001234
<td>The JOBS service cannot accept any additional sessions at this time. Future requests may be accepted.</td>
</tr>
</table>
-
+
<table caption='&lt;session action="delete"/&gt; errors'>
<tr>
<th>Code</th>
diff --git a/xep-0043.xml b/xep-0043.xml
index 7624ad7..21b0cc0 100644
--- a/xep-0043.xml
+++ b/xep-0043.xml
@@ -40,7 +40,7 @@
<p>Accessing a RDBMS in a generic fashion is a complex and difficult
task. Consequently, this will not be an attempt to XMLize a generic
Database API or query language. Instead, it will providing a
- simple mechanism for a JID to read/write data that it has access to
+ simple mechanism for a JID to read/write data that it has access to
and specifying a model for those schemas to use in xml.</p>
<p>This document has two aims.</p>
<ol>
@@ -48,8 +48,8 @@
<li>Perform near SQL-like data manipulation</li>
</ol>
<p>Although designed for use with an RDBMS this document is not
- restricted to such uses. It may be used with any data storage
- system that can be broken down to a simple table, column/row
+ restricted to such uses. It may be used with any data storage
+ system that can be broken down to a simple table, column/row
format. for example comma delimited files.</p>
</section1>
<section1 topic='Prerequisites'>
@@ -57,9 +57,9 @@
must be aware of the following.</p>
<section2 topic='Namespace'>
- <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
+ <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
will be used until this becomes a jep. Once officially accepted as
- a jep and approved as final by the council, it will become
+ a jep and approved as final by the council, it will become
<link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
</section2>
<section2 topic='Elements'>
@@ -132,45 +132,45 @@
&lt;/database&gt;
</code>
- <p>All examples will assume the existence of the following rdbms setup. A
+ <p>All examples will assume the existence of the following rdbms setup. A
database named 'testdb' with tables created with following SQL
script:</p>
-
+
<code>
- create table tbl_one
- (
- a_int int,
- a_float float,
- a_char char(10)
+ create table tbl_one
+ (
+ a_int int,
+ a_float float,
+ a_char char(10)
)
- create table tbl_two
- (
- a_date datetime,
- a_numeric numeric(9,3)
+ create table tbl_two
+ (
+ a_date datetime,
+ a_numeric numeric(9,3)
)
</code>
</section2>
-</section1>
+</section1>
<section1 topic='Usage'>
<section2 topic='Requesting Schemas'>
<example caption='A simple schema request'>
&lt;iq id="001" to="db.host" type="get"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;/iq&gt;
</example>
-
+
<p>This is a simple request to discover what tables/procedures
- exist on the database testdb. And what permissions are available
- to the user. All schema requests will respond within the scope that
+ exist on the database testdb. And what permissions are available
+ to the user. All schema requests will respond within the scope that
was asked for. This is to prevent unnecessary data from flooding
the network. So the response for the above request would look
- something like:</p>
-
+ something like:</p>
+
<example caption='Response to a schema request'>
&lt;iq id="001" type="result" from="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" permission="both"/&gt;
@@ -178,72 +178,72 @@
&lt;/database&gt;
&lt;/iq&gt;
</example>
-
- <p>The response is scoped to only the 'children' of the request.
- Since the request was for the testdb database, only the tables
- within that database were returned in the result. The reason for
- the limitation is to prevent excessively large packets from filling
+
+ <p>The response is scoped to only the 'children' of the request.
+ Since the request was for the testdb database, only the tables
+ within that database were returned in the result. The reason for
+ the limitation is to prevent excessively large packets from filling
the network from large schemas.</p>
-
+
<p>The response indicates that the user has both read and write
- permissions on the table 'tbl_one' and only read permissions on
- the table 'tbl_two'. Consequently, the user may only perform get
+ permissions on the table 'tbl_one' and only read permissions on
+ the table 'tbl_two'. Consequently, the user may only perform get
requests on 'tbl_two'.</p>
-
+
<example caption='Request detailed table schema'>
-&lt;iq id="002" type="get" to="db.host"&gt;
- &lt;database
+&lt;iq id="002" type="get" to="db.host"&gt;
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
&lt;/database&gt;
&lt;/iq&gt;
</example>
-
+
<p>The response would look like:</p>
<example caption='Response to detailed request'>
-&lt;iq id="002" type="result" from="db.host"&gt;
- &lt;database
+&lt;iq id="002" type="result" from="db.host"&gt;
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
- &lt;table name="tbl_one" permission="both"&gt;
+ &lt;table name="tbl_one" permission="both"&gt;
&lt;col name="a_int" type="int"/&gt;
&lt;col name="a_float" type="float"/&gt;
&lt;col name="a_char" type="char" size="10"/&gt;
&lt;/table&gt;
&lt;/database&gt;
-&lt;/iq&gt;
+&lt;/iq&gt;
</example>
-
+
<p>The schema response for tbl_one is quite intuitive. Three
- columns exist, one called a_int of type int (integer), another
- a_float of type float and a third called a_char of type char
+ columns exist, one called a_int of type int (integer), another
+ a_float of type float and a third called a_char of type char
with a size of ten characters.</p>
-
+
</section2>
<section2 topic='Manipulating Data'>
-
+
<p>Manipulation of data (select, insert, update, delete) will
- definitely not be elegant or easy. SQL allows for some fairly
- complex queries on any fully functional RDBMS. Consequently,
- the data manipulation will be relatively limited since it is
+ definitely not be elegant or easy. SQL allows for some fairly
+ complex queries on any fully functional RDBMS. Consequently,
+ the data manipulation will be relatively limited since it is
not a goal to translate SQL into xml.</p>
-
+
<section3 topic='Selects'>
<p>To indicate a select like query, specify an &lt;iq&gt; of
- type get. The table that the query is to be performed against
- must be specified. The columns that are to be returned in
- the result set must be scoped within the relative table.
- Any attribute on the &lt;col&gt; element besides name will be
- ignored. e.g. it is not required nor recommended to specify
+ type get. The table that the query is to be performed against
+ must be specified. The columns that are to be returned in
+ the result set must be scoped within the relative table.
+ Any attribute on the &lt;col&gt; element besides name will be
+ ignored. e.g. it is not required nor recommended to specify
the data types or the sizes while performing a get.</p>
-
+
<example caption='Basic select'>
&lt;iq id="003" type="get" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -258,14 +258,14 @@
select a_int, a_float, a_char
from tbl_one
</example>
-
- <p>It is also possible to specify a limit on the number of rows
- returned in the result set by specifying a value for the limit
+
+ <p>It is also possible to specify a limit on the number of rows
+ returned in the result set by specifying a value for the limit
attribute.</p>
-
+
<example caption='Basic select with limit'>
&lt;iq id="003" type="get" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" limit="2"&gt;
@@ -278,17 +278,17 @@
</example>
<p>In this case a limit of two rows will be returned in the result set.</p>
-
+
<p> The result set which is returned will contain all the rows
that met the criteria of the select. There is no schema
- information beyond the column names included in the result set.
- Each 'row' in the result set is scoped within the corresponding
+ information beyond the column names included in the result set.
+ Each 'row' in the result set is scoped within the corresponding
&lt;table&gt; element. This allows for queries on multiple
tables to be used in one &lt;iq&gt; packet.</p>
<example caption='Response to basic select'>
&lt;iq id="003" type="result" from="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -307,13 +307,13 @@
</section3>
<section3 topic='Constraining Result Sets'>
- <p>It would be impractical to request the entire contents of the
- table every time you needed one row or a subset of the data. You
+ <p>It would be impractical to request the entire contents of the
+ table every time you needed one row or a subset of the data. You
can constrain the result set by specifying a where clause.</p>
<example caption='Select with constraints'>
&lt;iq id="004" type="get" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -332,10 +332,10 @@
select a_int, a_float, a_char from tbl_one
where a_int = 1234 and a_float &lt; 200.00
</example>
-
- <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
+
+ <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;=</p>
<ul>
@@ -354,13 +354,13 @@
<li>not - to negate a result</li>
<li>or - logical OR ||</li>
<li>and - logical AND &amp;&amp;</li>
- </ul>
+ </ul>
<p><strong>Result</strong></p>
<example caption='Response to select with constraints'>
&lt;iq id="003" type="result" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -375,17 +375,17 @@
<section3 topic='Inserts'>
<p>Inserting or altering the stored data in anyway requires
- setting the type attribute to a value of set. This indicates
+ setting the type attribute to a value of set. This indicates
that the user wants to perform a 'insert/update'. The
- differentiating factor between an insert and an update operation
+ differentiating factor between an insert and an update operation
is whether a &lt;where&gt; element is used. If there is no
-&lt;where&gt; element then it must be interpreted as an insert.
+&lt;where&gt; element then it must be interpreted as an insert.
If a &lt;where&gt; element does exist, then it must be
interpreted as an update.</p>
<example caption='Inserting data'>
&lt;iq id="004" type="set" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -408,14 +408,14 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<p><strong>Result</strong></p>
<p> If there is no result set for the query, as in an update,
- insert, delete, then the response must indicate success or
+ insert, delete, then the response must indicate success or
failure within the &lt;table&gt; element scope. An empty
-&lt;table&gt; element indicates success, and a &lt;table&gt;
+&lt;table&gt; element indicates success, and a &lt;table&gt;
element containing an &lt;error&gt; element indicates a failure.</p>
<example caption='Response to data insert'>
&lt;iq id="004" type="result" from="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@@ -425,10 +425,10 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/database&gt;
&lt;/iq&gt;
</example>
-
- <p> The insert into tbl_one succeeded since the response has an
- empty &lt;table&gt; element. However, the insert into tbl_two
- failed with a permission denied error. Which is indicated with a
+
+ <p> The insert into tbl_one succeeded since the response has an
+ empty &lt;table&gt; element. However, the insert into tbl_two
+ failed with a permission denied error. Which is indicated with a
non-empty &lt;table&gt; element.</p>
</section3>
@@ -439,7 +439,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Updating'>
&lt;iq id="005" type="set" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -452,7 +452,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/iq&gt;
SQL Syntax:
- update tbl_one
+ update tbl_one
set a_char = 'aaaaaaaaaa'
where a_int = 1234
</example>
@@ -464,7 +464,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Response to update'>
&lt;iq id="005" type="result" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@@ -476,12 +476,12 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<section3 topic='Deletes'>
<p> If the type attribute has a value of set and there are no
- &lt;col&gt; elements scoped within the &lt;table&gt; element,
+ &lt;col&gt; elements scoped within the &lt;table&gt; element,
then the query must be interpreted as a delete.</p>
<example caption='Simple delete'>
&lt;iq id="006" type="set" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"&gt;
@@ -497,13 +497,13 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</example>
<p><strong>Result</strong></p>
-
+
<p>Again, if a result set is not generated by a query, then
success or failure must be indicated by the &lt;table&gt; element</p>
<example caption='Response to delete'>
&lt;iq id="006" type="result" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one"/&gt;
@@ -514,35 +514,35 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</section2>
<section2 topic='Procedures'>
- <p> Procedures, or stored procedures <note>Apparently procedures
- are not as common in RDBMS as I thought. Postgres and MySQL have
- functions, but not procedures. So until I, or someone else,
- researches this issue this feature is on hold.</note>
-, are often handy to make frequently used sql queries execute faster.
- These are simply queries stored in a precompiled form and given a
- name with a list of parameters. Each RDBMS handles procedures
- differently, but the common characteristics are that they are
+ <p> Procedures, or stored procedures <note>Apparently procedures
+ are not as common in RDBMS as I thought. Postgres and MySQL have
+ functions, but not procedures. So until I, or someone else,
+ researches this issue this feature is on hold.</note>
+, are often handy to make frequently used sql queries execute faster.
+ These are simply queries stored in a precompiled form and given a
+ name with a list of parameters. Each RDBMS handles procedures
+ differently, but the common characteristics are that they are
stored server side and have in/out parameters.</p>
- <p> The &lt;proc&gt; element will be used to indicate a procedure.
- It has similar characteristics to the &lt;table&gt; element. The
- core differences are that the &lt;col&gt; elements have permissions
- and a &lt;result&gt; element can be used to indicate the value
+ <p> The &lt;proc&gt; element will be used to indicate a procedure.
+ It has similar characteristics to the &lt;table&gt; element. The
+ core differences are that the &lt;col&gt; elements have permissions
+ and a &lt;result&gt; element can be used to indicate the value
returned by the procedure.</p>
- <p> The permission attribute on a &lt;col&gt; element is used to
+ <p> The permission attribute on a &lt;col&gt; element is used to
indicate whether the parameter is in (read), out (write) or in/out (both). </p>
-
- <p> The only result set acceptable from a procedure is that of the
+
+ <p> The only result set acceptable from a procedure is that of the
parameters or &lt;col&gt; element. If the procedure produces a
result set outside of the parameters this should be ignored.</p>
</section2>
<section2 topic='Errors'>
- <p> The server must be able to let the client know when an error
+ <p> The server must be able to let the client know when an error
occurs, instead of just being silent.</p>
-
+
<table caption='Error Codes'>
<tr>
<th>Code</th>
@@ -558,49 +558,49 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<tr>
<td>398</td>
<td>Invalid Table Name</td>
- <td>Returned when the client has requested information from a
+ <td>Returned when the client has requested information from a
table/procedure which does not exist according to the component.</td>
</tr>
<tr>
<td>397</td>
<td>Invalid Column Name</td>
- <td>Returned when the client has requested information from a
+ <td>Returned when the client has requested information from a
column which does not exist according to the component.</td>
</tr>
<tr>
<td>380</td>
<td>Permission Denied on Table</td>
- <td>Returned when the requested action is not allowed for the
+ <td>Returned when the requested action is not allowed for the
user on the table</td>
</tr>
<tr>
<td>401</td>
<td>Access Denied</td>
- <td>Returned when the user does not have permission to use the
+ <td>Returned when the user does not have permission to use the
component.</td>
</tr>
</table>
- <p>If the user requests an action on a table which they do not have
+ <p>If the user requests an action on a table which they do not have
permission to do the following should be returned</p>
-
+
<example caption='Permission denied error'>
&lt;iq id="004" type="error" from="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_two"&gt;
&lt;error code="380"&gt;permission denied on table&lt;/error&gt;
&lt;/table&gt;
&lt;/database&gt;
- &lt;/iq&gt;
+ &lt;/iq&gt;
</example>
<p>If the user is not allowed to access the component the following should be returned</p>
<example caption='General access denied'>
&lt;iq id="004" type="error" from="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;error code="401"&gt;Access Denied&lt;/error&gt;
@@ -610,24 +610,24 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</section2>
<section2 topic='Optional Features'>
- <p> There are requirements which can be provided by other jabber
- components/namespaces, namely the jabber:iq:browse namespace
- in-place of Version Negotiation. Due to the inherent limitations
- of the above data retrieval mechanisms more sophisticated querying
- techniques might be desired. The &lt;query&gt; element will extend
+ <p> There are requirements which can be provided by other jabber
+ components/namespaces, namely the jabber:iq:browse namespace
+ in-place of Version Negotiation. Due to the inherent limitations
+ of the above data retrieval mechanisms more sophisticated querying
+ techniques might be desired. The &lt;query&gt; element will extend
the functionality </p>
<section3 topic='Embedded SQL'>
- <p> The abilities described in the Basics section are just that,
- basic. To provide more flexibility and allow for the full power
- of SQL without xmlifying everything, a &lt;sql&gt; element may
+ <p> The abilities described in the Basics section are just that,
+ basic. To provide more flexibility and allow for the full power
+ of SQL without xmlifying everything, a &lt;sql&gt; element may
be implemented to provide this feature.</p>
-
+
<p> The &lt;sql&gt; element must be scoped within the &lt;database&gt; element.</p>
<example caption='Embedded sql query'>
&lt;iq id="007" type="get" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;sql&gt; select a_int, a_float from tbl_one &lt;/sql&gt;
@@ -639,7 +639,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<example caption='Response to embedded query'>
&lt;iq id="007" type="result" to="db.host"&gt;
- &lt;database
+ &lt;database
name="testdb"
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;table name="tbl_one" permission="both"&gt;
@@ -658,38 +658,38 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;/iq&gt;
</example>
- <p> Since SQL is so flexible, the result set schema is not known
- until it is returned as a result of the query. Consequently, it
- must be sent as the first 'row' of the returned result. Each
+ <p> Since SQL is so flexible, the result set schema is not known
+ until it is returned as a result of the query. Consequently, it
+ must be sent as the first 'row' of the returned result. Each
following row will be the actual data queried for.</p>
- <p> If multiple tables are used within one SQL statement, then
- then name attribute within the &lt;table&gt; element can not be
- accurately denoted with a single table name. The best way to deal
- with this situation is to simply use a unique identifier within
- the scope of the &lt;database&gt; element. This will allow for
+ <p> If multiple tables are used within one SQL statement, then
+ then name attribute within the &lt;table&gt; element can not be
+ accurately denoted with a single table name. The best way to deal
+ with this situation is to simply use a unique identifier within
+ the scope of the &lt;database&gt; element. This will allow for
multiple &lt;sql&gt; results to be scoped within the same result.</p>
- </section3>
+ </section3>
<section3 topic='Version Negotiation'>
- <p>It is expected that this protocol will grow and be extended
+ <p>It is expected that this protocol will grow and be extended
to meet various demands. Therefore, version
- negotiation<note>Version Negotiation is being killed since browsing, feature
- negotiation, or disco will be able to perform this function,
- however it might be useful as an optional feature for clients
- that don't implement these yet, especially considering none
- of these have been standardized.</note> will be
+ negotiation<note>Version Negotiation is being killed since browsing, feature
+ negotiation, or disco will be able to perform this function,
+ however it might be useful as an optional feature for clients
+ that don't implement these yet, especially considering none
+ of these have been standardized.</note> will be
incorporated up front.</p>
-
+
<p>When the connection initiator, client end-user or
- server/transport, starts a session, it must first send
- the version number it expects to use, otherwise, behavior
+ server/transport, starts a session, it must first send
+ the version number it expects to use, otherwise, behavior
is undefined.</p>
<code>
&lt;iq id="000" type="get" to="db.host"&gt;
- &lt;database
+ &lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.1&lt;/version&gt;
&lt;/database&gt;
@@ -697,25 +697,25 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</code>
<p>Three responses are possible from the server.</p>
- <ol>
+ <ol>
<li>
<p>It supports that version number and responds with:</p>
<code>
&lt;iq id="000" type="result" from="db.host"&gt;
- &lt;database
+ &lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.1&lt;/version&gt;
&lt;/database&gt;
&lt;/iq&gt;
</code>
<p>The type of 'result' indicates that the version request was
- successful and if the client is satisfied with the version number,
+ successful and if the client is satisfied with the version number,
may continue with schema requests or whatever.</p></li>
-
+
<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
+ &lt;database
xmlns="http://openaether.org/projects/jabber_database.html"/&gt;
&lt;/iq&gt;
</code>
@@ -724,7 +724,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
alternative option.</p>
<code>
&lt;iq id="000" type="error" from="db.host"&gt;
- &lt;database
+ &lt;database
xmlns="http://openaether.org/projects/jabber_database.html"&gt;
&lt;version&gt;0.2&lt;/version&gt;
&lt;/database&gt;
@@ -771,21 +771,21 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
&lt;!ELEMENT result (#PCDATA)&gt;
&lt;!ATTLIST error code CDATA #IMPLIED&gt;
&lt;!ATTLIST database name CDATA #IMPLIED&gt;
-&lt;!ATTLIST table
-name CDATA #IMPLIED
- permission (read | write | both) #IMPLIED
+&lt;!ATTLIST table
+name CDATA #IMPLIED
+ permission (read | write | both) #IMPLIED
limit CDATA #IMPLIED
&gt;
&lt;!ATTLIST proc name CDATA #IMPLIED&gt;
-&lt;!ATTLIST col
- name CDATA #IMPLIED
- size CDATA #IMPLIED
- op (eq | neq | lt | gt | let | get | null) #IMPLIED
- conj (not | or | and ) #IMPLIED
- permission (read | write | both) #IMPLIED
- type (bit | tinyint | integer | utinyint | uinteger |
- float | numeric | date | datetime | timestamp |
- time | char | vchar | text | blob) #IMPLIED
+&lt;!ATTLIST col
+ name CDATA #IMPLIED
+ size CDATA #IMPLIED
+ op (eq | neq | lt | gt | let | get | null) #IMPLIED
+ conj (not | or | and ) #IMPLIED
+ permission (read | write | both) #IMPLIED
+ type (bit | tinyint | integer | utinyint | uinteger |
+ float | numeric | date | datetime | timestamp |
+ time | char | vchar | text | blob) #IMPLIED
&gt;
</code>
</section2>
diff --git a/xep-0046.xml b/xep-0046.xml
index e7c93fa..64332c3 100644
--- a/xep-0046.xml
+++ b/xep-0046.xml
@@ -7,7 +7,7 @@
<xep>
<header>
<title>DTCP</title>
- <abstract>Direct TCP connection between two Jabber entities.</abstract>
+ <abstract>Direct TCP connection between two Jabber entities.</abstract>
&LEGALNOTICE;
<number>0046</number>
<status>Retracted</status>
diff --git a/xep-0047.xml b/xep-0047.xml
index aefa2b4..b871856 100644
--- a/xep-0047.xml
+++ b/xep-0047.xml
@@ -180,7 +180,7 @@
<p>If the responder informs the initiator that it wishes to proceed with the session, the initiator can begin to send data over the bytestream (in addition, because the bytestream is bidirectional, the responder can also send data; see the <link url='#bidi'>Bidirectionality</link> section of this document for details).</p>
<p>Each chunk of data is contained in a &lt;data/&gt; element qualified by the 'http://jabber.org/protocol/ibb' namespace. The data element SHOULD be sent in an IQ stanza to enable proper tracking and throttling, but instead MAY be sent in a message stanza. The data to be sent, prior to base64-encoding and prior to any wrapping in XML, MUST NOT be larger than the 'block-size' determined in the bytestream negotiation.</p>
<example caption='Sending data in an IQ stanza'><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
id='kr91n475'
to='juliet@capulet.com/balcony'
type='set'>
@@ -235,11 +235,11 @@
<iq from='juliet@capulet.com/balcony'
id='us71g45j'
to='romeo@montague.net/orchard'
- type='result'/>
+ type='result'/>
]]></example>
<p>It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an &notfound; error.</p>
<example caption='Recipient does not know about the IBB session'><![CDATA[
-<iq type='error'
+<iq type='error'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
id='us71g45j'>
@@ -260,7 +260,7 @@
<section1 topic='Use of Message Stanzas' anchor='message'>
<p>It is RECOMMENDED to use IQ stanzas when sending data packets. However, an application MAY use message stanzas instead. If message stanzas are used when sending data packets, the sender SHOULD also use &xep0079; or some other stanza flow-control method. For proper tracking of delivery and processing errors related to data packets, the 'id' attribute SHOULD be used with message stanzas.</p>
<example caption='Sending data in a message stanza'><![CDATA[
-<message from='romeo@montague.net/orchard'
+<message from='romeo@montague.net/orchard'
id='dsw71gj3'
to='juliet@capulet.com/balcony'>
<data xmlns='http://jabber.org/protocol/ibb' seq='0' sid='i781hf64'>
@@ -294,7 +294,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
- <p>The &REGISTRAR; includes 'http://jabber.org/protocol/ibb' in its registry of XML namespaces at &NAMESPACES;.</p>
+ <p>The &REGISTRAR; includes 'http://jabber.org/protocol/ibb' in its registry of XML namespaces at &NAMESPACES;.</p>
</section2>
</section1>
diff --git a/xep-0048.xml b/xep-0048.xml
index c657ce8..fd2ca44 100644
--- a/xep-0048.xml
+++ b/xep-0048.xml
@@ -114,7 +114,7 @@
<p>Note: The datatypes are as defined in &w3xmlschema2;.</p>
<example caption='An example of the conference element'><![CDATA[
<storage xmlns='storage:bookmarks'>
- <conference name='Council of Oberon'
+ <conference name='Council of Oberon'
autojoin='true'
jid='council@conference.underhill.org'>
<nick>Puck</nick>
@@ -168,7 +168,7 @@
<publish node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
- <conference name='The Play&apos;s the Thing'
+ <conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@@ -207,7 +207,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
- <conference name='The Play&apos;s the Thing'
+ <conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@@ -226,7 +226,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
- <conference name='The Play&apos;s the Thing'
+ <conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@@ -255,7 +255,7 @@
<items node='storage:bookmarks'>
<item id='current'>
<storage xmlns='storage:bookmarks'>
- <conference name='The Play&apos;s the Thing'
+ <conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
@@ -271,7 +271,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and <cite>XEP-0223</cite>.</p>
- <p>Use of the &lt;password/&gt; child of the &lt;conference/&gt; element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage.</p>
+ <p>Use of the &lt;password/&gt; child of the &lt;conference/&gt; element is NOT RECOMMENDED, since the password could be discovered by a third party, e.g. an eavesdropper (if channel encryption is not used) or a server administrator. However, the element MAY be used in suitably secure environments (e.g., where it is known that communications will not be sent over unencrypted channels and the server administrators are trusted). Clients SHOULD NOT default to storing passwords and MUST enable users to disable any password storage.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
diff --git a/xep-0049.xml b/xep-0049.xml
index 810ac12..f91986d 100644
--- a/xep-0049.xml
+++ b/xep-0049.xml
@@ -112,7 +112,7 @@ SERVER:
from="hamlet@shakespeare.lit/denmark"
to="hamlet@shakespeare.lit/denmark"
id="1001"/>
- ]]></example>
+ ]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[
CLIENT:
diff --git a/xep-0051.xml b/xep-0051.xml
index 4a0453d..6681acd 100644
--- a/xep-0051.xml
+++ b/xep-0051.xml
@@ -74,7 +74,7 @@
<section1 topic='Connection Transfer Protocol' anchor='protocol'>
<p>The transfer packet is addressed to the user from the domain they are logged into, it contains the server address to connect to which can be domain name or ip address, it can also contain an optional port number. There is also the domain specified just in case they have to use a different domain name when they log in or to maintain the original domain.</p>
<example caption='Server tells client to connect to a different server in the cluster (by ip address)'><![CDATA[
-<iq type='set' from='jabber.org' to='user@jabber.org'>
+<iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'>
<domain>jabber.org</domain>
<server>123.123.123.122</server>
@@ -82,7 +82,7 @@
</iq>
]]></example>
<example caption='Server tells client to connect to a different server in the cluster (by domain name)'><![CDATA[
-<iq type='set' from='jabber.org' to='user@jabber.org'>
+<iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'>
<domain>jabber.org</domain>
<server>server2.jabber.org</server>
@@ -90,7 +90,7 @@
</iq>
]]></example>
<example caption='Server tells client to connect to a different server in the cluster (using a different port number)'><![CDATA[
-<iq type='set' from='jabber.org' to='user@jabber.org'>
+<iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'>
<domain>jabber.org</domain>
<server>server3.jabber.org:6222</server>
@@ -98,7 +98,7 @@
</iq>
]]></example>
<example caption='Server tells client to simply reconnect'><![CDATA[
-<iq type='set' from='jabber.org' to='user@jabber.org'>
+<iq type='set' from='jabber.org' to='user@jabber.org'>
<query xmlns='urn:xmpp:cxfr'>
<domain>jabber.org</domain>
<server>jabber.org</server>
diff --git a/xep-0052.xml b/xep-0052.xml
index 064ed04..2235731 100644
--- a/xep-0052.xml
+++ b/xep-0052.xml
@@ -105,7 +105,7 @@
<p>
In order to send a file, the sender must first tell the receiver a little
bit about the file to make sure they will accept it. At the same time they
- list the stream methods they support in the order they wish to use them.
+ list the stream methods they support in the order they wish to use them.
This is done by sending the information in the http://www.jabber.org/protocol/filexfer namespace.
</p>
@@ -113,9 +113,9 @@
&lt;iq type='set' id='ft_1' to='recvr@jabber.org/Home'&gt;
&lt;file xmlns='http://www.jabber.org/protocol/filexfer'
action='offer'
- id='a0'
- name='myfile.txt'
- size='1024'
+ id='a0'
+ name='myfile.txt'
+ size='1024'
mime-type='text/plain'&gt;
&lt;feature xmlns='http://jabber.org/protocol/feature-neg'&gt;
&lt;x xmlns='jabber:x:data'&gt;
@@ -129,7 +129,7 @@
</example>
<p>
- That is the basic request, a more complete requeset with range support is
+ That is the basic request, a more complete requeset with range support is
shown below.
</p>
@@ -137,9 +137,9 @@
&lt;iq type='set' id='ft_1' to='recvr@jabber.org/Home'&gt;
&lt;file xmlns='http://www.jabber.org/protocol/filexfer'
action='offer'
- id='a0'
- name='myfile.txt'
- size='1024'
+ id='a0'
+ name='myfile.txt'
+ size='1024'
mime-type='text/plain'
date='20020412T00:00:00'
hash='23e4ad6b63343b33a333c334'&gt;
@@ -158,7 +158,7 @@
&lt;/file&gt;
&lt;/iq&gt;
</example>
-
+
<p>If a receiver decides to accept an offered file they request it from the sending with an &lt;iq/&gt; type result. The receiver sends back the id of the file being sent, the method they wish to use, and the range they wish to download (if the sender announced support). When range support is being used the receiver MUST specify the length and MAY specify a beginning offset with the acceptance.</p>
<example caption='Request the Offered File'>
@@ -190,7 +190,7 @@
</example>
<p>
- If the receiver decides to not accept the file they SHOULD send back an
+ If the receiver decides to not accept the file they SHOULD send back an
error 403 to the sender.
</p>
@@ -253,7 +253,7 @@
<p>
If the transfer does not complete, for any reason after the meta-data
- negotiation, the party that has the error SHOULD send an error 500 and
+ negotiation, the party that has the error SHOULD send an error 500 and
the file id to the other party.
</p>
@@ -342,7 +342,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 meta-data 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.
@@ -356,7 +356,7 @@
<em>Transfer Failed (500)</em>: If the file transfer fails for any
reason after negotiation, the error generator SHOULD send a 500 error
to the other party. This is the only error message that both the
- sender and reciever may send. The &lt;error/&gt; CDATA MAY contain
+ sender and reciever may send. The &lt;error/&gt; CDATA MAY contain
information about the failure.
</li>
<li>
diff --git a/xep-0054.xml b/xep-0054.xml
index 05730c2..e5283d2 100644
--- a/xep-0054.xml
+++ b/xep-0054.xml
@@ -118,7 +118,7 @@
<EMAIL><INTERNET/><PREF/><USERID>stpeter@jabber.org</USERID></EMAIL>
<JABBERID>stpeter@jabber.org</JABBERID>
<DESC>
- More information about me is located on my
+ More information about me is located on my
personal website: http://www.saint-andre.com/
</DESC>
</vCard>
@@ -225,8 +225,8 @@
]]></example>
<p>In accordance with &xmppcore;, a compliant server MUST respond on behalf of the requestor and not forward the IQ to the requestee's connected resource.</p>
<example caption="Receiving Another User's vCard"><![CDATA[
-<iq from='jer@jabber.org'
- to='stpeter@jabber.org/roundabout'
+<iq from='jer@jabber.org'
+ to='stpeter@jabber.org/roundabout'
type='result'
id='v3'>
<vCard xmlns='vcard-temp'>
@@ -335,7 +335,7 @@ Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment
-on or otherwise explain it or assist in its implmentation
+on or otherwise explain it or assist in its implmentation
may be prepared, copied, published and distributed, in whole
or in part, without restriction of any kind, provided that
the above copyright notice and this paragraph are included
@@ -365,9 +365,9 @@ PARTICULAR PURPOSE.
<!-- ==== -->
<!-- NOTE: the following root element is not used in the
- modified vcard-temp DTD published by the Jabber
+ modified vcard-temp DTD published by the Jabber
project (now XMPP Standards Foundation) and is
- included here only for historical purposes;
+ included here only for historical purposes;
implementations that comply with vcard-temp must
specify the root element as vCard, not xCard. -->
@@ -379,35 +379,35 @@ PARTICULAR PURPOSE.
<!ELEMENT vCard (
(VERSION, FN, N),
(NICKNAME?,
- PHOTO?,
- BDAY?,
- ADR?,
- LABEL?,
- TEL?,
+ PHOTO?,
+ BDAY?,
+ ADR?,
+ LABEL?,
+ TEL?,
EMAIL?,
JABBERID?,
- MAILER?,
- TZ?,
- GEO?,
- TITLE?,
- ROLE?,
- LOGO?,
- AGENT?,
- ORG?,
- CATEGORIES?,
- NOTE?,
- PRODID?,
- REV?,
- SORT-STRING?,
- SOUND?,
- UID?,
- URL?,
- CLASS?,
+ MAILER?,
+ TZ?,
+ GEO?,
+ TITLE?,
+ ROLE?,
+ LOGO?,
+ AGENT?,
+ ORG?,
+ CATEGORIES?,
+ NOTE?,
+ PRODID?,
+ REV?,
+ SORT-STRING?,
+ SOUND?,
+ UID?,
+ URL?,
+ CLASS?,
KEY?,
DESC?
)*)>
- <!-- vCard specification version property.
+ <!-- vCard specification version property.
This MUST be 2.0, if the document conforms to RFC 2426. -->
<!ELEMENT VERSION (#PCDATA)>
@@ -418,7 +418,7 @@ PARTICULAR PURPOSE.
values must be specified as a comma separated
list of values. -->
<!ELEMENT N ( FAMILY?, GIVEN?, MIDDLE?, PREFIX?, SUFFIX?)>
-
+
<!ELEMENT FAMILY (#PCDATA)>
<!ELEMENT GIVEN (#PCDATA)>
<!ELEMENT MIDDLE (#PCDATA)>
@@ -441,21 +441,21 @@ PARTICULAR PURPOSE.
multiple values must be specified as a comma separated list
of values. -->
<!ELEMENT ADR (
- HOME?,
- WORK?,
- POSTAL?,
- PARCEL?,
- (DOM | INTL)?,
- PREF?,
- POBOX?,
- EXTADD?,
- STREET?,
- LOCALITY?,
- REGION?,
- PCODE?,
+ HOME?,
+ WORK?,
+ POSTAL?,
+ PARCEL?,
+ (DOM | INTL)?,
+ PREF?,
+ POBOX?,
+ EXTADD?,
+ STREET?,
+ LOCALITY?,
+ REGION?,
+ PCODE?,
CTRY?
)>
-
+
<!ELEMENT POBOX (#PCDATA)>
<!ELEMENT EXTADD (#PCDATA)>
<!ELEMENT STREET (#PCDATA)>
@@ -466,12 +466,12 @@ PARTICULAR PURPOSE.
<!-- Address label property. -->
<!ELEMENT LABEL (
- HOME?,
- WORK?,
- POSTAL?,
- PARCEL?,
- (DOM | INTL)?,
- PREF?,
+ HOME?,
+ WORK?,
+ POSTAL?,
+ PARCEL?,
+ (DOM | INTL)?,
+ PREF?,
LINE+
)>
@@ -480,19 +480,19 @@ PARTICULAR PURPOSE.
<!-- Telephone number property. -->
<!ELEMENT TEL (
- HOME?,
- WORK?,
- VOICE?,
- FAX?,
- PAGER?,
- MSG?,
- CELL?,
- VIDEO?,
- BBS?,
- MODEM?,
- ISDN?,
- PCS?,
- PREF?,
+ HOME?,
+ WORK?,
+ VOICE?,
+ FAX?,
+ PAGER?,
+ MSG?,
+ CELL?,
+ VIDEO?,
+ BBS?,
+ MODEM?,
+ ISDN?,
+ PCS?,
+ PREF?,
NUMBER
)>
@@ -501,90 +501,90 @@ PARTICULAR PURPOSE.
<!-- Email address property. Default type is INTERNET. -->
<!ELEMENT EMAIL (
- HOME?,
- WORK?,
- INTERNET?,
- PREF?,
- X400?,
+ HOME?,
+ WORK?,
+ INTERNET?,
+ PREF?,
+ X400?,
USERID
)>
<!ELEMENT USERID (#PCDATA)>
-
+
<!-- NOTE: the following element was added by the Jabber
project (now XMPP Standards Foundation) to
handle Jabber IDs; the value must be in the
form of user@host -->
<!ELEMENT JABBERID (#PCDATA)>
-
+
<!-- Mailer (e.g., Mail User Agent Type) property. -->
<!ELEMENT MAILER (#PCDATA)>
-
+
<!-- Time zone's Standard Time UTC offset. Value must be an
ISO 8601 formatted UTC offset. -->
<!ELEMENT TZ (#PCDATA)>
-
+
<!-- Geographical position. Values are the decimal degress of
- LATitude and LONgitude. The value should be specified to
+ LATitude and LONgitude. The value should be specified to
six decimal places.-->
<!ELEMENT GEO (LAT, LON)>
-
+
<!-- Latitude value. -->
<!ELEMENT LAT (#PCDATA)>
-
+
<!-- Longitude value. -->
<!ELEMENT LON (#PCDATA)>
-
+
<!-- Title property. -->
<!ELEMENT TITLE (#PCDATA)>
<!-- Role property. -->
<!ELEMENT ROLE (#PCDATA)>
-
+
<!-- Organization logo property. -->
<!ELEMENT LOGO ((TYPE, BINVAL) | EXTVAL)>
-
+
<!-- Administrative agent property. -->
<!ELEMENT AGENT (vCard | EXTVAL)>
-
+
<!-- Organizational name and units property. -->
<!ELEMENT ORG (ORGNAME, ORGUNIT*)>
-
+
<!ELEMENT ORGNAME (#PCDATA)>
-
+
<!ELEMENT ORGUNIT (#PCDATA)>
-
+
<!-- Application specific categories property. -->
<!ELEMENT CATEGORIES (KEYWORD+)>
-
+
<!ELEMENT KEYWORD (#PCDATA)>
-
+
<!-- Commentary note property. -->
<!ELEMENT NOTE (#PCDATA)>
-
+
<!-- Identifier of product that generated the vCard property. -->
<!ELEMENT PRODID (#PCDATA)>
-
- <!-- Last revised property. The value must be an
+
+ <!-- Last revised property. The value must be an
ISO 8601 formatted UTC date/time. -->
<!ELEMENT REV (#PCDATA)>
-
+
<!-- Sort string property. -->
<!ELEMENT SORT-STRING (#PCDATA)>
-
- <!-- Formatted name pronunciation property. The value is
- either a textual phonetic pronunciation, a BASE64
+
+ <!-- Formatted name pronunciation property. The value is
+ either a textual phonetic pronunciation, a BASE64
encoded binary digital audio pronunciation or a URI to
- an external binary digital audio pronunciation.-->
+ an external binary digital audio pronunciation.-->
<!ELEMENT SOUND (PHONETIC | BINVAL | EXTVAL)>
-
+
<!-- Textual phonetic pronunciation. -->
<!ELEMENT PHONETIC (#PCDATA)>
-
+
<!-- Unique identifier property. -->
<!ELEMENT UID (#PCDATA)>
-
+
<!-- Directory URL property. -->
<!ELEMENT URL (#PCDATA)>
@@ -593,19 +593,19 @@ PARTICULAR PURPOSE.
handle free-form descriptive text. -->
<!ELEMENT DESC (#PCDATA)>
-
+
<!-- Privacy classification property. -->
<!ELEMENT CLASS (PUBLIC | PRIVATE | CONFIDENTIAL)>
-
+
<!ELEMENT PUBLIC EMPTY>
-
+
<!ELEMENT PRIVATE EMPTY>
-
+
<!ELEMENT CONFIDENTIAL EMPTY>
-
+
<!-- Authentication credential or encryption key property. -->
<!ELEMENT KEY (TYPE?, CRED)>
-
+
<!ELEMENT CRED (#PCDATA)>
<!-- ==== -->
diff --git a/xep-0056.xml b/xep-0056.xml
index ee08f44..55736c1 100644
--- a/xep-0056.xml
+++ b/xep-0056.xml
@@ -54,7 +54,7 @@ ANSI X.12, EDIFACT/UN and ebXML are all standards. This document describes a fun
<section1 topic='Transmitting ebXML via XMPP'>
<section2 topic='Introduction to ebXML'>
-<p>EbXML <note><link url='http://www.ebxml.org'>http://www.ebxml.org</link></note>, a subset of XML that is defined through OASIS.org, is quickly becoming a de-facto standard for electronic, unified, inter and intra business process communication and for business process specification. The direct adjacency to UN/CEFACT EDIFACT, especially object-oriented EDI, make the widespread use of ebXML for automatic business transaction negotiation, process definition, etc. quite likely.
+<p>EbXML <note><link url='http://www.ebxml.org'>http://www.ebxml.org</link></note>, a subset of XML that is defined through OASIS.org, is quickly becoming a de-facto standard for electronic, unified, inter and intra business process communication and for business process specification. The direct adjacency to UN/CEFACT EDIFACT, especially object-oriented EDI, make the widespread use of ebXML for automatic business transaction negotiation, process definition, etc. quite likely.
</p>
</section2>
@@ -73,12 +73,12 @@ ebXML Messages SHALL be transmitted within Jabber IQ chunks. The value of the 't
]]></example>
<p>
-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.
+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 it's 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>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>
</section2>
@@ -166,7 +166,7 @@ EDIFACT/UN is very similar to X.12 and differs only in the meaning of tags and i
</section2>
<section2 topic='Protocol'>
-<p>SAP IDocs SHALL be transmitted in a query tag of an IQ chunk. The IQ chunk's type attribute SHALL be 'set. The query's namespace attribute SHALL be set to 'http://jabber.org/protocol/sap_idoc'. The query tag SHALL contain the iDoc, XML aware.
+<p>SAP IDocs SHALL be transmitted in a query tag of an IQ chunk. The IQ chunk's type attribute SHALL be 'set. The query's namespace attribute SHALL be set to 'http://jabber.org/protocol/sap_idoc'. The query tag SHALL contain the iDoc, XML aware.
</p>
</section2>
diff --git a/xep-0057.xml b/xep-0057.xml
index a23d4ac..5ccd980 100644
--- a/xep-0057.xml
+++ b/xep-0057.xml
@@ -7,7 +7,7 @@
<xep>
<header>
<title>Extended Roster</title>
- <abstract>This document defines a way to handle extended roster items.</abstract>
+ <abstract>This document defines a way to handle extended roster items.</abstract>
&LEGALNOTICE;
<number>0057</number>
<status>Retracted</status>
@@ -66,7 +66,7 @@
<section2 topic="Server-side information">
<p>This information is implementation-dependent, so to provide flexibility for it, the <tt>jabber:x:data</tt> namespace defined in &xep0004; must be used. The client can set these parameters by setting this item with this form with <tt>type='submit'</tt>.</p>
<example><![CDATA[<item jid="romeo@montague.net"
- name="Romeo"
+ name="Romeo"
subscription="both">
<x xmlns='jabber:x:data' type='form'>
<field type='list-single' label='Visibility' var='visibility'>
@@ -138,7 +138,7 @@
<example><![CDATA[<iq id="roster_1" type="result">
<query xmlns="jabber:iq:roster">
<item jid="romeo@montague.net"
- name="Romeo"
+ name="Romeo"
category="user"
type="client"
subscription="both">
@@ -162,7 +162,7 @@
</x>
</item>
<item jid="jdev@conference.jabber.org"
- name="Developers Zone"
+ name="Developers Zone"
category="conference"
type="text"
subscription="none">
diff --git a/xep-0058.xml b/xep-0058.xml
index e7a383d..66ffa1e 100644
--- a/xep-0058.xml
+++ b/xep-0058.xml
@@ -96,7 +96,7 @@
8.5. Modifying the Member List
8.6. Granting Moderator Privileges
8.7. Revoking Moderator Privileges
- 8.8. Modifying the Moderator List
+ 8.8. Modifying the Moderator List
...
</text>
</iq>]]></example>
diff --git a/xep-0061.xml b/xep-0061.xml
index 82dd132..810bb38 100644
--- a/xep-0061.xml
+++ b/xep-0061.xml
@@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
- <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
+ <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@@ -37,14 +37,14 @@
</revision>
</header>
<section1 topic='Introduction'>
- <p>A very simple namespace contaning display hints for the content in a message. Can be used for
+ <p>A very simple namespace contaning display hints for the content in a message. Can be used for
person-person collaboration, or by a service managing notes.</p>
</section1>
<section1 topic='Message Extension'>
-<p>Normal messages are sent, with a sharednote namespace extending them hinting to any supporting client on
-how to display the message as a note instead. Any changes to the note within that client should then be sent
-back to the sender, either automatically or when the user saves the note (depending on the update element, by
+<p>Normal messages are sent, with a sharednote namespace extending them hinting to any supporting client on
+how to display the message as a note instead. Any changes to the note within that client should then be sent
+back to the sender, either automatically or when the user saves the note (depending on the update element, by
default on a save action by the user).</p>
<example caption='An Example Shared Note Message'><![CDATA[
@@ -66,7 +66,7 @@ default on a save action by the user).</p>
</message>
]]></example>
-<p>Any element not specified in the note should use the last known setting or client defaults, so that when a
+<p>Any element not specified in the note should use the last known setting or client defaults, so that when a
change is sent, only the changed elements are returned.</p>
</section1>
@@ -75,7 +75,7 @@ change is sent, only the changed elements are returned.</p>
<p>Each thread is a different shared note. Auto updates should use an internal client timer and batch large
changes into chunks, when the user is typing every 5-10 seconds or so. When the user has made changes that
-haven't been sent and an update comes in on the same thread the client should prompt the user with the
+haven't been sent and an update comes in on the same thread the client should prompt the user with the
changes offering to replace or save their changes.</p>
</section1>
diff --git a/xep-0063.xml b/xep-0063.xml
index d536ada..22d9528 100644
--- a/xep-0063.xml
+++ b/xep-0063.xml
@@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
- <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
+ <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@@ -61,7 +61,7 @@
<example caption='Matches all presence packets'><![CDATA[
<presence xmlns='http://jabber.org/protocol/filter/basic'/>
]]></example>
-
+
<example caption='Matches all jabber:iq:version IQ packets'><![CDATA[
<iq xmlns='http://jabber.org/protocol/filter/basic'>jabber:iq:version</iq>
]]></example>
@@ -69,7 +69,7 @@
<example caption='Matches all packets from user@company.com'><![CDATA[
<from xmlns='http://jabber.org/protocol/filter/basic'>user@company.com</from>
]]></example>
-
+
</section1>
<section1 topic='Actions'>
@@ -85,11 +85,11 @@
<example caption='Pretend that we don&apos;t exist'><![CDATA[
<bounce xmlns='http://jabber.org/protocol/filter/basic' code='404'/>
]]></example>
-
+
<example caption='Send a copy to our home account'><![CDATA[
<copy xmlns='http://jabber.org/protocol/filter/basic'>me@home.com</copy>
]]></example>
-
+
</section1>
<section1 topic='Security Considerations'>
diff --git a/xep-0064.xml b/xep-0064.xml
index ebd722c..5aef95f 100644
--- a/xep-0064.xml
+++ b/xep-0064.xml
@@ -30,7 +30,7 @@
<version>0.2</version>
<date>2003-09-30</date>
<initials>psa</initials>
- <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
+ <remark>At the request of the author, changed the status of this document to Deferred pending development of an implementation; also changed the type to Informational.</remark>
</revision>
<revision>
<version>0.1</version>
@@ -56,11 +56,11 @@
<example caption='Matches all messages with that have a subject element'><![CDATA[
<xpath xmlns='http://jabber.org/protocol/filter/xpath'>/message/subject</xpath>
]]></example>
-
+
<example caption='Matches all presence packets that have an x:delay stamp'><![CDATA[
<xpath xmlns='http://jabber.org/protocol/filter/xpath'>/presence/x[namespace-uri()=='jabber:x:delay']</xpath>
]]></example>
-
+
</section1>
<section1 topic='Security Considerations'>
diff --git a/xep-0065.xml b/xep-0065.xml
index 36e716e..2d6ab77 100644
--- a/xep-0065.xml
+++ b/xep-0065.xml
@@ -308,7 +308,7 @@
to='requester@example.com/foo'
type='error'>
<error type='auth'>
- <forbidden
+ <forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -320,7 +320,7 @@
to='requester@example.com/foo'
type='error'>
<error type='auth'>
- <forbidden
+ <forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -332,7 +332,7 @@
to='streamer.example.com'
type='error'>
<error type='cancel'>
- <not-allowed
+ <not-allowed
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -403,7 +403,7 @@ Requester Target
to='requester@example.com/foo'
type='error'>
<error type='modify'>
- <not-acceptable
+ <not-acceptable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -438,7 +438,7 @@ STATUS = X'00'
to='requester@example.com/foo'
type='error'>
<error type='cancel'>
- <item-not-found
+ <item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -741,7 +741,7 @@ DATA = Target or Requester JID
from='streamer.example.com'
to='target@example.org/bar'
id='zy3v29h6'>
- <udpsuccess xmlns='http://jabber.org/protocol/bytestreams'
+ <udpsuccess xmlns='http://jabber.org/protocol/bytestreams'
dstaddr='Value of Hash'/>
</message>
]]></example>
diff --git a/xep-0066.xml b/xep-0066.xml
index f0a8723..f1361fb 100644
--- a/xep-0066.xml
+++ b/xep-0066.xml
@@ -183,11 +183,11 @@
<p>A sample protocol flow is shown below.</p>
<example caption='Stream Initiation Offer'>
<![CDATA[
-<iq type='set'
+<iq type='set'
from='romeo@montague.net/orchard'
to='juliet@capulet.com/chamber'
id='offer1'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@@ -209,7 +209,7 @@
</example>
<example caption='Stream Initiation Result'>
<![CDATA[
-<iq type='result'
+<iq type='result'
from='juliet@capulet.com/chamber'>
to='romeo@montague.net/orchard'
id='offer1'>
diff --git a/xep-0067.xml b/xep-0067.xml
index d251dd7..f370367 100644
--- a/xep-0067.xml
+++ b/xep-0067.xml
@@ -45,7 +45,7 @@
<section1 topic='Introduction'>
<p>
-Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
+Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
</p>
<p>
So, what this document comes down to: it defines the data architecture for stock data and it specifies, that a 'stocks/' node is recommended to exist, which again holds all symbols as subnodes, which again hold either '/realtime', '/bar' or '/news' as subnodes. The 'bar' subnode contains a 'time descriptor' subnode. The sort of the symbols is defined through the service provider, who can i.e. support Y!ahoo finance symbols, (german) WKNs or official stock symbols.
@@ -55,7 +55,7 @@ So, what this document comes down to: it defines the data architecture for stock
<section1 topic="Realtime data distribution">
<p>
-Realtime (or close-to-realtime) full stock value data is distributed to a ticker symbol pub/sub location, in the stocks domain. The share data SHALL contain name, time of last trade, most recent stock value, last trade volume, bid, ask, bid size, ask size of the share. If a value is not available, the value MUST be set to '-1'. Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Realtime share value SHALL be published to a position 'realtime' in the ticker symbol domain.
+Realtime (or close-to-realtime) full stock value data is distributed to a ticker symbol pub/sub location, in the stocks domain. The share data SHALL contain name, time of last trade, most recent stock value, last trade volume, bid, ask, bid size, ask size of the share. If a value is not available, the value MUST be set to '-1'. Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Realtime share value SHALL be published to a position 'realtime' in the ticker symbol domain.
</p>
<example caption='Component distributes realtime share value ticker data'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='set' id='publish1'>
@@ -126,10 +126,10 @@ Realtime (or close-to-realtime) full stock value data is distributed to a ticker
<section1 topic="Distribution of barchart, time framed stock value data ">
<p>Time framed, suitable for barcharts/candle sticks/line diagram, stock value data is distributed to a pub/sub location, the ticker symbol domain in the stocks domain. The share data SHALL contain name, validity time of this data set, open, hi, low, close for this time frame, traded volume in this time span of a share. </p>
<p>If a value is not available, the value MUST be set to '-1'. </p>
-<p>Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Time framed, barcharted share data SHALL be published to a position 'bar' in the ticker symbol domain, the subdomain of this position SHALL be the time span information, time span as stated below. It is up to a component, how to to react on subscriptions in various time spans. Implementations are advised to generate data as according to subscribers demands (subscriptions). Values lower than 0:0:0:0:5:0 are not suitable for most implementations.
+<p>Each of the values is transmitted in a corresponding xml element, as seen below. The data is published to a pub/sub position. Time framed, barcharted share data SHALL be published to a position 'bar' in the ticker symbol domain, the subdomain of this position SHALL be the time span information, time span as stated below. It is up to a component, how to to react on subscriptions in various time spans. Implementations are advised to generate data as according to subscribers demands (subscriptions). Values lower than 0:0:0:0:5:0 are not suitable for most implementations.
</p>
<p>
-The time span SHALL be represented as a string, composed of the amount of years, months, days, hours, minutes, seconds covered by this barchart data set. Time span values SHALL be separated from each other through ':'. A leading zero MAY be attached to digits lower than ten.
+The time span SHALL be represented as a string, composed of the amount of years, months, days, hours, minutes, seconds covered by this barchart data set. Time span values SHALL be separated from each other through ':'. A leading zero MAY be attached to digits lower than ten.
</p>
<example caption='Component distributes realtime barcharted share value ticker data'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='set' id='publish1'>
@@ -165,7 +165,7 @@ Similar to section 2, timeframed data MAY be transmitted in a message element.
Another important part in a stock system is distribution of stock/share specific news.
</p>
<p>
-Stock news are distributed to the pub/sub gateway, to the 'news' location in the ticker symbol subdomain. The stock news are packed in a 'stocknews' chunk. The stocknews chunk contains time, subject, body and source of these news.
+Stock news are distributed to the pub/sub gateway, to the 'news' location in the ticker symbol subdomain. The stock news are packed in a 'stocknews' chunk. The stocknews chunk contains time, subject, body and source of these news.
</p>
<example caption='Component publishes share/stock specific news'><![CDATA[
<iq from='stockgate@way.com' to='publish@gate.way' type='rset' id='publish1'>
diff --git a/xep-0068.xml b/xep-0068.xml
index 6167b4c..eefe04e 100644
--- a/xep-0068.xml
+++ b/xep-0068.xml
@@ -118,14 +118,14 @@
<p>These are forms that do not have a hidden field of name FORM_TYPE.
Existing processing rules still apply.</p>
<example caption='Message with no FORM_TYPE'><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'>
<thread>vote-thread-reatmon-134</thread>
<x xmlns='jabber:x:data' type='form'>
<title>Vote #134</title>
<instructions>
- This is the vote to pick a new mascot.
+ This is the vote to pick a new mascot.
Thanks for your time!
</instructions>
<field var='mascot' type='list-single'>
@@ -156,11 +156,11 @@
<field var="pubsub#node" type="hidden">
<value>generic/pgm-mp3-player</value>
</field>
- <field var="pubsub#subscriber_jid" type="jid-single"
+ <field var="pubsub#subscriber_jid" type="jid-single"
label="Jabber ID of Subscriber">
<value>sub1@foo.com</value>
</field>
- <field var="{http://example.com/pubsub}time_restrictions" type="text-multi"
+ <field var="{http://example.com/pubsub}time_restrictions" type="text-multi"
label="Limit to these time ranges">
<value>09:00-12:00</value>
<value>13:00-17:00</value>
@@ -203,7 +203,7 @@
</iq>
]]></example>
<example caption='Service Returns Registration Form'><![CDATA[
-<iq
+<iq
type='result'
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
@@ -221,35 +221,35 @@
<field
type='hidden'
var='FORM_TYPE'>
- <value>http://jabber.org/protocol/muc#user</value>
+ <value>http://jabber.org/protocol/muc#user</value>
</field>
- <field
+ <field
type='text-single'
label='First Name'
var='muc#user_first'>
<required/>
</field>
- <field
+ <field
type='text-single'
label='Last Name'
var='muc#user_last'>
<required/>
</field>
- <field
+ <field
type='text-single'
label='Desired Nickname'
var='muc#user_roomnick'>
<required/>
</field>
- <field
+ <field
type='text-single'
label='Your URL'
var='muc#user_url'/>
- <field
+ <field
type='text-single'
label='Email Address'
var='muc#user_email'/>
- <field
+ <field
type='text-multi'
label='FAQ Entry'
var='muc#user_faqentry'/>
@@ -258,7 +258,7 @@
</iq>
]]></example>
<example caption='User Submits Registration Form'><![CDATA[
-<iq
+<iq
type='set'
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
@@ -266,7 +266,7 @@
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
- <value>http://jabber.org/protocol/muc#user</value>
+ <value>http://jabber.org/protocol/muc#user</value>
</field>
<field var='muc#user_first'>
<value>Brunhilde</value>
diff --git a/xep-0070.xml b/xep-0070.xml
index 30a5dd9..308776b 100644
--- a/xep-0070.xml
+++ b/xep-0070.xml
@@ -175,11 +175,11 @@ GET https://files.shakespeare.lit:9345/missive.html HTTP/1.1
<example caption='HTTP Server Returns Authenticate Response'><![CDATA[
401 Unauthorized HTTP/1.1
WWW-Authenticate: Basic realm="xmpp"
-WWW-Authenticate: Digest realm="xmpp",
- domain="files.shakespeare.lit",
- stale=false,
- nonce="ec2cc00f21f71acd35ab9be057970609",
- qop="auth",
+WWW-Authenticate: Digest realm="xmpp",
+ domain="files.shakespeare.lit",
+ stale=false,
+ nonce="ec2cc00f21f71acd35ab9be057970609",
+ qop="auth",
algorithm="MD5"
]]></example>
</section2>
@@ -203,13 +203,13 @@ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
<example caption='HTTP Client Makes Digest Authorization Request'><![CDATA[
Authorization: Digest username="juliet@capulet.com",
realm="xmpp",
- nonce="ec2cc00f21f71acd35ab9be057970609",
+ nonce="ec2cc00f21f71acd35ab9be057970609",
uri="missive.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
- opaque="5ccc069c403ebaf9f0171e9517f40e41"
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example>
</section3>
<section3 topic='Additional Authentication Schemes' anchor='http-authz-add'>
@@ -226,9 +226,9 @@ Authorization: Digest username="juliet@capulet.com",
<p>If the JID provided was a full JID, the confirmation request SHOULD be sent in an &IQ; stanza of type "get" whose 'to' attribute is set to the full JID, but MAY be sent in a &MESSAGE; stanza.</p>
<p>If the JID provided was a bare JID, the confirmation request MUST be sent in a &MESSAGE; stanza whose 'to' attribute is set to the bare JID; this enables delivery to the "most available" resource for the user (however "most available" is determined by the XMPP Server). The &MESSAGE; stanza SHOULD include a &THREAD; element for tracking purposes and MAY include a &BODY; element that provides human-readable information or instructions. If it however provides a &BODY;, the server SHOULD be able to handle a plaintext reply from the client, in the case where it does not support this XEP.</p>
<example caption='Confirmation Request Sent via IQ'><![CDATA[
-<iq type='get'
- from='files.shakespeare.lit'
- to='juliet@capulet.com/balcony'
+<iq type='get'
+ from='files.shakespeare.lit'
+ to='juliet@capulet.com/balcony'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
@@ -238,7 +238,7 @@ Authorization: Digest username="juliet@capulet.com",
]]></example>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
- from='files.shakespeare.lit'
+ from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>
@@ -251,7 +251,7 @@ Authorization: Digest username="juliet@capulet.com",
a7374jnjlalasdf82
If you wish to confirm the request, please reply
- to this message by typing "OK". If not, please
+ to this message by typing "OK". If not, please
reply with "No".
</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
@@ -264,16 +264,16 @@ Authorization: Digest username="juliet@capulet.com",
<section2 topic='XMPP Client Confirms Request via XMPP' anchor='xmpp-confirm'>
<p>If the confirmation request was provided via an &IQ; stanza, the XMPP Client MUST respond to the request by sending an &IQ; stanza back to the XMPP Server. If the user wishes to confirm the request, the &IQ; response stanza MUST be of type "result" and MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes):</p>
<example caption='XMPP Client Confirms Request via IQ'><![CDATA[
-<iq type='result'
- from='juliet@capulet.com/balcony'
- to='files.shakespeare.lit'
+<iq type='result'
+ from='juliet@capulet.com/balcony'
+ to='files.shakespeare.lit'
id='ha000'/>
]]></example>
<p>If the user wishes to deny the request, the &IQ; response stanza MUST be of type "error", MAY contain the original &lt;confirm/&gt; child element (although this is not necessary since the XMPP 'id' attribute can be used for tracking purposes), and MUST specify an error, which SHOULD be &notauthorized;:</p>
<example caption='XMPP Client Denies Request via IQ'><![CDATA[
-<iq type='error'
- from='juliet@capulet.com/balcony'
- to='files.shakespeare.lit'
+<iq type='error'
+ from='juliet@capulet.com/balcony'
+ to='files.shakespeare.lit'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
@@ -297,7 +297,7 @@ Authorization: Digest username="juliet@capulet.com",
]]></example>
<p>If the user wishes to deny the request, the &MESSAGE; response stanza MUST be of type "error", MUST mirror the &lt;thread/&gt; ID (if provided by the XMPP Server), MUST contain the original &lt;confirm/&gt; child element, and MUST specify an error, which SHOULD be &notauthorized;:</p>
<example caption='XMPP Client Denies Request via Message'><![CDATA[
-<message type='error'
+<message type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
@@ -342,7 +342,7 @@ Content-Length: 3032
<li>The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).</li>
<li>If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with <cite>RFC 6120</cite>.</li>
<li>If a binding of XMPP to HTTP is used (e.g., as specified in <cite>XEP-0124</cite>), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.</li>
- </ol>
+ </ol>
</section2>
<section2 topic='End-to-End Encryption' anchor='security-e2e'>
<p>For added security, the XMPP Server and XMPP Client may wish to communicate using end-to-end encryption. Methods for doing so are outside the scope of this proposal.</p>
@@ -365,7 +365,7 @@ Content-Length: 3032
targetNamespace='http://jabber.org/protocol/http-auth'
xmlns='http://jabber.org/protocol/http-auth'
elementFormDefault='qualified'>
-
+
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@@ -384,7 +384,7 @@ Content-Length: 3032
</xs:simpleContent>
</xs:complexType>
</xs:element>
-
+
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
diff --git a/xep-0071.xml b/xep-0071.xml
index 84dcf9d..0eabf2d 100644
--- a/xep-0071.xml
+++ b/xep-0071.xml
@@ -313,7 +313,7 @@
</table>
</section2>
<section2 topic='Hypertext Module Definition' anchor='def-hypertext'>
- <p>The Hypertext Module is defined as including the &lt;a/&gt; element only:</p>
+ <p>The Hypertext Module is defined as including the &lt;a/&gt; element only:</p>
<table caption='Defined Hypertext Module Elements and Attributes'>
<tr><th>Element</th><th>Attributes</th></tr>
<tr><td>&lt;a/&gt;</td><td>class, id, title; style; accesskey, charset, href, hreflang, rel, rev, tabindex, type</td></tr>
@@ -372,7 +372,7 @@
<p>For security reasons or because of display constraints, a compliant client MAY choose to display 'alt' text only, not the image itself (for details, see the <link url='#security-code'>Malicious Objects</link> section of this document).</p>
</section2>
<section2 topic='Style Attribute Module Profile' anchor='profile-style'>
- <p>This module MUST be supported in XHTML-IM if possible; although clients written for certain platforms (e.g., console clients, mobile phones, and handheld computers) or for certain classes of users (e.g., text-to-speech clients) might not be able to support all of the recommended styles directly, they SHOULD attempt to emulate or translate the defined style properties into text or other presentation styles that are appropriate for the platform or user base in question.</p>
+ <p>This module MUST be supported in XHTML-IM if possible; although clients written for certain platforms (e.g., console clients, mobile phones, and handheld computers) or for certain classes of users (e.g., text-to-speech clients) might not be able to support all of the recommended styles directly, they SHOULD attempt to emulate or translate the defined style properties into text or other presentation styles that are appropriate for the platform or user base in question.</p>
<p>A full list of recommended style properties is provided below.</p>
<section3 topic='Recommended Style Properties' anchor='profile-style-properties'>
<p><cite>CSS1</cite> defines 42 "atomic" style properties (which are categorized into font, color and background, text, box, and classification properties) as well as 11 "shorthand" properties ("font", "background", "margin", "padding", "border-width", "border-top", "border-right", "border-bottom", "border-left", "border", and "list-style"). Many of these properties are not appropriate for use in text-based instant messaging, for one or more of the following reasons:</p>
@@ -765,30 +765,30 @@ That seems fine to me.
The XHTML user agent conformance requirements say to ignore
elements and attributes you don't understand, to wit:
- 4. If a user agent encounters an element it does
- not recognize, it must continue to process the
- children of that element. If the content is text,
+ 4. If a user agent encounters an element it does
+ not recognize, it must continue to process the
+ children of that element. If the content is text,
the text must be presented to the user.
- 5. If a user agent encounters an attribute it does
- not recognize, it must ignore the entire attribute
+ 5. If a user agent encounters an attribute it does
+ not recognize, it must ignore the entire attribute
specification (i.e., the attribute and its value).
</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
- <p>The <acronym>XHTML</acronym> user agent conformance
- requirements say to ignore elements and attributes
+ <p>The <acronym>XHTML</acronym> user agent conformance
+ requirements say to ignore elements and attributes
you don't understand, to wit:</p>
<ol type='1' start='4'>
<li><p>
- If a user agent encounters an element it does
- not recognize, it must continue to process the
+ If a user agent encounters an element it does
+ not recognize, it must continue to process the
children of that element. If the content is text,
the text must be presented to the user.
</p></li>
<li><p>
- If a user agent encounters an attribute it does
- not recognize, it must ignore the entire attribute
+ If a user agent encounters an attribute it does
+ not recognize, it must ignore the entire attribute
specification (i.e., the attribute and its value).
</p></li>
</ol>
@@ -938,8 +938,8 @@ That seems fine to me.
This schema defines the <html/> element qualified by
the 'http://jabber.org/protocol/xhtml-im' namespace.
The only allowable child is a <body/> element qualified
- by the 'http://www.w3.org/1999/xhtml' namespace. Refer
- to the XHTML-IM schema driver for the definition of the
+ by the 'http://www.w3.org/1999/xhtml' namespace. Refer
+ to the XHTML-IM schema driver for the definition of the
XHTML 1.0 Integration Set.
Full documentation of this Integration Set is contained in
@@ -955,8 +955,8 @@ That seems fine to me.
<xs:element name='html'>
<xs:complexType>
<xs:sequence>
- <xs:element ref='xhtml:body'
- minOccurs='0'
+ <xs:element ref='xhtml:body'
+ minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
@@ -994,7 +994,7 @@ That seems fine to me.
- List
- Image
- Style Attribute
-
+
The Formal Public Identifier (FPI) for this Integration
Set is:
@@ -1011,23 +1011,23 @@ That seems fine to me.
<xs:documentation source="http://www.xmpp.org/extensions/xep-0071.html"/>
</xs:annotation>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkphras-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-blkstruct-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-hypertext-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-image-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlphras-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstruct-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-inlstyle-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-list-1.xsd"/>
- <xs:include
+ <xs:include
schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml-struct-1.xsd"/>
</xs:schema>
@@ -1044,13 +1044,13 @@ That seems fine to me.
<xs:annotation>
<xs:documentation>
- This is the XML Schema module of named XHTML 1.0 content models
- for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging
- marked-up instant messages between entities that conform to
- the Extensible Messaging and Presence Protocol (XMPP). This
- Integration Set includes a subset of the modules defined for
- XHTML 1.0 but does not redefine any existing modules, nor
- does it define any new modules. Specifically, it includes the
+ This is the XML Schema module of named XHTML 1.0 content models
+ for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging
+ marked-up instant messages between entities that conform to
+ the Extensible Messaging and Presence Protocol (XMPP). This
+ Integration Set includes a subset of the modules defined for
+ XHTML 1.0 but does not redefine any existing modules, nor
+ does it define any new modules. Specifically, it includes the
following modules only:
- Structure
@@ -1059,7 +1059,7 @@ That seems fine to me.
- List
- Image
- Style Attribute
-
+
Therefore XHTML-IM uses the following content models:
Block.mix; Block-like elements, e.g., paragraphs
diff --git a/xep-0072.xml b/xep-0072.xml
index 43198ce..2f6b198 100644
--- a/xep-0072.xml
+++ b/xep-0072.xml
@@ -137,18 +137,18 @@
<p>In order to determine whether a potential responding entity supports the SOAP XMPP Binding, a requesting entity SHOULD send a &xep0030; information request to the potential responding entity:</p>
<example caption="Requester queries responder regarding protocol support"><![CDATA[
<iq from='requester@example.com/soap-client'
- to='responder@example.com/soap-server'
+ to='responder@example.com/soap-server'
id='disco1'
- type='get'>
+ type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>If the responding entity supports the SOAP XMPP Binding and the requesting entity is not blocked from communicating with the responding entity, the responding entity MUST include a feature of "http://jabber.org/protocol/soap" in its reply and SHOULD specify a service discovery identity of "automation/soap".</p>
<example caption="Responder replies regarding protocol support"><![CDATA[
-<iq from='responder@example.com/soap-server'
+<iq from='responder@example.com/soap-server'
to='requester@example.com/soap-client'
id='disco1'
- type='result'>
+ type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='automation' type='soap'/>
<feature var='http://jabber.org/protocol/soap'/>
@@ -169,18 +169,18 @@
<example caption="Requesting entity sends IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap1'
- to='responder@example.com/soap-server'
- type='set'>
- <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
+ to='responder@example.com/soap-server'
+ type='set'>
+ <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
- <n:passenger
+ <n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
@@ -208,7 +208,7 @@
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
- </env:Envelope>
+ </env:Envelope>
</iq>
]]></example>
<p>If the responding entity does not support the SOAP XMPP Binding, it SHOULD return a &unavailable; error:</p>
@@ -247,13 +247,13 @@
]]></example>
<p>If the responding entity does not return an error, it MUST respond with an IQ of type "result":</p>
<example caption='Responding entity returns IQ-result'><![CDATA[
-<iq from='responder@example.com/soap-server'
+<iq from='responder@example.com/soap-server'
id='soap1'
- to='requester@example.com/soap-client'
+ to='requester@example.com/soap-client'
type='result'>
- <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
+ <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
- <m:reservation xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -276,7 +276,7 @@
<p:arriving>
<p:airportChoices>JFK LGA EWR</p:airportChoices>
</p:arriving>
- </p:return>
+ </p:return>
</p:itineraryClarification>
</env:Body>
</env:Envelope>
@@ -286,12 +286,12 @@
<example caption="Requesting entity sends another IQ-set"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap2'
- to='responder@example.com/soap-server'
- type='set'>
- <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
+ to='responder@example.com/soap-server'
+ type='set'>
+ <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -367,10 +367,10 @@
<message from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'>
- <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
+ <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -449,10 +449,10 @@
<message from='requester@example.com/soap-client'
id='soap2'
to='responder@example.com/soap-server'>
- <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
+ <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -485,17 +485,17 @@
<example caption="IQ-set with SOAP representation header"><![CDATA[
<iq from='requester@example.com/soap-client'
id='soap2'
- to='responder@example.com/soap-server'
- type='set'>
- <env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
- xmlns:rep='http://www.w3.org/2004/08/representation'
+ to='responder@example.com/soap-server'
+ type='set'>
+ <env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
+ xmlns:rep='http://www.w3.org/2004/08/representation'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<env:Header>
<rep:Representation resource='http://example.org/me.png'>
<rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
</rep:Representation>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -536,8 +536,8 @@
<rep:Representation resource='http://example.org/me.png'>
<rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
</rep:Representation>
- <m:reservation
- xmlns:m="http://travelcompany.example.org/reservation"
+ <m:reservation
+ xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
@@ -592,13 +592,13 @@
</ol>
<p>The following is an example of a WSDL definition for an endpoint that supports the SOAP XMPP binding: a mythical service that translates Shakespearean English into selected modern languages and dialects.</p>
<example caption="Example of WSDL definition for a translation service that supports SOAP over XMPP"><![CDATA[
-<definitions
- name='ShakespeareTranslation'
+<definitions
+ name='ShakespeareTranslation'
targetNamespace='http://www.example.org/services/BabelFishService.wsdl'>
xmlns='http://schemas.xmlsoap.org/wsdl/'
xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/'
xmlns:tns='http://shakespeare.lit/translation.wsdl'>
-
+
<binding name='ShakespeareTranslationSoap' type='tns:TranslationPortType'>
<soap:binding style='document' transport='http://jabber.org/protocol/soap'/>
<operation name='Translate'>
@@ -626,7 +626,7 @@
<section2 topic="Binding Name" anchor='binding-name'>
<p>The SOAP XMPP Binding is identified by the following URI:</p>
<ul>
- <li>http://jabber.org/protocol/soap</li>
+ <li>http://jabber.org/protocol/soap</li>
</ul>
</section2>
<section2 topic="Supported Features" anchor='binding-features'>
@@ -1078,7 +1078,7 @@
<td>&lt;VersionMismatch/&gt;</td>
</tr>
</table>
- <p>Note: When errors are due to the XMPP transport protocol alone and not to the application layer defined by SOAP, errors MUST be reported with standard XMPP error codes only instead of the XMPP &undefined; condition plus application-specific condition.</p>
+ <p>Note: When errors are due to the XMPP transport protocol alone and not to the application layer defined by SOAP, errors MUST be reported with standard XMPP error codes only instead of the XMPP &undefined; condition plus application-specific condition.</p>
</section1>
<section1 topic="Business Rules" anchor='bizrules'>
@@ -1155,7 +1155,7 @@
</section1>
<section1 topic="Implementation Notes" anchor='impl'>
- <p><em>This section is non-normative.</em></p>
+ <p><em>This section is non-normative.</em></p>
<p>An XMPP entity that supports the SOAP XMPP binding could function as a "SOAP intermediary" that hands a SOAP message off to some other deployment for subsequent processing (HTTP, email, a specialized enterprise messaging platform, etc.) rather than functioning as the "ultimate SOAP receiver" for the message (as these terms are defined in Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). If the intended recipient functions as a SOAP intermediary, implementations should be aware that subsequent processing may alter the representation of SOAP messages.</p>
<p>As an example, consider a component that functions as a gateway between XMPP-based and HTTP-based web services. Its purpose might be to mix HTTP and XMPP for web services and to invoke any web services already accessible through HTTP from XMPP clients.</p>
<p><cite>WS-Routing</cite>, whose aim is to dynamically compose SOAP message paths and processing sequences, can be used in order to reference web services outside of an XMPP network from within it. WS-Routing extends SOAP Envelope Headers with the &lt;path/&gt; element, which specifies the following for the message: the sender's URL (&lt;from/&gt;), the final destination's URL (&lt;to/&gt;), a forward (&lt;forward/&gt;) path with an arbitrary number of intermediaries (&lt;via/&gt;), and an optional return path (&lt;reverse/&gt;). Each intermediary MUST process the &lt;path/&gt; header and update it accordingly to the already performed path; moreover it MAY process the Body of the message.</p>
diff --git a/xep-0073.xml b/xep-0073.xml
index 22c46ff..8386755 100644
--- a/xep-0073.xml
+++ b/xep-0073.xml
@@ -110,7 +110,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note: This protocol suite is obsolete. For updated protocol suites, refer to &xep0211; and &xep0212;.</em></p>
- <p>Given the large number of Jabber/XMPP protocols,
+ <p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of &rfc3920; and &rfc3921;. In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas that are too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
@@ -168,9 +168,9 @@
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in <cite>XEP-0078: Non-SASL Authentication</cite> is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see <cite>XEP-0078</cite> regarding the proper order of precedence between SASL authentication and non-SASL authentication).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
- <p>This document requires no interaction with the &REGISTRAR;.</p>
+ <p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>
diff --git a/xep-0074.xml b/xep-0074.xml
index 4545c4e..0aa8ca8 100644
--- a/xep-0074.xml
+++ b/xep-0074.xml
@@ -48,7 +48,7 @@
actor="juliet@capulet.com/church"
oper="uri://capulet.com/inventory#obtain"
target="poison"/>
- </iq>
+ </iq>
]]>
</example>
<p>Here we have the inventory.capulet.com component querying the security component as to whether juliet@ may obtain the requested poison.</p>
@@ -63,7 +63,7 @@
target="poison">
<allowed/>
</acl>
- </iq>
+ </iq>
]]>
</example>
<p>Unfortunately, the response is in the affirmative and the romantic tragedy follows.</p>
@@ -87,7 +87,7 @@
target="poison">
<allowed/>
</acl>
- </iq>
+ </iq>
]]>
</example>
<example caption='Negative response (denied)'>
@@ -101,7 +101,7 @@
target="poison">
<denied/>
</acl>
- </iq>
+ </iq>
]]>
</example>
<example caption='Error response'>
@@ -114,7 +114,7 @@
oper="uri://capulet.com/inventory#obtain"
target="poison"/>
<error code="404">No information available</error>
- </iq>
+ </iq>
]]>
</example>
</section1>
@@ -126,7 +126,7 @@
from="inventory.capulet.com"
type="get" id="1234">
<query xmlns="http://jabber.org/protocol/sac"/>
- </iq>
+ </iq>
]]>
</example>
<p>The to jid must then respond with a list of operations, if the jid supports SAC.</p>
@@ -140,7 +140,7 @@
<oper uri="uri://capulet.com/inventory#add"/>
<oper uri="uri://capulet.com/inventory#remove"/>
</query>
- </iq>
+ </iq>
]]>
</example>
</section1>
@@ -151,7 +151,7 @@
<p>To follow.</p>
</section1>
<section1 topic='IANA Considerations'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>As a result of this document, the &REGISTRAR; will need to register the 'http://jabber.org/protocol/sac' namespace.</p>
diff --git a/xep-0075.xml b/xep-0075.xml
index 76b46b7..821493d 100644
--- a/xep-0075.xml
+++ b/xep-0075.xml
@@ -430,7 +430,7 @@
used to describe the attribute in multiple languages
(differentiated using the 'xml:lang' attribute).</li>
</ul>
- <p>The attribute definitions returned to a client should
+ <p>The attribute definitions returned to a client should
include only attributes the user is authorized to access.</p>
</section3>
<section3 topic='Method Definitions'>
@@ -447,7 +447,7 @@
<li>One or more strings of descriptive text, indicating the
use and behavior of this method.</li>
</ul>
- <p>The method definitions returned to a client should
+ <p>The method definitions returned to a client should
include only methods the user is authorized to access.</p>
</section3>
<section3 topic='Class References'>
@@ -674,7 +674,7 @@
id='joap_read_1'
from='Station@trainset.example.com/Paddington'
to='Client@example.com'>
- <read xmlns='jabber:iq:joap'>
+ <read xmlns='jabber:iq:joap'>
<attribute>
<name>name</name>
<value>Paddington Station</value>
@@ -726,7 +726,7 @@
id='joap_read_2'
from='Train@trainset.example.com/38'
to='Client@example.com'>
- <read xmlns='jabber:iq:joap'>
+ <read xmlns='jabber:iq:joap'>
<attribute>
<name>location</name>
<value>Station@trainset.example.com/Paddington</value>
@@ -742,7 +742,7 @@
<value>BoxCar@trainset.example.com/212</value>
<value>Caboose@trainset.example.com/9</value>
</data>
- </array>
+ </array>
</value>
</attribute>
</read>
@@ -1620,7 +1620,7 @@
minOccurs='1' maxOccurs='1' />
<element name='desc' type='joap:Description'
minOccurs='0' maxOccurs='unbounded' />
- </sequence>
+ </sequence>
</complexType>
</element>
</sequence>
@@ -1799,7 +1799,7 @@
PassengerCar: Car
passengers: i4
-
+
Building:
name: string
size: struct (length: i4, width: i4)
@@ -1808,12 +1808,12 @@
previous: TrackSegment
next: TrackSegment
- Switch:
+ Switch:
in: TrackSegment
out: TrackSegment[]
boolean switchTo(TrackSegment)
- Station: TrackSegment, Building
+ Station: TrackSegment, Building
]]></example>
</section1>
</xep>
diff --git a/xep-0076.xml b/xep-0076.xml
index 0f29979..9655359 100644
--- a/xep-0076.xml
+++ b/xep-0076.xml
@@ -43,9 +43,9 @@
</section1>
<section1 topic='Use Cases'>
<section2 topic='Evil Messages'>
- <p>If an evil entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p>
+ <p>If an evil entity sends an evil message, it MUST include an appropriately namespaced extension in the message stanza:</p>
<example caption='Evil Entity Sends Evil Message'><![CDATA[
-<message
+<message
from='iago@shakespeare.lit/pda'
to='emilia@shakespeare.lit/mobile'>
<body>
@@ -57,7 +57,7 @@
]]></example>
</section2>
<section2 topic='Evil Presence'>
- <p>If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p>
+ <p>If an evil entity sends evil presence information, it MUST include an appropriately namespaced extension in the presence stanza:</p>
<example caption='Evil Entity Sends Evil Presence'><![CDATA[
<presence from='iago@shakespeare.lit/pda'>
<show>dnd</show>
@@ -67,7 +67,7 @@
]]></example>
</section2>
<section2 topic='Evil IQs'>
- <p>If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p>
+ <p>If an evil entity provides evil information in an IQ exchange, it MUST include an appropriately namespaced extension in the IQ stanza:</p>
<example caption='Evil Entity Sends Evil Message'><![CDATA[
<iq from='iago@shakespeare.lit/pda'
id='evil1'
@@ -108,7 +108,7 @@
<p>Because the 'http://jabber.org/protocol/evil' namespace flags an XML stanza as malicious, it is critically important that an entity appropriately process an XML stanza that contains the evil extension. Mission-critical applications SHOULD ignore any stanzas tagged with the evil extension. Evil servers MAY pass through evil stanzas unmodified. Really evil servers MAY silently delete the evil extension. Entities that are evil to the core SHOULD support channel-level evil as defined in RFC 3514, since this document defines per-stanza evil only.</p>
</section1>
<section1 topic='IANA Considerations'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall register the 'http://jabber.org/protocol/evil' namespace as a result of this document.</p>
diff --git a/xep-0077.xml b/xep-0077.xml
index 7949068..f64940c 100644
--- a/xep-0077.xml
+++ b/xep-0077.xml
@@ -839,10 +839,10 @@ xmpp:marlowe.shakespeare.lit?unregister
xmlns='jabber:iq:register'
elementFormDefault='qualified'>
- <xs:import
+ <xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>
- <xs:import
+ <xs:import
namespace='jabber:x:oob'
schemaLocation='http://www.xmpp.org/schemas/x-oob.xsd'/>
diff --git a/xep-0078.xml b/xep-0078.xml
index 371b139..cb7500b 100644
--- a/xep-0078.xml
+++ b/xep-0078.xml
@@ -309,11 +309,11 @@
<xs:annotation>
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
- protocol has been superseded by SASL Authentication as
+ protocol has been superseded by SASL Authentication as
defined in RFC 3920 and RFC 6120, and is now obsolete.
- For historical purposes, the protocol documented by this
- schema is defined in XEP-0078:
+ For historical purposes, the protocol documented by this
+ schema is defined in XEP-0078:
http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>
@@ -348,11 +348,11 @@
<xs:annotation>
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
- protocol has been superseded by SASL Authentication as
+ protocol has been superseded by SASL Authentication as
defined in RFC 3920 and RFC 6120, and is now obsolete.
- For historical purposes, the protocol documented by this
- schema is defined in XEP-0078:
+ For historical purposes, the protocol documented by this
+ schema is defined in XEP-0078:
http://www.xmpp.org/extensions/xep-0078.html
</xs:documentation>
diff --git a/xep-0079.xml b/xep-0079.xml
index 2348afe..c16b254 100644
--- a/xep-0079.xml
+++ b/xep-0079.xml
@@ -1070,7 +1070,7 @@
is "forward" and the message can be forwarded to another XMPP
address, (3) the value is "gateway" and the message can be sent
to a non-XMPP address via a gateway, (4) the value is "none" and
- the message cannot be delivered at all, or (5) the value is
+ the message cannot be delivered at all, or (5) the value is
"stored" and the message can be stored for later delivery.
</processing>
<doc>XEP-0079</doc>
@@ -1177,7 +1177,7 @@
targetNamespace='http://jabber.org/protocol/amp'
xmlns='http://jabber.org/protocol/amp'
elementFormDefault='qualified'>
-
+
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@@ -1196,7 +1196,7 @@
<xs:attribute name='to' use='optional' type='xs:string'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='invalid-rules'>
<xs:complexType>
<xs:sequence>
@@ -1241,7 +1241,7 @@
targetNamespace='http://jabber.org/protocol/amp#errors'
xmlns='http://jabber.org/protocol/amp#errors'
elementFormDefault='qualified'>
-
+
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
diff --git a/xep-0080.xml b/xep-0080.xml
index 08632cf..bace23d 100644
--- a/xep-0080.xml
+++ b/xep-0080.xml
@@ -156,7 +156,7 @@
<li>It shall be possible to encapsulate location in terms of Global Positioning System (GPS) coordinates as well as civil location (city, street, building, etc.).</li>
<li>The GPS encoding mechanism shall have a single set of units, so that receivers do not need to use heuristics to determine an entity's position.</li>
<li>It shall be possible to specify the known amount of error in the GPS coordinates.</li>
- <li>It shall be possible to include a natural-language description of the location.</li>
+ <li>It shall be possible to include a natural-language description of the location.</li>
</ul>
</section1>
<section1 topic='Data Format' anchor='format'>
@@ -337,7 +337,7 @@
</iq>
]]></example>
<example caption='Subscriber receives event with payload'><![CDATA[
-<message from='portia@merchantofvenice.lit'
+<message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
@@ -356,7 +356,7 @@
]]></example>
<p>In order to indicate that the user is no longer publishing any location information, the user's client shall send an empty &lt;geoloc/&gt; element, which can be considered a "stop command" for geolocation:</p>
<example caption='User stops publishing geolocation information'><![CDATA[
-<iq from='portia@merchantofvenice.lit/pda'
+<iq from='portia@merchantofvenice.lit/pda'
id='publish2'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@@ -369,7 +369,7 @@
</iq>
]]></example>
<example caption='Subscriber receives empty event'><![CDATA[
-<message from='portia@merchantofvenice.lit'
+<message from='portia@merchantofvenice.lit'
to='bassanio@merchantofvenice.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/geoloc'>
@@ -436,8 +436,8 @@
<td align='center'>&lt;Street/&gt;
<note>The IMPS specification also enables one to define an intersection (e.g., "Broadway and 34th Street") as the combination of a &lt;Crossing1/&gt; element (e.g., "Broadway") and a &lt;Crossing2/&gt; element (e.g., "34th Street"). To map from IMPS to XMPP, an application SHOULD map such a combination to one XMPP &lt;street/&gt; element.</note>
</td>
- <td align='center'>&lt;A6/&gt;
- <note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to XMPP, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one XMPP &lt;street/&gt; element.</note>
+ <td align='center'>&lt;A6/&gt;
+ <note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to XMPP, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;STREET/&gt;</td>
</tr>
@@ -512,9 +512,9 @@
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
-<xs:schema
+<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
- targetNamespace='http://jabber.org/protocol/geoloc'
+ targetNamespace='http://jabber.org/protocol/geoloc'
xmlns='http://jabber.org/protocol/geoloc'
elementFormDefault='qualified'>
diff --git a/xep-0081.xml b/xep-0081.xml
index 501e950..ad01ac3 100644
--- a/xep-0081.xml
+++ b/xep-0081.xml
@@ -59,7 +59,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The value of a URI scheme (see &rfc3986;) for Jabber/XMPP communications has long been recognized within the Jabber community, and such a scheme has been formally defined in &rfc5122; as a way of identifying entities that adhere to &xmppcore; or its antecedents. Unfortunately, URI schemes are slow to be accepted on the Internet, such that it might be years (if ever) before widely deployed software such as web browsers will support addresses of the form &lt;xmpp:user@domain&gt;.</p>
- <p>Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach
+ <p>Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach
<note>See, for instance, &lt;<link url='http://www.mozilla.org/docs/web-developer/mimetypes.html'>http://www.mozilla.org/docs/web-developer/mimetypes.html</link>&gt; for information about MIME support in the Mozilla family of web browsers.</note>
is to define a MIME type (in accordance with &rfc2045;) and then reconfigure the relevant server and client software to correctly handle the new MIME type.</p>
<p>Therefore, this document defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.</p>
@@ -76,10 +76,10 @@
<ul>
<li>Join a groupchat room.</li>
<li>Register with a service.</li>
- <!--
+ <!--
<li>Send a &xep0030; request.</li>
<li>Search a user directory (see &xep0055;).</li>
- <li>Request another user's vCard.</li>
+ <li>Request another user's vCard.</li>
-->
</ul>
<p>These use cases are defined below.</p>
@@ -203,19 +203,19 @@ Optional parameters: (charset) Same as charset parameter of
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023; per Section 11.5
of RFC 3920, the encoding must be UTF-8.
-Security considerations: All of the security considerations
- specified in RFC 3023 and RFC 3920 apply to this XML media
+Security considerations: All of the security considerations
+ specified in RFC 3023 and RFC 3920 apply to this XML media
type. Refer to Section 11 of XSF XEP-0081.
Interoperability considerations: (none)
Specification: XSF XEP-0081
Applications which use this media type: non-XMPP applications
(e.g., web browsers or email clients) that wish to invoke
- XMPP-compliant applications for instant messaging and
+ XMPP-compliant applications for instant messaging and
presence functionality.
-Additional information: This media type is not to be confused
- with the "application/xmpp+xml" media type, which is for
+Additional information: This media type is not to be confused
+ with the "application/xmpp+xml" media type, which is for
use by native XMPP applications.
-Person and email address to contact for further information:
+Person and email address to contact for further information:
XMPP Registrar, <registrar@xmpp.org>
Intended usage: COMMON
Author/Change controller: XSF, XMPP Registrar
diff --git a/xep-0084.xml b/xep-0084.xml
index a0f6095..9507baa 100644
--- a/xep-0084.xml
+++ b/xep-0084.xml
@@ -263,9 +263,9 @@
]]></example>
<p>The PEP service running at the user's server then SHOULD return the avatar data.</p>
<example caption='PEP service returns avatar data'><![CDATA[
-<iq type='result'
- from='juliet@capulet.lit'
- to='romeo@montague.lit/home'
+<iq type='result'
+ from='juliet@capulet.lit'
+ to='romeo@montague.lit/home'
id='retrieve1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:avatar:data'>
diff --git a/xep-0085.xml b/xep-0085.xml
index cf3e0dd..3eaed01 100644
--- a/xep-0085.xml
+++ b/xep-0085.xml
@@ -314,7 +314,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<section1 topic='A Simple Example' anchor='example-basic'>
<p>In the following conversation, both User &lt;bernardo@shakespeare.lit&gt; and Contact &lt;francisco@shakespeare.lit&gt; support chat state notifications.</p>
<example caption="User Sends Initial Content Message With &lt;active/&gt; Notification"><![CDATA[
-<message
+<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit'
type='chat'>
@@ -323,7 +323,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</message>
]]></example>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
-<message
+<message
from='francisco@shakespeare.lit/elsinore'
to='bernardo@shakespeare.lit/pda'
type='chat'>
@@ -333,7 +333,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Because the User now knows that the Contact supports chat state notifications, the User can send other notification types.</p>
<example caption="User Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
-<message
+<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit/elsinore'
type='chat'>
@@ -341,7 +341,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
</message>
]]></example>
<example caption="User Sends a Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
-<message
+<message
from='bernardo@shakespeare.lit/pda'
to='francisco@shakespeare.lit/elsinore'
type='chat'>
@@ -352,9 +352,9 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
<p>And so forth.</p>
</section1>
<section1 topic='A Detailed Conversation' anchor='example-detail'>
- <p>The following conversation flow illustrates in more detail the workings of chat state notifications (in this case also using threads) between a User &lt;romeo@shakespeare.lit&gt; and a Contact &lt;juliet@capulet.com&gt;.</p>
+ <p>The following conversation flow illustrates in more detail the workings of chat state notifications (in this case also using threads) between a User &lt;romeo@shakespeare.lit&gt; and a Contact &lt;juliet@capulet.com&gt;.</p>
<example caption="User Sends Initial Content Message"><![CDATA[
-<message
+<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com'
type='chat'>
@@ -369,7 +369,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>At this point Juliet's client knows that Romeo's client supports chat state notifications. Thus she replies to the content message and her client includes a notification that her state is &lt;active/&gt;:</p>
<example caption="Contact's Client Sends Content Message Reply With &lt;active/&gt; Notification"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -383,7 +383,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>And so the conversation continues. After a while, Juliet asks a question that brings Romeo up short:</p>
<example caption="Contact Sends Another Message"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -393,8 +393,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo begins composing a reply to Juliet's heartfelt question, and his client notifies Juliet that he is composing a reply.</p>
<example caption="User's Client Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
-<message
- from='romeo@montague.net/orchard'
+<message
+ from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@@ -403,8 +403,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo realizes his reply is too rash and pauses to choose the right words; after some (configurable) time period, his client senses the delay and sends a state of &lt;paused/&gt;.</p>
<example caption="User's Client Sends Standalone &lt;paused/&gt; Notification"><![CDATA[
-<message
- from='romeo@montague.net/orchard'
+<message
+ from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@@ -413,8 +413,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo starts composing again, and his Jabber client sends a &lt;composing/&gt; notification to Juliet's client.</p>
<example caption="User's Clients Sends Standalone &lt;composing/&gt; Notification"><![CDATA[
-<message
- from='romeo@montague.net/orchard'
+<message
+ from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@@ -423,8 +423,8 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo finally sends his reply.</p>
<example caption="User Replies"><![CDATA[
-<message
- from='romeo@montague.net/orchard'
+<message
+ from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
<thread>act2scene2chat1</thread>
@@ -434,7 +434,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>The conversation ebbs and flows, waxes and wanes, until Juliet is called away by her Nurse...</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -449,7 +449,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>We suppose that Juliet minimizes the chat window, so her client generates an &lt;inactive/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;inactive/&gt; Notification"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -459,7 +459,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>When she returns and brings the window up again, her client generates an &lt;active/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;active/&gt; Notification"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -469,7 +469,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>The conversation continues, but Juliet is called away again by that nagging Nurse:</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -482,7 +482,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>We suppose that Juliet closes the chat window, so her client generates a &lt;gone/&gt; notification:</p>
<example caption="Contact's Client Sends Standalone &lt;gone/&gt; Notification"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
@@ -492,7 +492,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>Romeo's client now considers the chat thread to be over and generates a new Thread ID when he sends a new message:</p>
<example caption="User's Client Sends Content Message with New Thread ID"><![CDATA[
-<message
+<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com/balcony'
type='chat'>
@@ -507,7 +507,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
]]></example>
<p>When Juliet returns to her computer on the balcony, she finds the new message from Romeo. When she finishes her reply, her client includes both an &lt;active/&gt; notification and the new Thread ID with the body of her reply:</p>
<example caption="Contact's Client Sends Content Message"><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
diff --git a/xep-0086.xml b/xep-0086.xml
index 8acbf86..b7a03b7 100644
--- a/xep-0086.xml
+++ b/xep-0086.xml
@@ -83,7 +83,7 @@
<section1 topic='Supporting Legacy Entities'>
<p>XMPP-compliant entities can issue errors to legacy clients and servers by adding a &quot;code&quot; attribute to the &lt;error/&gt; element it sends.</p>
<example caption='A simple error response'><![CDATA[
-<message
+<message
to='juliet@capulet.com/balcony'
from='romeo@montague.net/garden'
type='error'>
diff --git a/xep-0087.xml b/xep-0087.xml
index 3243f4b..c49d574 100644
--- a/xep-0087.xml
+++ b/xep-0087.xml
@@ -84,7 +84,7 @@
Receiver rejects the stream initiation, EUC
</li>
</ol>
-
+
</section2>
</section1>
<section1 topic='Basic Usage'>
@@ -95,9 +95,9 @@
</p>
<example caption='Requesting Disco Information From Receiver'>
<![CDATA[
- <iq
- type='get'
- to='receiver@jabber.org/resource'
+ <iq
+ type='get'
+ to='receiver@jabber.org/resource'
from='sender@jabber.org/resource'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@@ -132,8 +132,8 @@
<example caption='Offer Stream Initiation'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'
profile='http://jabber.org/protocol/si/profile/profile-name'>
@@ -155,8 +155,8 @@
<example caption='Offer Stream Initiation (Profile in NS)'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'>
<profile xmlns='http://jabber.org/protocol/si/profile/profile-name'>
@@ -181,8 +181,8 @@
<!--
<example caption='Offer Regular File Transfer (Alternate Stream Negotiation)'>
<![CDATA[
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='application/octet-stream'
profile='filexfer'>
@@ -249,8 +249,8 @@
</example>
<example caption='Offer to Start a MP3 Stream'>
<![CDATA[
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='s0'
mime-type='audio/x-mp3'
profile='streaming-audio'>
@@ -267,8 +267,8 @@
</example>
<example caption='Offer to Start a MP3 Stream (Alternate Stream Negotiation)'>
<![CDATA[
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='s0'
mime-type='audio/x-mp3'
profile='streaming-audio'>
@@ -288,7 +288,7 @@
accept the stream. This information is transported in Stream Initiation
through a <em>profile</em>. A profile is a series of required and
optional headers that describe the stream data or how the stream is to be
- used. Each Stream Initiation MUST have only one profile, so the stream
+ used. Each Stream Initiation MUST have only one profile, so the stream
usage is kept clear.
</p>
<p>
@@ -304,8 +304,8 @@
decided upon. Each piece of information will be transported in a
&lt;header&gt; tag. The name attribute is a descriptive key that can be
looked up at the XMPP Registrar or XEP describing the profile. The
- actual data in the &lt;header&gt; is the fact related to the name
- attribute. It must also be stated whether the header is required or
+ actual data in the &lt;header&gt; is the fact related to the name
+ attribute. It must also be stated whether the header is required or
optional.
</p>
<p>
@@ -385,7 +385,7 @@
meanings and data:</p>
<ul>
<li>
- <em>Declining Transfer (403)</em>: During the Stream Initiation
+ <em>Declining Transfer (403)</em>: During the Stream Initiation
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.
@@ -406,14 +406,14 @@
</section1>
<section1 topic='IANA Considerations'>
<p>
- This document uses the MIME types as recorded by IANA, but no other direct
+ This document uses the MIME types as recorded by IANA, but no other direct
interaction is necessary.
</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>
- The "http://jabber.org/protocol/si" namespace will be registered.
- The registrar will track header profiles for different stream initiation
+ The "http://jabber.org/protocol/si" namespace will be registered.
+ The registrar will track header profiles for different stream initiation
uses.
</p>
</section1>
diff --git a/xep-0088.xml b/xep-0088.xml
index 91dd9c9..3874d34 100644
--- a/xep-0088.xml
+++ b/xep-0088.xml
@@ -68,7 +68,7 @@
<section2 topic='Service Discovery'>
<p>&xep0030; SHALL be used for discovering support for webtabs on servers.</p>
<example caption='Disco info response containing support for webtabs'><![CDATA[
-<iq
+<iq
type='result'
from='domain.com'
to='user@domain/resource'
@@ -79,7 +79,7 @@
</iq>]]></example>
<p>It is RECOMMENDED that the jabber server itself (JSM in jabberd) serves the webtab list, but if desired by the server implementor they MAY be served by a separate host/component.</p>
<example caption='Separate webtab host specified by server'><![CDATA[
-<iq
+<iq
type='result'
from='domain.com'
to='user@domain/resource'
@@ -91,7 +91,7 @@
</query>
</iq>
-<iq
+<iq
type='result'
from='webtabs.domain.com'
to='user@domain/resource'
diff --git a/xep-0090.xml b/xep-0090.xml
index 8223a5b..40ce69b 100644
--- a/xep-0090.xml
+++ b/xep-0090.xml
@@ -110,7 +110,7 @@
The protocol documented by this schema is defined in
XEP-0090: http://www.xmpp.org/extensions/xep-0090.html
- NOTE: This protocol has been deprecated in favor of the
+ NOTE: This protocol has been deprecated in favor of the
Entity Time protocol specified in XEP-0202:
http://www.xmpp.org/extensions/xep-0202.html
</xs:documentation>
diff --git a/xep-0091.xml b/xep-0091.xml
index 59cb1ac..8d5164c 100644
--- a/xep-0091.xml
+++ b/xep-0091.xml
@@ -153,7 +153,7 @@
The protocol documented by this schema is defined in
XEP-0091: http://www.xmpp.org/extensions/xep-0091.html
- NOTE: This protocol has been deprecated in favor of the
+ NOTE: This protocol has been deprecated in favor of the
Delayed Delivery protocol specified in XEP-0203:
http://www.xmpp.org/extensions/xep-0203.html
</xs:documentation>
diff --git a/xep-0093.xml b/xep-0093.xml
index 3aadf96..4f1431b 100644
--- a/xep-0093.xml
+++ b/xep-0093.xml
@@ -69,7 +69,7 @@
<message to='hamlet@denmark' from='horatio@denmark'>
<subject>Visitors</subject>
<body>This message contains roster items.</body>
- <x xmlns='jabber:x:roster'>
+ <x xmlns='jabber:x:roster'>
<item jid='rosencrantz@denmark'
name='Rosencrantz'>
<group>Visitors</group>
diff --git a/xep-0095.xml b/xep-0095.xml
index 842730b..45d4451 100644
--- a/xep-0095.xml
+++ b/xep-0095.xml
@@ -107,8 +107,8 @@
<section2 topic='Discovery' anchor='usecase-disco'>
<p>Before a Stream Initiation is attempted the Sender should be sure that the Receiver supports both Stream Initiation and the specific profile that they wish to use. This is typically accomplished using &xep0030;:</p>
<example caption='Requesting Disco Information From Receiver'><![CDATA[
-<iq type='get'
- to='receiver@jabber.org/resource'
+<iq type='get'
+ to='receiver@jabber.org/resource'
from='sender@jabber.org/resource'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@@ -298,7 +298,7 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>
- This document uses the MIME types as recorded by the IANA, but no direct
+ This document uses the MIME types as recorded by the IANA, but no direct
interaction with the IANA is necessary.
</p>
</section1>
@@ -331,8 +331,8 @@
targetNamespace='http://jabber.org/protocol/si'
xmlns='http://jabber.org/protocol/si'
elementFormDefault='qualified'>
-
- <xs:import
+
+ <xs:import
namespace='http://jabber.org/protocol/feature-neg'
schemaLocation='http://www.xmpp.org/schemas/feature-neg.xsd'/>
@@ -360,7 +360,7 @@
<xs:attribute name='profile' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='bad-profile' type='empty'/>
<xs:element name='no-valid-streams' type='empty'/>
diff --git a/xep-0096.xml b/xep-0096.xml
index 463f90b..96e1f16 100644
--- a/xep-0096.xml
+++ b/xep-0096.xml
@@ -126,7 +126,7 @@
with the possibility of one child describing the optional ranged transfers.
</p>
<p>
- The root element is &lt;file&gt; and has four attributes. The attributes
+ The root element is &lt;file&gt; and has four attributes. The attributes
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>
@@ -143,14 +143,14 @@
&lt;range&gt;. Both are OPTIONAL.
</p>
<p>
- &lt;desc&gt; is used to provide a sender-generated description of the file so
- the receiver can better understand what is being sent. It MUST NOT be sent in
+ &lt;desc&gt; is used to provide a sender-generated description of the file so
+ the receiver can better understand what is being sent. It MUST NOT be sent in
the result.
</p>
<p>
- When &lt;range&gt; is sent in the offer, it should have no
+ 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
+ sender can do ranged transfers. When a Stream Initiation result is sent
with the &lt;range&gt; element, it uses these attributes:</p>
<ul>
<li>
@@ -165,10 +165,10 @@
</li>
</ul>
<p>Both attributes are OPTIONAL on the &lt;range&gt; element. Sending no
- attributes is synonymous with not sending the &lt;range&gt;
+ 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
- offset 0. More generally, data is sent over the stream byte for byte starting
+ offset 0. More generally, data is sent over the stream byte for byte starting
at the offset position for the length specified.
</p>
<section2 topic='Mandatory-to-Implement Technologies' anchor='protocol-tech'>
@@ -180,7 +180,7 @@
<example caption='Simple Profile Usage in Stream Initiation Offer'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@@ -217,7 +217,7 @@
<example caption='Complete Profile Usage in Stream Initiation Offer'>
<![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@@ -399,7 +399,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
targetNamespace='http://jabber.org/protocol/si/profile/file-transfer'
xmlns='http://jabber.org/protocol/si/profile/file-transfer'
elementFormDefault='qualified'>
-
+
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
@@ -419,7 +419,7 @@ xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=
<xs:attribute name='size' type='xs:integer' use='required'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='range'>
<xs:complexType>
<xs:simpleContent>
diff --git a/xep-0097.xml b/xep-0097.xml
index a47594d..d8f6899 100644
--- a/xep-0097.xml
+++ b/xep-0097.xml
@@ -66,8 +66,8 @@
<example><![CDATA[
<message to="jdev@jabber.org" from="calendar.jabber.org" type="normal">
<body>
- Protocol gathering every Tuesday at 22:00 UTC
- located in foundation@conference.jabber.org
+ Protocol gathering every Tuesday at 22:00 UTC
+ located in foundation@conference.jabber.org
</body>
<ical xmlns="http://jabber.org/protocol/gw/ical">
BEGIN:VCALENDAR
diff --git a/xep-0098.xml b/xep-0098.xml
index 03dc46b..d342a2c 100644
--- a/xep-0098.xml
+++ b/xep-0098.xml
@@ -31,7 +31,7 @@
</revision>
</header>
<section1 topic='Introduction'>
- <p>The 'jabber:iq:private' namespace has been
+ <p>The 'jabber:iq:private' namespace has been
documented in &xep0049; according to the historical behavior
of current implementations. However there are two backward compatible
improvements to the protocol introduced in this standard
@@ -46,33 +46,33 @@ with this standard.</p>
</section1>
<section1 topic='private-xml Namespace'>
<section2 topic='Description'>
- <p>A Jabber client can store any arbitrary XML on the server side by sending an
-&IQ; chunk of type "set" to the server with a &QUERY; child scoped by the
-'http://jabber.org/protocol/private-xml' namespace. The &QUERY; element MUST contain a single, arbitrary
-XML fragment. That fragment MUST be scoped by its
+ <p>A Jabber client can store any arbitrary XML on the server side by sending an
+&IQ; chunk of type "set" to the server with a &QUERY; child scoped by the
+'http://jabber.org/protocol/private-xml' namespace. The &QUERY; element MUST contain a single, arbitrary
+XML fragment. That fragment MUST be scoped by its
own namespace. Any existing data stored on the server with the same fully qualified
element name (tag name + namespace) is replaced by the new data.</p>
- <p>The data can then be retrieved by sending an &IQ;
-of type "get" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace,
-which in turn MUST contain a single child element scoped by the namespace used
+ <p>The data can then be retrieved by sending an &IQ;
+of type "get" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace,
+which in turn MUST contain a single child element scoped by the namespace used
for storage of that fragment. The fully qualified element name is used to locate
matching XML data on the server. If no matching data is found, the server will
respond with the empty query child element and not an error.</p>
- <p>Finally, existing data on the server can be removed by sending an &IQ;
-of type "set" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace and
-containing an 'action' attribute with value 'delete',
-which in turn MUST contain a single child element scoped by the namespace used
+ <p>Finally, existing data on the server can be removed by sending an &IQ;
+of type "set" with a &QUERY; child scoped by the 'http://jabber.org/protocol/private-xml' namespace and
+containing an 'action' attribute with value 'delete',
+which in turn MUST contain a single child element scoped by the namespace used
for storage of that fragment. The fully qualified element name is used to locate
matching XML data on the server. The server responds with a successful result
whether a matching data fragment was found or not (it's successful because the
provided data no longer exits on the server). Deleting data using this method is
-indistinguishable from setting an empty XML fragment as far as the behavior this
-protoco is concerned. However, deleting data MUST remove the data from the server
-which may be implemented differently than the case of setting the data to an empty
+indistinguishable from setting an empty XML fragment as far as the behavior this
+protoco is concerned. However, deleting data MUST remove the data from the server
+which may be implemented differently than the case of setting the data to an empty
element. This may have significance in the context of future advanced XML storage protocols.
Using the basic private XML data storage protocol, Jabber entities can create, read, update, and delete
-private data on the server. The data stored might be
-anything, as long as it is valid XML. One typical usage for this namespace is the
+private data on the server. The data stored might be
+anything, as long as it is valid XML. One typical usage for this namespace is the
server-side storage of client preferences.</p>
</section2>
<section2 topic='Methods'>
@@ -85,10 +85,10 @@ server-side storage of client preferences.</p>
</table>
</section2>
<section2 topic='Elements'>
- <p>The root element of this namespace is query. A single child
-element with a proper namespace must be included otherwise the server will
-respond with error code 406. Only one element can be queried or set in a
-single IQ request. However, multiple elements, each containing data,
+ <p>The root element of this namespace is query. A single child
+element with a proper namespace must be included otherwise the server will
+respond with error code 406. Only one element can be queried or set in a
+single IQ request. However, multiple elements, each containing data,
can be stored independently on the server using separate set queries.</p>
<example caption='Client Stores Private Data'><![CDATA[
@@ -102,12 +102,12 @@ CLIENT:
</iq>
SERVER:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1001"/>
- ]]></example>
+ ]]></example>
<example caption='Client Retrieves Private Data'><![CDATA[
CLIENT:
@@ -118,10 +118,10 @@ CLIENT:
</iq>
SERVER:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1002">
<query xmlns="http://jabber.org/protocol/private-xml">
<exodus xmlns="exodus:prefs">
@@ -143,10 +143,10 @@ CLIENT:
</iq>
SERVER:
-<iq
- type="error"
- from="hamlet@shakespeare.lit"
- to="macbeth@shakespeare.lit"
+<iq
+ type="error"
+ from="hamlet@shakespeare.lit"
+ to="macbeth@shakespeare.lit"
iq="1003">
<query xmlns="http://jabber.org/protocol/private-xml">
<exodus xmlns="exodus:prefs">
@@ -204,16 +204,16 @@ CLIENT:
</iq>
SERVER (does not have data in "imaginary" namespace, returns empty element):
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1006">
<query xmlns="http://jabber.org/protocol/private-xml">
<data xmlns="imaginary"/>
</query>
</iq>
- ]]></example>
+ ]]></example>
<p>Finally, the client can delete data from the server using the delete query action.</p>
<example caption='User Deletes Data'><![CDATA[
CLIENT:
@@ -224,12 +224,12 @@ CLIENT:
</iq>
SERVER (server responds with success):
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1006"/>
- ]]></example>
+ ]]></example>
</section2>
diff --git a/xep-0099.xml b/xep-0099.xml
index 4aac721..9375311 100644
--- a/xep-0099.xml
+++ b/xep-0099.xml
@@ -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 it's 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
@@ -50,14 +50,14 @@ all request-response interactions. The particular action to be taken MUST be set
in the &IQ; &QUERY; sub-element. The action attribute MUST have a value of 'create', 'read',
'update', or 'delete'. Responses use the standard &IQ; 'result' and 'error' types.
For backward compatibility, an &IQ; 'get' query is treated as equivalent to an &IQ; 'set'
-query with action of 'read'. Action protocols may require all or just a subset of these
+query with action of 'read'. Action protocols may require all or just a subset of these
actions depending on the desired outcome.</p>
<p>In addition to the action attribute an optional "strict" attribute may be set in the &IQ; &QUERY;
sub-element. The only valid values for strict is "true" or "false" (case sensitive).
The strict behavior of actions causes more errors to be returned which tends to make
protocols more robust but also more complex. Action protocols MUST define the default value of
-the "strict" attribute in the context of that protocol. In addition, some protocols may
-not wish to allow changing the strict default, so action protocols MUST declare
+the "strict" attribute in the context of that protocol. In addition, some protocols may
+not wish to allow changing the strict default, so action protocols MUST declare
whether the strict behavior of the protocol may be set in the &IQ; &QUERY; sub-element.</p>
</section2>
<section2 topic='Actions'>
@@ -119,13 +119,13 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1001"/>
- ]]></example>
- <p>With strict actions enabled, conflict data will cause the create action
+ ]]></example>
+ <p>With strict actions enabled, conflict data will cause the create action
to fail when existing data is on the recipient node. Here we show iq:private, and strict actions with existing data on the server.</p>
<example caption='Client Stores New Private Data but Conflicts'><![CDATA[
SENDER:
@@ -138,10 +138,10 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="error"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="error"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="409">Conflict</error>
<exodus xmlns="exodus:prefs">
@@ -149,7 +149,7 @@ RECIPIENT:
</exodus>
</query>
</iq>
- ]]></example>
+ ]]></example>
</section2>
</section1>
@@ -183,10 +183,10 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1001">
<query xmlns="jabber:iq:private" action="read" strict="true">
<exodus xmlns="exodus:prefs"/>
@@ -194,8 +194,8 @@ RECIPIENT:
</exodus>
</query>
</iq>
- ]]></example>
- <p>With strict actions enabled, the absence of matching data will cause the read action
+ ]]></example>
+ <p>With strict actions enabled, the absence of matching data will cause the read action
to fail. Here we show iq:private, and strict actions with no matching data on the server.</p>
<example caption='Client Reads Private Data but Not Found (strict)'><![CDATA[
SENDER:
@@ -206,18 +206,18 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="error"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="error"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<data xmlns="imaginary"/>
</query>
</iq>
- ]]></example>
- <p>With strict actions disabled, the absence of matching data will cause the read action
-to return an 'empty' result. Here we show iq:private, and strict actions disabled with no matching data
+ ]]></example>
+ <p>With strict actions disabled, the absence of matching data will cause the read action
+to return an 'empty' result. Here we show iq:private, and strict actions disabled with no matching data
on the server.</p>
<example caption='Client Reads Private Data but Not Found (not strict)'><![CDATA[
SENDER:
@@ -228,15 +228,15 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1003">
<data xmlns="imaginary"/>
</query>
</iq>
- ]]></example>
+ ]]></example>
</section2>
</section1>
@@ -270,13 +270,13 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1001"/>
- ]]></example>
- <p>With strict actions enabled, the absence of existing data will cause the update action
+ ]]></example>
+ <p>With strict actions enabled, the absence of existing data will cause the update action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Updates Private Data but None Found'><![CDATA[
SENDER:
@@ -289,10 +289,10 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="error"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="error"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<exodus xmlns="exodus:prefs">
@@ -300,7 +300,7 @@ RECIPIENT:
</exodus>
</query>
</iq>
- ]]></example>
+ ]]></example>
</section2>
</section1>
@@ -332,13 +332,13 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1001"/>
- ]]></example>
- <p>With strict actions enabled, the absence of existing data will cause the delete action
+ ]]></example>
+ <p>With strict actions enabled, the absence of existing data will cause the delete action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Deletes Private Data but None Found (strict)'><![CDATA[
SENDER:
@@ -349,17 +349,17 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="error"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="error"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1002">
<error code="404">Not Found</error>
<data xmlns="imaginary"/>
</query>
</iq>
- ]]></example>
- <p>With strict actions disabled, the absence of existing data will not cause the delete action
+ ]]></example>
+ <p>With strict actions disabled, the absence of existing data will not cause the delete action
to fail. Here we show iq:private, and strict actions with no existing data on the server.</p>
<example caption='Client Deletes Private Data but None Found (not strict)'><![CDATA[
SENDER:
@@ -370,12 +370,12 @@ SENDER:
</iq>
RECIPIENT:
-<iq
- type="result"
- from="hamlet@shakespeare.lit/denmark"
- to="hamlet@shakespeare.lit/denmark"
+<iq
+ type="result"
+ from="hamlet@shakespeare.lit/denmark"
+ to="hamlet@shakespeare.lit/denmark"
id="1003"/>
- ]]></example>
+ ]]></example>
</section2>
</section1>
<section1 topic='Defining an Action Protocol'>
diff --git a/xep-0102.xml b/xep-0102.xml
index 77b97f1..3f924bc 100644
--- a/xep-0102.xml
+++ b/xep-0102.xml
@@ -91,18 +91,18 @@
<section3 topic="End To End Protection">
<p>It is easy to imagine XMPP systems in which the servers play active, fundamental roles in the protection of conversation data. Such systems could offer many advantages, like: </p>
<ul>
-<li>allowing the servers to function as credential issuing authorities,
+<li>allowing the servers to function as credential issuing authorities,
</li>
<li>allowing the servers to function as policy enforcement points. </li>
</ul>
<p>Unfortunately, such systems have significant disadvantages when one considers the nature of instant messaging: </p>
<ul>
-<li>Many servers may be un-trusted, public servers.
+<li>Many servers may be un-trusted, public servers.
</li>
-<li>In many conversation communities, decisions of trust and membership can only be adequately defined by the members themselves.
+<li>In many conversation communities, decisions of trust and membership can only be adequately defined by the members themselves.
</li>
-<li>In many conversation communities, membership in the community changes in real time based upon the dynamics of the conversation.
+<li>In many conversation communities, membership in the community changes in real time based upon the dynamics of the conversation.
</li>
<li>In many conversation communities, the data classification of the conversation changes in real time based upon the dynamics of the conversation. </li>
</ul>
@@ -120,7 +120,7 @@
<section2 topic="2.2 Environmental Considerations">
<p>Any new IM security protocol must integrate smoothly into the existing IM environment, and it must also recognize the nature of the transactions performed by conversation participants. These considerations are especially important: </p>
<ul>
-<li>dynamic communities. The members of a community are defined in near real time by the existing members.
+<li>dynamic communities. The members of a community are defined in near real time by the existing members.
</li>
<li>dynamic conversations. Conversations may involve any possible subset of the entire set of community members. </li>
</ul>
@@ -130,7 +130,7 @@
<section2 topic="Usability">
<p>Given the requirement to place the responsibility for the protection of conversation data in the hands of the participants, it is imperative to address some fundamental usability issues: </p>
<ul>
-<li>Overall ease of use is a requirement. For protocol purposes, one implication is that some form of authentication via passphrases is necessary. While we recognize that this can have appalling consequences, especially when we realize that a passphrase may be shared by all of the community members, we also recognize its utility.
+<li>Overall ease of use is a requirement. For protocol purposes, one implication is that some form of authentication via passphrases is necessary. While we recognize that this can have appalling consequences, especially when we realize that a passphrase may be shared by all of the community members, we also recognize its utility.
</li>
<li>PKIs are well established in many large organizations, and some communities will prefer to rely on credentials issued from these authorities. We must allow the use of existing PKI credentials and trust models rather than impose closed, XMPP-specific credentials.
</li>
@@ -140,17 +140,17 @@
<section2 topic="Development And Deployment">
<p>To successfully integrate into the existing XMPP environment, an extension protocol for security must satisfy the following: </p>
<ul>
-<li>It must be an optional extension of the existing XMPP protocol.
+<li>It must be an optional extension of the existing XMPP protocol.
</li>
-<li>It must be transparent to existing XMPP servers.
+<li>It must be transparent to existing XMPP servers.
</li>
-<li>It must function gracefully in cases where some community members are not running a user agent that supports the protocol.
+<li>It must function gracefully in cases where some community members are not running a user agent that supports the protocol.
</li>
-<li>It must make good use of XML.
+<li>It must make good use of XML.
</li>
-<li>It must avoid encumbered algorithms.
+<li>It must avoid encumbered algorithms.
</li>
-<li>It must be straightforward to implement using widely available cryptographic toolkits.
+<li>It must be straightforward to implement using widely available cryptographic toolkits.
</li>
<li>It must not require a PKI. </li>
</ul>
@@ -377,7 +377,7 @@
</ul>
<p>This key agreement protocol is used to establish a shared key with an assigned identifier and associated identities for two parties. The resulting common keying information state comprise a key name, secret keying material, the identification of the two parties, and three algorithms for use during authentication:</p>
<ul>
-<li>encryption for privacy,
+<li>encryption for privacy,
</li>
<li>hashing for protecting the integrity of message and for authentication of message fields
</li>
@@ -485,14 +485,14 @@
<section4 topic="Initiator request Security Association parameters">
<p>The intitiator uses a &lt;SecurityAssociation/&gt; element in the request to list all the EHA algorithms that it supports. In addition it provides its own DH ephemeral public key.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initiator cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value is used as the originator key name for the security association.</li>
</ul>
<ul>
-<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
+<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
-<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
+<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
</li>
</ul>
<p>These values are then used to prepare the XML element; this element is transmitted via the existing XMPP iq mechanism: </p>
@@ -525,15 +525,15 @@
<section4 topic="Responder select Security Association parameters">
<p>The responder will reply to the request by sending out its own selcted EHA algorithms that will be used in the remainign transaction. </p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The responder cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value is used as the recipient key name for the security association..
</li>
<li>The algorithms attributes are checked against the values supported by the user agent. If the receiver is not able to select one set out of the proposed algorithms, an error code 406-Unacceptable is returned.
</li>
-<li>The desired confidentiality and HMAC cryptographic algorithms are selected from the proposed set. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
+<li>The desired confidentiality and HMAC cryptographic algorithms are selected from the proposed set. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
-<li>The desired authentication algorithm is selected from the proposed set. The manner in which this algorithm is selected and all related policy issues are outside the scope of this specification. In the digital signature case, the responder's end-entity certificate MUST be issued by one of the trusted CAs listed in the session1 PDU or by the same issuer as the initiator's end-entity certificate. If the responder does not have acceptable credentials, an error code of 401-Unuthorized occurs.
+<li>The desired authentication algorithm is selected from the proposed set. The manner in which this algorithm is selected and all related policy issues are outside the scope of this specification. In the digital signature case, the responder's end-entity certificate MUST be issued by one of the trusted CAs listed in the session1 PDU or by the same issuer as the initiator's end-entity certificate. If the responder does not have acceptable credentials, an error code of 401-Unuthorized occurs.
</li>
</ul>
@@ -558,7 +558,7 @@
<section4 topic="Initiator provides its ephemeral public key">
<p>The intitiator provides its own DH ephemeral public key.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are used as the originator key name and the recipient key name for the security association..
</li>
@@ -592,11 +592,11 @@
<section4 topic="Responder provides its ephemeral public key">
<p>The responder check the validity of the parameters and eventualy replies with its own DH ephemeral public key.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 406 - Unacceptable .
</li>
-<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
+<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
</li>
<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded. </li>
</ul>
@@ -626,9 +626,9 @@
<section4 topic="Initiator provides its encrypted nonce">
<p>The intitiator provides its nonce encrypted with the agreed algorithm and the public key of the responder.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
-<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
+<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
</li>
<li>The initiator nonce is prepared by first generating a string of 20 random octets (160 random bits). The nonce is then encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters. </li>
</ul>
@@ -663,23 +663,23 @@
<section4 topic="Responder provides its encrypted nonce">
<p>The responder replies with the concatenation of its own nonce and the initiator nonce encrypted with the agreed algorithm and the public key of the initiator. The packet is authenticated using the agreed signature algorithm.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 401 - Unauthorized.
</li>
<li>The initiator nonce is decrypted using the responder private key.
</li>
-<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). It is then apended to the initiator nonce and the result encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters.
+<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). It is then apended to the initiator nonce and the result encrypted using the selected encryption algorithm and the shared secret key. The resulting octets are then encoded into a string of base64 characters.
</li>
-<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
-<li>Kir = hmac (0, initiator's nonce | responder's nonce)
+<li>Kir = hmac (0, initiator's nonce | responder's nonce)
</li>
<li>EHAs = (Encryption algorithm URI | Digest algorithm URI | Signature algorithm URI)
</li>
-<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
+<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
</li>
</ol>
<ul>
@@ -709,9 +709,9 @@
</EncryptedData>
</KA-Nonce>
</KeyAgreement>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignaturetValue>
... encoded signature value
@@ -724,31 +724,31 @@
<section4 topic="Initiator authenticate the final agreement">
<p>The initiator authenticate the keying material using the agreed signature algorithm.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
-<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
+<li>The initator and responder cookies are checked; a mismatch results in the procedure being aborted.
</li>
<li>The concatenation of the responder and initiator nonce is decrypted using the initiator private key. The original initiator nonce is compared to the result. An invalid nonce results in aborting the procedure. Otherwise the result is used to generate Kir
</li>
-<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
-<li>Kir = hmac (0, initiator's nonce | responder's nonce)
+<li>Kir = hmac (0, initiator's nonce | responder's nonce)
</li>
<li>EHAs = (Encryption algorithm URI | Digest algorithm URI | Signature algorithm URI)
</li>
-<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
+<li>HASH_R = hmac (Kir, JID responder | JID initiator | length of DH group | responder DH public key | initiator DH public key | EHAs)
</li>
</ol>
<ul>
<li>The authenticator is verified. A failure results in aborting the procedure.
</li>
-<li>Based on the selected authentication algorithm, the initiator&#8217;s authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator&#8217;s authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
-<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
+<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
</li>
</ol>
@@ -763,10 +763,10 @@
<KeyName>324A...BF24</KeyName>
</RecipientKeyInfo>
</SecurityAssociation>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignaturetValue>
<p>... encoded signature value</p>
@@ -779,15 +779,15 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder checks the final agreement">
<p>The responder acknowledge the keying material.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initator and responder cookies are checked; a mismatch results in an error code of 401 - Unauthorized.
</li>
-<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
-<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
+<li>HASH_I = hmac (Kir, JID initiator | JID responder | length of DH group | initiator DH public key | responder DH public key | EHAs)
</li>
</ol>
<ul>
@@ -804,21 +804,21 @@ xmldsig-core-schema.xsd">
<section4 topic="Initiator provides all Security Association parameters">
<p>The intitiator uses &lt;SecurityAssociation/&gt; element in the request to list all the EHA algorithms that it supports. In addition it provides its own DH ephemeral public key. The message is signed with its own private key.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
<li>The initiator cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value will be used as identifier for the initiator leg of the security association.
</li>
-<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
+<li>The available set of confidentiality and HMAC cryptographic algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification.
</li>
-<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
+<li>The available set of authentication algorithms is selected. The manner in which these algorithms are selected and all related policy issues are outside the scope of this specification. When the digital signature form of authentication is selected, the relevant end-entity certificate and, optionally, a chain of CA certificates representing a validation path, is assembled and encoded. A set of trusted CA certificates MAY optionally be included via caCertificate elements; if so, the set MUST include the issuer of the initiator's end-entity certificate.
</li>
<li>A Diffie-Hellman group is selected. The appropriate values for g and p will be used to generate the initiator's public key.
</li>
-<li>An ephemeral private key, x, is generated using g and p for the selected group. This key MUST be generated using an appropriate random number source. The corresponding public key, g^x, is generated and encoded.
+<li>An ephemeral private key, x, is generated using g and p for the selected group. This key MUST be generated using an appropriate random number source. The corresponding public key, g^x, is generated and encoded.
</li>
<li>The initiator nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
</li>
-<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -855,9 +855,9 @@ xmldsig-core-schema.xsd">
<p>... encoded initiator nonce value>
</KA-Nonce>
</KeyAgreement>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignatureValue>
<p>... encoded initiator signature value</p>
@@ -870,11 +870,11 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder respond to Security Association parameters">
<p>The responder will reply to the request by acknowledging the selected EHA algorithms. In addition, it provides its own DH ephemeral public key. The message is signed with its own private key.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
-<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
+<li>The Diffie-Hellman group is checked against the values supported by the user agent. An unsupported group results in an error code of 406 - Unacceptable
</li>
-<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -888,11 +888,11 @@ xmldsig-core-schema.xsd">
</li>
<li>The responder cookie is prepared by generating a string of 32 random octets (64 random bits). The cookie resulting octets are then encoded into a string of hex characters. The generated value will be used as identifier for the responder leg of the security association.
</li>
-<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded.
+<li>An ephemeral private key, y, is generated using g and p for the group indicated by the PDU. This key MUST be generated using an appropriate random number source. The corresponding public key, g^y, is generated and encoded.
</li>
-<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
+<li>The responder nonce is prepared by first generating a string of 20 random octets (160 random bits). The resulting octets are then encoded into a string of base64 characters.
</li>
-<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the responder's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -927,10 +927,10 @@ xmldsig-core-schema.xsd">
<p>... encoded responder nonce value>
</KA-Nonce>
</KeyAgreement>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignatureValue>
<p>... encoded responder signature value</p>
@@ -943,9 +943,9 @@ xmldsig-core-schema.xsd">
<section4 topic="Initiator authenticate the final agreement">
<p>The initiator authenticate the keying material using the agreed signature algorithm.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
-<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -957,7 +957,7 @@ xmldsig-core-schema.xsd">
<ul>
<li>The authenticator is verified. A failure results in the procedure being aborted.
</li>
-<li>Based on the selected authentication algorithm, the authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -979,10 +979,10 @@ xmldsig-core-schema.xsd">
<KeyName>324A...BF24</KeyName>
</RecipientKeyInfo>
</SecurityAssociation>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignaturetValue>
<p>... encoded signature value</p>
@@ -994,9 +994,9 @@ xmldsig-core-schema.xsd">
<section4 topic="Responder check the final agreement">
<p>The responder acknowledge the keying material.</p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants, respectively.
</li>
-<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
+<li>Based on the selected authentication algorithm, the initiator's authenticator is constructed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -1031,28 +1031,28 @@ xmldsig-core-schema.xsd">
<section3 topic="Generating And Sending a Conversation Key Transport PDU">
<p>The Key Transport assumes that a security association be negotiated for the purpose of securely transporting conversation keys. The sender's user agent employs the following algorithm to generate the keyTransport PDU: </p>
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants who negotiated the security association, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants who negotiated the security association, respectively.
</li>
-<li>The security association identifier is assembled.
+<li>The security association identifier is assembled.
</li>
-<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the integrity key sKEYID_a , is wrapped in instances of xenc:EncryptedKey as follows:
+<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the integrity key sKEYID_a , is wrapped in instances of xenc:EncryptedKey as follows:
</li>
</ul>
<ol>
-<li>The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
+<li>The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
</li>
-<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT be present.
+<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT be present.
</li>
-<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid symmetric key wrap algorithm. Furthermore, the algorithm MUST be the same as was negotiated for the security association.
+<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid symmetric key wrap algorithm. Furthermore, the algorithm MUST be the same as was negotiated for the security association.
</li>
-<li>The ds:KeyInfo element MUST NOT be present. The key to use is the shared secret KEY of the negotiated security association.
+<li>The ds:KeyInfo element MUST NOT be present. The key to use is the shared secret KEY of the negotiated security association.
</li>
-<li>The xenc:ContainedKeyName element MUST be present.
+<li>The xenc:ContainedKeyName element MUST be present.
</li>
<li>The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice. </li>
</ol>
<ul>
-<li>The HMAC is computed using KEY of the negotiated security association. A digital signature requires calculating:
+<li>The HMAC is computed using KEY of the negotiated security association. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -1066,7 +1066,7 @@ xmldsig-core-schema.xsd">
<query xmlns="xmpp:sec">
<SecurityAssociation id="negotiated SA id"/>
<KeyTransport>
-<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
+<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-enc&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@@ -1076,7 +1076,7 @@ xmldsig-core-schema.xsd">
</CipherValue>
</CipherData>
</EncryptedKey>
-<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
+<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-auth&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@@ -1086,7 +1086,7 @@ xmldsig-core-schema.xsd">
</CipherValue>
</CipherData>
</EncryptedKey>
-<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
+<EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<ContainedKeyName>A32F...245A324A...BF24-dig&lt;/ContainedKeyName>
<EncryptionMethod Algorithm="kw-tripledes"/>
@@ -1097,10 +1097,10 @@ xmldsig-core-schema.xsd">
</CipherData>
</EncryptedKey>
</KeyTransport>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@@ -1117,13 +1117,13 @@ xmldsig-core-schema.xsd">
<section3 topic="Receiving and Processing the Conversation Key Transport PDU">
<p>The receiver's user agent employs the following algorithm to process each KeyTransport PDU: </p>
<ul>
-<li>The values of initiator, responder, and security association id MUST indicate an existing security association. An invalid security association results in an error of 401 - Unauthorized.
+<li>The values of initiator, responder, and security association id MUST indicate an existing security association. An invalid security association results in an error of 401 - Unauthorized.
</li>
-<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the intergrity key sKEYID_a, is unwrapped. Any failures result in an error code of 406-Unacceptable.
+<li>The payload, which consists of the confidentiality key sKEYID_e, digest key sKEYID_d and the intergrity key sKEYID_a, is unwrapped. Any failures result in an error code of 406-Unacceptable.
</li>
-<li>The body of the HMAC element is decoded into the actual HMAC octet string.
+<li>The body of the HMAC element is decoded into the actual HMAC octet string.
</li>
-<li>The HMAC is computed using KEY of the security association. A digital signature requires calculating:
+<li>The HMAC is computed using KEY of the security association. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -1131,7 +1131,7 @@ xmldsig-core-schema.xsd">
</li>
</ol>
<ul>
-<li>The HMAC is validated. An invalid HMAC results in an error code of 406-Unacceptable.
+<li>The HMAC is validated. An invalid HMAC results in an error code of 406-Unacceptable.
</li>
<li>The keys are added to the user agent's key store. </li>
</ul>
@@ -1179,12 +1179,12 @@ xmldsig-core-schema.xsd">
</section3>
<section3 topic="Other Public Keys Transport">
<ul>
-<li>The values of initiator and responder MUST be the JIDs of the two participants in the exchange, respectively.
+<li>The values of initiator and responder MUST be the JIDs of the two participants in the exchange, respectively.
</li>
<li>The payload, which consists of the public key of the responder is assembled. </li>
</ul>
<ul>
-<li>The SIGN is computed using the private key of the responder. A digital signature requires calculating:
+<li>The SIGN is computed using the private key of the responder. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -1204,9 +1204,9 @@ xmldsig-core-schema.xsd">
</RSAKeyValue>
</KeyInfo>
</KeyTransport>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@@ -1228,7 +1228,7 @@ xmldsig-core-schema.xsd">
<section2 topic="Message Protection Mechanism">
<p>A protected message is defined as a traditional XMPP message whose body content is extended to include the transport of a cryptographically protected message body. The two key features are: </p>
<ul>
-<li>the usual body element contains some arbitrary text.
+<li>the usual body element contains some arbitrary text.
</li>
<li>the message contains a XMPP x element defining the xmpp:sec namespace; this element transports the protected message. </li>
</ul>
@@ -1238,24 +1238,24 @@ xmldsig-core-schema.xsd">
<section2 topic="Generating And Sending the Protected Message PDU">
<p>The sender's user agent employs the following algorithm to generate the protected Message PDU: </p>
<ul>
-<li>The security association identifier is assembled.
+<li>The security association identifier is assembled.
</li>
<li>The actual message body is encoded into a character string corresponding to a XMPP message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows: </li>
</ul>
<ol>
-<li>The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
+<li>The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
</li>
-<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT be present.
+<li>The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT be present.
</li>
-<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid block encryption algorithm.
+<li>The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid block encryption algorithm.
</li>
-<li>The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality key indicated by the convId attribute.
+<li>The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality key indicated by the convId attribute.
</li>
<li>The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice. </li>
</ol>
<ul>
-<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
+<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
</li>
</ul>
<ol>
@@ -1270,7 +1270,7 @@ xmldsig-core-schema.xsd">
The real body is protected.
</body>
<x xmlns="xmpp:security">
-<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
+<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<KeyInfo>
<KeyName>A32F2...45A324A...BF24-enc</KeyName>
@@ -1282,9 +1282,9 @@ The real body is protected.
</CipherValue>
</CipherData>
</EncryptedData>
-<Signature
- xmlns="http://www.w3.org/2000/09/xmldsig#"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<Signature
+ xmlns="http://www.w3.org/2000/09/xmldsig#"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#xmldsig-core-schema.xsd">
<SignedInfo>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
@@ -1303,13 +1303,13 @@ The real body is protected.
<section2 topic="Receiving and Processing the Protected Message PDU">
<p>The receiver's user agent employs the following algorithm to process each protectedMessage PDU: </p>
<ul>
-<li>The values of initiator, responder, and key name MUST indicate an existing security association. An invalid security association results in an error of 406-Unacceptable.
+<li>The values of initiator, responder, and key name MUST indicate an existing security association. An invalid security association results in an error of 406-Unacceptable.
</li>
-<li>The payload, which consists of the actual message body, is unwrapped. Any failures result in an error code of 406-Unacceptable.
+<li>The payload, which consists of the actual message body, is unwrapped. Any failures result in an error code of 406-Unacceptable.
</li>
-<li>The body of the HMAC element is decoded into the actual HMAC octet string.
+<li>The body of the HMAC element is decoded into the actual HMAC octet string.
</li>
-<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
+<li>Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:
</li>
</ul>
<ol>
diff --git a/xep-0103.xml b/xep-0103.xml
index ceaed94..227c8a9 100644
--- a/xep-0103.xml
+++ b/xep-0103.xml
@@ -138,7 +138,7 @@
<p>The sender starts with an SI request, using the semantics from XEP-0095:</p>
<example caption='Requesting SI transfer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='a0'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
diff --git a/xep-0104.xml b/xep-0104.xml
index ae0960e..e13b147 100644
--- a/xep-0104.xml
+++ b/xep-0104.xml
@@ -180,7 +180,7 @@
targetNamespace='http://jabber.org/protocol/url-data/scheme/http'
xmlns='http://jabber.org/protocol/url-data/scheme/http'
elementFormDefault='qualified'>
-
+
<xs:element name='auth'>
<xs:complexType>
<xs:attribute name='scheme' use='required' type='xs:string'/>
@@ -196,7 +196,7 @@
</xs:element>
</xs:complexType>
</xs:element>
-
+
<xs:element name='cookie'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
@@ -209,7 +209,7 @@
<xs:attribute name='version' use='optional' type='xs:string'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='header'>
<xs:complexType>
<xs:simpleContent>
diff --git a/xep-0105.xml b/xep-0105.xml
index 71514a9..2d9032a 100644
--- a/xep-0105.xml
+++ b/xep-0105.xml
@@ -82,11 +82,11 @@
<section1 topic='Examples'>
<example caption='Profile Usage in Stream Initiation Offer'><![CDATA[
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
- <si
- xmlns='http://jabber.org/protocol/si'
+ <si
+ xmlns='http://jabber.org/protocol/si'
id='a0'
profile='http://jabber.org/protocol/si/profile/tree-transfer'>
- <tree
+ <tree
xmlns='http://jabber.org/profile/si/profile/tree-transfer'
numfiles='9'
size='80500'>
@@ -132,7 +132,7 @@
]]></example>
<example caption='Subsequent File Transfer Offer'><![CDATA[
<iq type='set' id='offer2' to='receiver@jabber.org/resource'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='ft1'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@@ -169,7 +169,7 @@
targetNamespace='http://jabber.org/protocol/si/profile/tree-transfer'
xmlns='http://jabber.org/protocol/si/profile/tree-transfer'
elementFormDefault='qualified'>
-
+
<xs:element name='tree'>
<xs:complexType>
<xs:attribute name='numfiles' use='required' type='xs:integer'/>
@@ -177,7 +177,7 @@
<xs:element ref='directory' minOccurs='0' maxOccurs='1'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='directory'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
@@ -185,14 +185,14 @@
<xs:element ref='file' minOccurs='0' maxOccurs='unbounded'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='file'>
<xs:complexType>
<xs:attribute name='name' use='required' type='xs:string'/>
<xs:attribute name='sid' use='required' type='xs:string'/>
</xs:complexType>
</xs:element>
-
+
</xs:schema>
]]></code>
</section1>
diff --git a/xep-0107.xml b/xep-0107.xml
index 73a37ec..711384b 100644
--- a/xep-0107.xml
+++ b/xep-0107.xml
@@ -122,7 +122,7 @@
]]></example>
<p>The mood is then delivered to all subscribers:</p>
<example caption='Mood is Delivered to All Subscribers'><![CDATA[
-<message
+<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -152,7 +152,7 @@
</iq>
]]></example>
<example caption='Empty Mood Information is Delivered to All Subscribers'><![CDATA[
-<message
+<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
diff --git a/xep-0108.xml b/xep-0108.xml
index bb366e4..a70a777 100644
--- a/xep-0108.xml
+++ b/xep-0108.xml
@@ -111,7 +111,7 @@
<section2 topic='Pubsub Transport' anchor='proto-pubsub'>
<p>Activity information SHOULD be communicated and transported by means of the &xep0060; subset specified in &xep0163;. Because activity information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;.</p>
<example caption='User Publishes Activity'><![CDATA[
-<iq type='set'
+<iq type='set'
from='juliet@capulet.lit/ca486eba-0f9a-11dc-8835-000bcd821bfb'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@@ -130,8 +130,8 @@
]]></example>
<p>The activity is then delivered to all subscribers:</p>
<example caption='Activity is Delivered to All Subscribers'><![CDATA[
-<message
- from='juliet@capulet.lit'
+<message
+ from='juliet@capulet.lit'
to='romeo@montague.lit'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/activity'>
@@ -162,7 +162,7 @@
</iq>
]]></example>
<example caption='Empty Activity Information is Delivered to All Subscribers'><![CDATA[
-<message
+<message
from='juliet@capulet.lit'
to='romeo@montague.net'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -237,7 +237,7 @@
<li>taking_a_shower</li>
</ul>
</li>
-
+
<li>having_appointment</li>
<li>inactive
diff --git a/xep-0109.xml b/xep-0109.xml
index 18559fc..64cf9c3 100644
--- a/xep-0109.xml
+++ b/xep-0109.xml
@@ -79,7 +79,7 @@
is in effect.</li>
</ul>
- <p>All these requirements are satisfied by &xep0163;, which is a subset of &xep0060;.</p>
+ <p>All these requirements are satisfied by &xep0163;, which is a subset of &xep0060;.</p>
</section1>
@@ -104,7 +104,7 @@
out-of-office settings on a PEP node with the desired access model (such as Presence or Open). When
a user (or their client) sends presence containing CAPS (see &xep0115;) with an
entry for out-of-office to a contact with an out-of-office message, the user's
- client is notified of the out-of-office message and may display, in a client-defined
+ client is notified of the out-of-office message and may display, in a client-defined
fashion, the out-of-office settings information.</p>
<p>Clients may rely on the PEP node for notifications of changes as well as
@@ -131,7 +131,7 @@
]]></example>
<example caption='Server returns out-of-office settings'><![CDATA[
-<iq type='result'
+<iq type='result'
from='example.com'
id='get1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub>
@@ -152,8 +152,8 @@
<p>The &lt;start/> and &lt;end/> elements define the times between which this vacation
message should be considered valid by a supporting client; the times are in
- the format specified by &xep0082;.</p>
-
+ the format specified by &xep0082;.</p>
+
<p>The &lt;message/> element contains the text of the message which the client may
display for the user (when appropriate).</p>
@@ -172,9 +172,9 @@
of 'current' to the out-of-office node:</p>
<example caption='Publishing new out-of-office settings'><![CDATA[
-<iq type='set'
- from='user@example.com/client'
- to='example.com'
+<iq type='set'
+ from='user@example.com/client'
+ to='example.com'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:ooo:0'>
@@ -193,9 +193,9 @@
]]></example>
<example caption='Out-of-office settings published successfully'><![CDATA[
-<iq type='result'
- from='example.com'
- to='user@example.com/client'
+<iq type='result'
+ from='example.com'
+ to='user@example.com/client'
id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:ooo:0'>
@@ -216,7 +216,7 @@
<p>And by design, PEP sends a notification to all the user's resources.</p>
<example caption="PEP node notification sent to user"><![CDATA[
-<message from='user@example.com'
+<message from='user@example.com'
id='notification_1781477179'
to='user@example.com/client' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -307,7 +307,7 @@
<section1 topic='Server requirements'>
<p>A server implementing out-of-office messages MUST implement
- &xep0163;.</p>
+ &xep0163;.</p>
</section1>
<section1 topic='Security Considerations'>
<p>None yet defined.</p>
diff --git a/xep-0111.xml b/xep-0111.xml
index cf834d4..8e468d3 100644
--- a/xep-0111.xml
+++ b/xep-0111.xml
@@ -77,7 +77,7 @@
<section1 topic="Introduction" anchor='intro'>
<p><em>Note Well: This proposal has been retracted by the authors in favor of &xep0166;.</em></p>
<p>The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &xmppcore;).
- <note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
+ <note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
In particular, TINS provides an XMPP representation of standard session management semantics such as those provided by the Session Initiation Protocol (SIP; see &rfc3261;). As a result, native XMPP clients that support TINS can negotiate out-of-band multimedia sessions (e.g., use of the Real-Time Transport Protocol or RTP; see &rfc3550;) and XMPP services that support TINS can easily interoperate with SIP services through gateways.</p>
</section1>
<section1 topic="Requirements" anchor='reqs'>
@@ -89,7 +89,7 @@
</ol>
</section1>
<section1 topic="Protocol" anchor='protocol'>
- <p>TINS exchanges are completed by sending &MESSAGE; stanzas containing a child &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace.
+ <p>TINS exchanges are completed by sending &MESSAGE; stanzas containing a child &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace.
<note>While it may seem that the semantics of &IQ; stanzas are more appropriate, <cite>RFC 3261</cite> allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in <cite>RFC 6120</cite>.</note>
In order to track the structure of the TINS "conversation", the &THREAD; child of &MESSAGE; MAY also be included. The &lt;tins/&gt; element MUST possess a 'method' attribute, whose value SHOULD be either an IANA-registered value for a SIP method or "result", as described below. The following SIP methods will probably be used most frequently in TINS interactions:</p>
<ul>
@@ -97,7 +97,7 @@
<li><p>ACK -- Used by the initiator to tell the invitee that an out-of-band session has been established.</p></li>
<li><p>BYE -- Used by either side of the conversation to terminate the transaction. This message SHOULD cause all resources associated with this transaction to be freed, and any associated network connections to be terminated.</p></li>
</ul>
- <p>The SDP data itself is included as the XML character data of an &lt;sdp/&gt; child of the &lt;tins/&gt; element, qualifed by the 'urn:ietf:rfc:2327' namespace (this is consistent with &rfc2648;).
+ <p>The SDP data itself is included as the XML character data of an &lt;sdp/&gt; child of the &lt;tins/&gt; element, qualifed by the 'urn:ietf:rfc:2327' namespace (this is consistent with &rfc2648;).
<note>The &lt;sdp/&gt; element is qualified by a separate namespace because it may be desirable for TINS to support other formats (such as SDPng) in the future; these can then be added without changing the XML schema for TINS.</note>
Any restricted XML characters in the SDP data (i.e., &amp; &apos; &lt; &gt; &quot;) MUST be properly escaped when contained in the XML character data of the &lt;sdp/&gt; element (for example, the ' character MUST be escaped to &amp;apos;). It is the responsibility of the XMPP recipient or translating gateway to unescape these restricted characters for processing.</p>
<p>The request stanza MAY also include either or both of the following:</p>
@@ -116,8 +116,8 @@
<p>The following XMPP stanzas could be used to initiate a voice call. The 'from' addresses will usually be added by the XMPP server or relevant gateway, but are shown here for the sake of clarity. Note the inclusion of SHIM headers and extended addresses.</p>
<example caption='Step 1: A sends an invite to B'><![CDATA[
<message
- from='A@example.com/work'
- to='B@example.com/laptop'
+ from='A@example.com/work'
+ to='B@example.com/laptop'
id='tins01'>
<thread>1234@hostA.example.com</thread>
<tins method='INVITE' xmlns='http://jabber.org/protocol/tins'>
@@ -146,8 +146,8 @@
]]></example>
<example caption='Step 2: B tells A that it is trying'><![CDATA[
<message
- from='B@example.com/laptop'
- to='A@example.com/work'
+ from='B@example.com/laptop'
+ to='A@example.com/work'
id='tins01'>
<thread>1234@hostA.example.com</thread>
<tins method='result'
@@ -165,8 +165,8 @@
]]></example>
<example caption='Step 3: B tells A that it is ringing'><![CDATA[
<message
- from='B@example.com/laptop'
- to='A@example.com/work'
+ from='B@example.com/laptop'
+ to='A@example.com/work'
id='tins01'>
<tins method='result'
code='180'
@@ -183,11 +183,11 @@
]]></example>
<example caption='Step 4: B sends an updated description to A'><![CDATA[
<message
- from='B@example.com/laptop'
- to='A@example.com/work'
+ from='B@example.com/laptop'
+ to='A@example.com/work'
id='tins02'>
<thread>1234@hostA.example.com</thread>
- <tins method='result'
+ <tins method='result'
code='200'
xmlns='http://jabber.org/protocol/tins'>
<sdp xmlns='urn:ietf:rfc:2327'>
@@ -217,8 +217,8 @@
]]></example>
<example caption='Step 5: A sends an acknowledgement to B'><![CDATA[
<message
- from='A@example.com/work'
- to='B@example.com/laptop'
+ from='A@example.com/work'
+ to='B@example.com/laptop'
id='tins02'>
<thread>1234@hostA.example.com</thread>
<tins method='ACK' xmlns='http://jabber.org/protocol/tins'/>
@@ -234,8 +234,8 @@
]]></example>
<example caption='Step 6: B hangs up'><![CDATA[
<message
- from='B@example.com/laptop'
- to='A@example.com/work'
+ from='B@example.com/laptop'
+ to='A@example.com/work'
id='tins03'>
<thread>1234@hostA.example.com</thread>
<tins method='BYE' xmlns='http://jabber.org/protocol/tins'/>
@@ -251,8 +251,8 @@
]]></example>
<example caption='Step 7: A acknowledges the hang up'><![CDATA[
<message
- from='A@example.com/work'
- to='B@example.com/laptop'
+ from='A@example.com/work'
+ to='B@example.com/laptop'
id='tins03'>
<thread>1234@hostA.example.com</thread>
<tins method='result'
diff --git a/xep-0112.xml b/xep-0112.xml
index 9970553..a6a0c30 100644
--- a/xep-0112.xml
+++ b/xep-0112.xml
@@ -80,7 +80,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>NOTE WELL: The protocol defined herein has been folded into &xep0080;.</em></p>
- <p>This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>XEP-0080</cite>.</p>
+ <p>This document defines an extension mechanism for capturing "extended presence" information about a user's current physical location. The information structures defined herein are intended to provide a format for describing a location or address that may change fairly frequently (e.g., one's location on a campus or in a large building) in situations where the user or application does not possess, or does not wish to communicate, detailed latitude/longitude data of the type defined in <cite>XEP-0080</cite>.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>Information about the user's location is provided by the user and propagated on the network by the user's client. The information is structured by means of an &lt;physloc/&gt; element that is qualified by the 'http://jabber.org/protocol/physloc' namespace. The location information itself is provided as the XML character data of the following children of the &lt;physloc/&gt; element:</p>
@@ -212,8 +212,8 @@
<td align='center'>&lt;Street/&gt;
<note>The IMPS specification also enables one to define an intersection (e.g., "Broadway and 34th Street") as the combination of a &lt;Crossing1/&gt; element (e.g., "Broadway") and a &lt;Crossing2/&gt; element (e.g., "34th Street"). To map from IMPS to Jabber, an application SHOULD map such a combination to one Jabber/XMPP &lt;street/&gt; element.</note>
</td>
- <td align='center'>&lt;A6/&gt;
- <note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to Jabber, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one Jabber/XMPP &lt;street/&gt; element.</note>
+ <td align='center'>&lt;A6/&gt;
+ <note>The PIDF-LO format provides information elements for much more granular control over a traditional street address; in PIDF-LO the &lt;A6/&gt; element is the street name only, and further information is provided in distinct elements for a leading street direction (e.g., "N"), trailing street suffix (e.g., "SW"), street suffix (e.g., "Avenue"), house number (e.g., "909"), and house number suffix (e.g., "1/2"). To map from PIDF-LO to Jabber, an application SHOULD construct the complete street address from the PIDF-LO elements (&lt;A6/&gt;, &lt;PRD/&gt;, &lt;POD/&gt;, &lt;STS/&gt;, &lt;HNO/&gt;, and &lt;HNS/&gt;) and map the result to one Jabber/XMPP &lt;street/&gt; element.</note>
</td>
<td align='center'>&lt;STREET/&gt;</td>
</tr>
diff --git a/xep-0113.xml b/xep-0113.xml
index fd3dc39..944e3a5 100644
--- a/xep-0113.xml
+++ b/xep-0113.xml
@@ -71,7 +71,7 @@
<section2 topic='Single whiteboard message'>
<p>Typically the user right-clicks on the destination contact and will select a "whiteboard message" option. The client will show a dialog where the user can create the drawing. It is up to the implementation to decide whether the user can include text in the message as well. Upon clicking a send button the client will close the dialog and send the following message:</p>
<example caption='Single whiteboard message'><![CDATA[
-<message
+<message
from='painter@shakespeare.lit'
to='timon@shakespeare.lit/hall'>
<body>A piece of painting, which I do beseech your lordship to accept.</body>
@@ -88,7 +88,7 @@
<section2 topic='Whiteboard chat session'>
<p>A more typical use case is where two clients share a whiteboard. Again the user will right click on the destination and will select a "whiteboard chat" option. The client will present a dialog where the user can create a drawing. Upon clicking a send button or releasing the mouse button, the client will send the following message:</p>
<example caption='Initiating a whiteboard chat session'><![CDATA[
-<message
+<message
from='kingclaudius@shakespeare.lit/castle'
to='laertes@shakespeare.lit/castle'
type='chat'>
@@ -101,26 +101,26 @@
]]></example>
<p>In this case the dialog will not close. At the destination client a similar dialog will pop up, allowing the user at the other end to add her own part of the drawing. The resulting message will look like this (line breaks provided for readability only):</p>
<example caption='Continuing a whiteboard chat session'><![CDATA[
-<message
+<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
<thread>c357e044c676cc5e3c729d07544c87b58a366dba</thread>
<x xmlns='http://jabber.org/protocol/swb'>
- <path d='M 32 41 L 33 40 33 39 34 38 34 37 35 36 35 34 36 33 37
- 32 38 31 38 30 39 30 40 28 41 27 42 26 43 26 44 25 45
- 24 46 24 48 23 50 22 52 21 53 21 54 21 55 21 55 20 56
- 20 58 20 59 20 60 20 61 20 62 20 63 20 64 20 65 20 66
- 20 67 20 68 20 69 20 69 21 70 21 71 22 72 23 72 24 73
- 25 73 26 73 27 73 28 73 29 73 30 74 30 74 31 74 32 75
- 33 75 34 75 35 75 36 75 37 75 38 75 39 75 40 75 41 75
- 43 75 44 75 46 75 47 75 48 75 49 75 50 74 52 74 53 74
- 54 73 55 72 55 72 57 72 58 71 58 70 60 69 61 69 63 68
- 64 67 64 67 65 67 66 66 67 65 67 65 69 64 70 64 71 63
- 72 62 73 62 74 62 75 61 75 60 76 60 77 59 77 59 78 59
- 79 58 79 58 80 58 81 58 82 57 82 57 83 57 84 57 86 57
- 87 56 87 56 88 56 89 55 89 55 90 55 91 55 92 54 93 54
- 94 54 95 54 96 M 55 113 L 54 113 53 113 52 113 51 113
+ <path d='M 32 41 L 33 40 33 39 34 38 34 37 35 36 35 34 36 33 37
+ 32 38 31 38 30 39 30 40 28 41 27 42 26 43 26 44 25 45
+ 24 46 24 48 23 50 22 52 21 53 21 54 21 55 21 55 20 56
+ 20 58 20 59 20 60 20 61 20 62 20 63 20 64 20 65 20 66
+ 20 67 20 68 20 69 20 69 21 70 21 71 22 72 23 72 24 73
+ 25 73 26 73 27 73 28 73 29 73 30 74 30 74 31 74 32 75
+ 33 75 34 75 35 75 36 75 37 75 38 75 39 75 40 75 41 75
+ 43 75 44 75 46 75 47 75 48 75 49 75 50 74 52 74 53 74
+ 54 73 55 72 55 72 57 72 58 71 58 70 60 69 61 69 63 68
+ 64 67 64 67 65 67 66 66 67 65 67 65 69 64 70 64 71 63
+ 72 62 73 62 74 62 75 61 75 60 76 60 77 59 77 59 78 59
+ 79 58 79 58 80 58 81 58 82 57 82 57 83 57 84 57 86 57
+ 87 56 87 56 88 56 89 55 89 55 90 55 91 55 92 54 93 54
+ 94 54 95 54 96 M 55 113 L 54 113 53 113 52 113 51 113
49 114 49 115 48 115 47 115 47 116 47 117 46 117 45 117
45 118 45 120 45 121 45 123 45 124 45 125 45 127 45 128
45 130 46 131 46 132 46 133 47 133 47 134 48 134 49 134
@@ -135,7 +135,7 @@
<p>It is left as a mental exercise to the reader to imagine Laertes answer. Alternatively the reader could build this protocol into her favorite Jabber client, set a breakpoint, and paste the path above at the appropriate place.</p>
<p>Alternatively Laertes could respond like:</p>
<example caption='Moving a path'><![CDATA[
-<message
+<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
@@ -148,7 +148,7 @@
<p>This would move the King's triangle 100 pixels to the left and top, to the upper left corner of the screen.</p>
<p>If Laertes were bold enough he might even answer:</p>
<example caption='Deleting a path'><![CDATA[
-<message
+<message
from='laertes@shakespeare.lit/castle'
to='kingclaudius@shakespeare.lit/castle'
type='chat'>
@@ -163,7 +163,7 @@
<section2 topic='Conference room whiteboard'>
<p>The final use case is the one where multiple users, gathered in a conference room, share a single whiteboard. Messages will typically look like this:</p>
<example caption='Conference room whiteboard'><![CDATA[
-<message
+<message
from='nestor@shakespeare.lit'
to='plains@conference.shakespeare.lit'
type='groupchat'>
@@ -196,7 +196,7 @@
};
for (int i = 0 ; sHersheyFontData ['A'][2*i+2] != 0 ; i++) {
- // read a new coordinate pair
+ // read a new coordinate pair
POINT myPoint = {sHersheyFontData ['A'][2*i+2]-'R', sHersheyFontData ['A'][2*i+2+1]-'R')};
// test for the special case pen up
if (myPoint.x == -50 && myPoint.y == 0) {
@@ -277,7 +277,7 @@
<!ELEMENT path EMPTY >
<!ATTLIST path d CDATA #REQUIRED
stroke CDATA #IMPLIED
- stroke-width CDATA #IMPLIED
+ stroke-width CDATA #IMPLIED
id CDATA #IMPLIED >
<!ELEMENT move EMPTY >
<!ATTLIST move id CDATA #REQUIRED
diff --git a/xep-0114.xml b/xep-0114.xml
index 67485e0..2515849 100644
--- a/xep-0114.xml
+++ b/xep-0114.xml
@@ -100,7 +100,7 @@
from='plays.shakespeare.lit'
id='3BF96D32'>
]]></example>
- <p>If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., &lt;conflict/&gt; or &lt;host-unknown/&gt;). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an &lt;invalid-namespace/&gt; stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of <cite>XMPP Core</cite> by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to <cite>RFC 3920</cite> for details).</p>
+ <p>If the server will not service the component name specified in the 'to' attribute of the stream header, it MUST return a stream error (e.g., &lt;conflict/&gt; or &lt;host-unknown/&gt;). If the server does not recognize or support the namespace specified in the stream header (e.g., it does not support streams qualified by the 'jabber:component:accept' namespace), it MUST return an &lt;invalid-namespace/&gt; stream error. For all errors related to the stream header, the server MUST follow the rules in Section 4.7.1 of <cite>XMPP Core</cite> by returning an opening stream tag, stream error element, and closing stream tag rather than merely a stream error element (refer to <cite>RFC 3920</cite> for details).</p>
<p>After receiving the stream header reply from the server, the component MUST send a &lt;handshake/&gt; element with appropriate contents. <note>The handshake value is always supplied by the initiator. Thus for jabber:component:accept connections, the handshake value is provided by the component, whereas for jabber:component:connect connections, the handshake value is provided by the server.</note></p>
<example caption='Component sends handshake element'><![CDATA[
<handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake>
@@ -113,7 +113,7 @@
<li>Convert the hash output to all lowercase characters.</li>
</ol>
<p>If the credentials supplied by the initiator are not valid, the receiver MUST close the stream and the underlying TCP connection, and SHOULD return a &lt;not-authorized/&gt; stream error.</p>
- <p>If the credentials are acceptable, the receiving application (in this case the server) MUST return an empty &lt;handshake/&gt; element.</p>
+ <p>If the credentials are acceptable, the receiving application (in this case the server) MUST return an empty &lt;handshake/&gt; element.</p>
<example caption='Server sends empty handshake element to acknowledge success'><![CDATA[
<handshake/>
]]></example>
diff --git a/xep-0115.xml b/xep-0115.xml
index 6c66cfb..8641994 100644
--- a/xep-0115.xml
+++ b/xep-0115.xml
@@ -138,7 +138,7 @@
<p>It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:</p>
<ul>
<li>Showing a different set of icons depending on the capabilities of other entities.</li>
- <li>Not sending &xep0071; or other rich content to plaintext clients such as cell phones.</li>
+ <li>Not sending &xep0071; or other rich content to plaintext clients such as cell phones.</li>
<li>Allowing the initiation of a Voice over IP (VoIP) session only to clients that support &xep0166; and &xep0167;.</li>
<li>Not showing a "Send a File" button if another user's client does not support &xep0096;.</li>
<li>Filtering &xep0060; notifications based on advertised subscriber interests.</li>
@@ -150,7 +150,7 @@
<p>Imagine that you are a Shakespearean character named Juliet and one of your contacts, a handsome fellow named Romeo, becomes available. His client wants to publish its capabilities, and does this by adding to its presence packets a &lt;c/&gt; element with special attributes. As a result, your client receives the following presence packet:</p>
<code><![CDATA[
<presence from='romeo@montague.lit/orchard'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
@@ -159,9 +159,9 @@
<p>The 'node' attribute represents the client software Romeo is using. The 'ver' attribute is a specially-constructed string (called a "verification string") that represents the entity's service discovery identity (category and type as registered at &DISCOCATEGORIES;, as well as, optionally, xml:lang and name) and supported features (as registered at &DISCOFEATURES; as well as, optionally, extended service discovery information data registered at &FORMTYPES;).</p>
<p>At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.</p>
<code><![CDATA[
-<iq from='juliet@capulet.lit/chamber'
+<iq from='juliet@capulet.lit/chamber'
id='disco1'
- to='romeo@montague.lit/orchard'
+ to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
@@ -169,9 +169,9 @@
]]></code>
<p>The response is:</p>
<code><![CDATA[
-<iq from='romeo@montague.lit/orchard'
+<iq from='romeo@montague.lit/orchard'
id='disco1'
- to='juliet@capulet.lit/chamber'
+ to='juliet@capulet.lit/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
@@ -186,7 +186,7 @@
<p>At this point, your client knows that a contact who advertises a verification string of 'QgayPKawpkPSDYmwT/WM94uAlu0=' supports &xep0045; and the other features returned by Romeo because the contact in fact uses the same version of the same client software as Romeo, with the same enabled features, plugins, presented client name(s), and the like (i.e., the same input to the verification string <link url='#ver-gen'>generation method</link>). <note>The string can be relied upon because of how it is generated and checked, as explained later in this document.</note> Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same verification string. For example, your Nurse may use the same client that Romeo does:</p>
<code><![CDATA[
<presence from='nurse@capulet.lit/chamber'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
@@ -196,7 +196,7 @@
<p>On the other hand, for a person with the following presence ...</p>
<code><![CDATA[
<presence from='benvolio@capulet.lit/230193'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
@@ -205,7 +205,7 @@
<p>... or the following presence ...</p>
<code><![CDATA[
<presence from='bard@shakespeare.lit/globe'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
@@ -331,7 +331,7 @@
<code>
&lt;iq from='benvolio@capulet.lit/230193'
id='disco1'
- to='juliet@capulet.lit/chamber'
+ to='juliet@capulet.lit/chamber'
type='result'&gt;
&lt;query xmlns='http://jabber.org/protocol/disco#info'
node='http://psi-im.org#q07IKJEyjvHSyhy//CH0CxmKi8w='&gt;
@@ -460,9 +460,9 @@
<p>An application (the "requesting entity") can learn what features another entity supports by sending a disco#info request (see <cite>XEP-0030</cite>) to the entity that generated the caps information (the "generating entity").</p>
<example caption='Disco#info request'><![CDATA[
-<iq from='juliet@capulet.lit/balcony'
+<iq from='juliet@capulet.lit/balcony'
id='disco1'
- to='romeo@montague.lit/orchard'
+ to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='/>
@@ -476,9 +476,9 @@
<p>The generating entity then returns all of the capabilities it supports.</p>
<example caption='Disco#info response'><![CDATA[
-<iq from='romeo@montague.lit/orchard'
+<iq from='romeo@montague.lit/orchard'
id='disco1'
- to='juliet@capulet.lit/balcony'
+ to='juliet@capulet.lit/balcony'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
diff --git a/xep-0117.xml b/xep-0117.xml
index 14ac8f1..579943c 100644
--- a/xep-0117.xml
+++ b/xep-0117.xml
@@ -141,7 +141,7 @@
<p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
diff --git a/xep-0119.xml b/xep-0119.xml
index d18ffef..a08a2aa 100644
--- a/xep-0119.xml
+++ b/xep-0119.xml
@@ -172,9 +172,9 @@ Service | Manager
<p>This document introduces no new security considerations above and beyond those defined in the documents on which it depends. Because publicly exposing some forms of extended presence information (e.g., geolocation information) may lead to unnecessary risks, care should be taken in setting the access model for the relevant pubsub nodes (minimally, an access model of "presence" to take advantage of the bidirectional authorization scheme inherent in XMPP presence subscriptions).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
- <p>This document requires no interaction with the &REGISTRAR;.</p>
+ <p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>
diff --git a/xep-0120.xml b/xep-0120.xml
index dba89d7..e92a95d 100644
--- a/xep-0120.xml
+++ b/xep-0120.xml
@@ -60,7 +60,7 @@
<p>The format defined herein uses a simple "key-value" structure. Although this may seem contrary to the XML basis of Jabber technologies, there are at least two good reasons for pursuing this approach:</p>
<ol>
<li><p>Using namespaced XML elements would force implementations to maintain a record of all namespaces and to differentiate those that define actionable protocols (e.g., 'http://jabber.org/protocol/si') from those that define informational metadata formats (e.g., 'http://purl.org/dc/elements/1.1'); the only way to do this would be to maintain an internal list of all possible namespaces that might be encountered by an application on the network.</p></li>
- <li><p>Not all metadata formats that the Jabber community may want to use exist in stable XML representations (e.g., this is true of the vCard format) or in representations for which namespaces exist. In addition, some metadata formats (e.g., &foaf;) exist only in &w3rdf;, whose syntax is represented in XML but whose semantics impose a more complex structure that requires a specialized (non-XML) parser. As long as a clear mapping can be defined between such metadata formats and Jabber infobits, consistent information representation and exchange can be preserved.</p></li>
+ <li><p>Not all metadata formats that the Jabber community may want to use exist in stable XML representations (e.g., this is true of the vCard format) or in representations for which namespaces exist. In addition, some metadata formats (e.g., &foaf;) exist only in &w3rdf;, whose syntax is represented in XML but whose semantics impose a more complex structure that requires a specialized (non-XML) parser. As long as a clear mapping can be defined between such metadata formats and Jabber infobits, consistent information representation and exchange can be preserved.</p></li>
</ol>
</section1>
<section1 topic='Protocol'>
diff --git a/xep-0122.xml b/xep-0122.xml
index afcc755..dd04da6 100644
--- a/xep-0122.xml
+++ b/xep-0122.xml
@@ -140,8 +140,8 @@
<section3 topic='&lt;open/&gt; Validation' anchor='usercases-validation.open'>
<p>For "list-single" or "list-multi", to indicate that the user may enter a custom value (matching the datatype constraints) or choose from the predefined values, the &lt;validate/&gt; element shall contain an &lt;open/&gt; child element:</p>
<example caption='Open validation'><![CDATA[
-<field var='evt.category'
- type='list-single'
+<field var='evt.category'
+ type='list-single'
label='Event Category'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:string'>
@@ -161,7 +161,7 @@
<field var='evt.date' type='text-single' label='Event Date/Time'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:dateTime'>
- <range min='2003-10-05T00:00:00-07:00'
+ <range min='2003-10-05T00:00:00-07:00'
max='2003-10-24T23:59:59-07:00'/>
</validate>
<value>2003-10-06T11:22:00-07:00</value>
@@ -191,8 +191,8 @@
<section2 topic='Selection Ranges in "list-multi"' anchor='usecases-ranges'>
<p>For "list-multi", validation can indicate (via the &lt;list-range/&gt; element) that a minimum and maximum number of options should be selected and/or entered. This selection range MAY be combined with the other methods to provide more flexibility.</p>
<example caption='Selection Range validation'><![CDATA[
-<field var='evt.notify-methods'
- type='list-multi'
+<field var='evt.notify-methods'
+ type='list-multi'
label='Notify me by'>
<validate xmlns='http://jabber.org/protocol/xdata-validate'
datatype='xs:string'>
@@ -225,7 +225,7 @@
<p>While all elements associated with this document MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.</p>
<p>The use of namespace prefixes is RECOMMENDED for large forms, to reduce the data size. To maintain the highest level of compatibility, implementations sending the form using prefixes SHOULD use the namespace prefix "xdv", and SHOULD declare the namespace prefix mapping in the ancestor &lt;x xmlns='jabber:x:data'/&gt; element:</p>
<example caption='Example of recommended namespace prefixing'><![CDATA[
-<x xmlns='jabber:x:data'
+<x xmlns='jabber:x:data'
xmlns:xdv='http://jabber.org/protocols/xdata-validate'
type='form'>
<title>Sample Form</title>
@@ -264,7 +264,7 @@
<th>SHOULD NOT be Allowed</th>
<th>Display Suggestions</th>
</tr>
-
+
<tr>
<td>basic</td>
<td><ul>
@@ -281,7 +281,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale</td>
</tr>
-
+
<tr>
<td>open</td>
<td><ul>
@@ -297,7 +297,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale. For "text-multi" treat each value as a discrete entry (e.g. a user-entered list). For "list-multi" or "list-single", allow user to add/remove entries to select.</td>
</tr>
-
+
<tr>
<td>range</td>
<td><ul>
@@ -311,7 +311,7 @@
</ul></td>
<td>Display the datatype appropriate to the locale. For "text-single", allow user to increment/decrement through possible values. For "text-multi" treat each value as a discrete entry (e.g. a user-entered list). For "list-multi" or "list-single", allow user to add/remove entries to select.</td>
</tr>
-
+
<tr>
<td>regex</td>
<td><ul>
@@ -488,7 +488,7 @@
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
-
+
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/xdata-validate'
@@ -506,17 +506,17 @@
</xs:choice>
<xs:element ref='list-range' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
- <xs:attribute name='datatype'
- type='xs:string'
- use='optional'
+ <xs:attribute name='datatype'
+ type='xs:string'
+ use='optional'
default='xs:string'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='basic' type='empty'/>
-
+
<xs:element name='open' type='empty'/>
-
+
<xs:element name='range'>
<xs:complexType>
<xs:simpleContent>
@@ -527,24 +527,24 @@
</xs:simpleContent>
</xs:complexType>
</xs:element>
-
+
<xs:element name='regex' type='xs:string'/>
-
+
<xs:element name='list-range'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
- <xs:attribute name='min'
+ <xs:attribute name='min'
type='xs:unsignedInt'
use='optional'/>
- <xs:attribute name='max'
+ <xs:attribute name='max'
type='xs:unsignedInt'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
-
+
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
diff --git a/xep-0124.xml b/xep-0124.xml
index 359f1e5..f8fbb01 100644
--- a/xep-0124.xml
+++ b/xep-0124.xml
@@ -252,7 +252,7 @@ first socket second socket
+-+
|
+-+ <-- empty body request
- |X| socket opened --> ===
+ |X| socket opened --> ===
|-| |
| | new message out --> +-+
|-| <-- empty body response |X|
@@ -291,7 +291,7 @@ first socket second socket
| +-+
| |
| empty body request --> +-+
- | |X|
+ | |X|
| |-|
| | |
| | |
diff --git a/xep-0127.xml b/xep-0127.xml
index fd55bae..810f2b8 100644
--- a/xep-0127.xml
+++ b/xep-0127.xml
@@ -63,7 +63,7 @@
<p>In the case of direct messages, the message stanza SHOULD have no 'type' attribute, but MAY have any defined type that is appropriate to the communications context (e.g., "groupchat" in a text conference). The &lt;alert/&gt; element SHOULD be the only child element of the message stanza, but other elements MAY be included as necessary (e.g., a &lt;body/&gt; child in the 'jabber:client' namespace providing a natural-language description of the alert). The 'id' attribute of the &MESSAGE; stanza MAY be set to the value of the CAP &lt;identifier/&gt; element.</p>
<p>The following example shows Example A.2 from the CAP specification sent as a direct message.</p>
<example caption='An Alert Sent as a Message'><![CDATA[
-<message from='KSTO@NWS.NOAA.GOV'
+<message from='KSTO@NWS.NOAA.GOV'
to='weatherbot@jabber.org'
id='KSTO1055887203'>
<alert xmlns='http://www.incident.com/cap/1.0'>
@@ -82,10 +82,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
- AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
- INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
- COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
- MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
+ AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
+ INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
+ COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
+ MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@@ -94,12 +94,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
- EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
+ EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
- 38.47,-120.14 38.34,-119.95 38.52,-119.74
+ 38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>
@@ -138,10 +138,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
- AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
- INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
- COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
- MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
+ AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
+ INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
+ COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
+ MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@@ -150,12 +150,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
- EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
+ EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
- 38.47,-120.14 38.34,-119.95 38.52,-119.74
+ 38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>
@@ -191,10 +191,10 @@
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>
- AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
- INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
- COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
- MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
+ AT 254 PM PDT... NATIONAL WEATHER SERVICE DOPPLER RADAR
+ INDICATED A SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE
+ COUNTY... OR ABOUT 18 MILES SOUTHEAST OF KIRKWOOD...
+ MOVING SOUTHWEST AT 5 MPH. HAIL... INTENSE RAIN AND STRONG
DAMAGING WINDS ARE LIKELY WITH THIS STORM
</description>
<instruction>
@@ -203,12 +203,12 @@
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>
- EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
+ EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA,
EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA,
SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA
</areaDesc>
<polygon>
- 38.47,-120.14 38.34,-119.95 38.52,-119.74
+ 38.47,-120.14 38.34,-119.95 38.52,-119.74
38.62,-119.89 38.47,-120.14
</polygon>
<geocode>fips6=006109</geocode>
diff --git a/xep-0129.xml b/xep-0129.xml
index 62287a2..4021a7f 100644
--- a/xep-0129.xml
+++ b/xep-0129.xml
@@ -137,18 +137,18 @@
Host: files.shakespeare.lit
Authorization: Digest username="juliet@capulet.com",
realm="xmpp",
- nonce="ec2cc00f21f71acd35ab9be057970609",
+ nonce="ec2cc00f21f71acd35ab9be057970609",
uri="missive.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
- opaque="5ccc069c403ebaf9f0171e9517f40e41"
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example>
<p>The server then checks to ensure that the provided JID was specified via the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
- from='files.shakespeare.lit'
+ from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<confirm xmlns='http://jabber.org/protocol/http-auth'
diff --git a/xep-0130.xml b/xep-0130.xml
index 1a903fd..eeac873 100644
--- a/xep-0130.xml
+++ b/xep-0130.xml
@@ -349,16 +349,16 @@
</ol>
</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.
- <ol>
- <li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
- <li>Use Case Ends unsuccessfully.</li>
- </ol>
+ <ol>
+ <li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
+ <li>Use Case Ends unsuccessfully.</li>
+ </ol>
</li>
<li>All Users Remove Contact from Their WaitingLists
- <ol>
- <li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
+ <ol>
+ <li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
<li>Use Case Ends unsuccessfully.</li>
- </ol>
+ </ol>
</li>
</ol>
</section3>
@@ -604,7 +604,7 @@
<p>If none of the "modify" errors was generated and WaitingListService does not know Contact JID when the IQ result is returned to the user, it needs to contact InteropPartners in order to determine if the Contact is associated with one of the InteropPartners. Thus before it returns the Contact JID to the IM User, it needs to wait for the one of the InteropPartners to return Contact JID or for all of the InteropPartners to return errors.</p>
<p>If all of the InteropPartners return an error of type "cancel" (typically &notfound; and/or &notauthorized;) to WaitingListService, WaitingListService MUST return an &notfound; error (or local equivalent) to the IM User (and IM User SHOULD complete <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case).</p>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
-<message
+<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
@@ -646,12 +646,12 @@
to='user@service-provider.com'>
<body>Sorry, we cannot find this contact.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
- <item id='34567'
+ <item id='34567'
jid='contact@service-provider.com'
type='error'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
- <error code='404'
+ <error code='404'
type='cancel'
xmlns='jabber:client'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@@ -815,7 +815,7 @@
]]></example>
<p>If ServiceProvider's WaitingListService receives &notauthorized; and/or &notfound; errors from all InteropPartners, it returns a &notfound; error to IM User:</p>
<example caption='WaitingListService Returns &notfound; Error to IM User'><![CDATA[
-<message
+<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
diff --git a/xep-0131.xml b/xep-0131.xml
index dafd355..551598d 100644
--- a/xep-0131.xml
+++ b/xep-0131.xml
@@ -189,7 +189,7 @@
<p>The Distribute header enables a sender to specify whether the stanza may be further distributed by the recipient to other entities on the network. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT further distribute the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY further distribute the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". This header is semantically equivalent to the "Distribute" flag defined in &geoprivpol;. (The HTTP "Max-Forwards" header is not appropriate for this usage, since it defines proxy and gateway behavior rather than recipient behavior.) Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
</section2>
<section2 topic='Store' anchor='headers-store'>
- <p>The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT store the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY store the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
+ <p>The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false". If the sender specifies a value of "false", the recipient MUST NOT store the stanza or any information contained therein; if the sender specifies a value of "true", the recipient MAY store the stanza or any information contained therein; if the value is anything other than "true" or "false" and the recipient does not understand the value, the recipient MUST assume the default value of "false". Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
</section2>
<section2 topic='TTL' anchor='headers-ttl'>
<p>It may be useful to specify that the information contained in a stanza is valid only for a limited period of time. Such is the function of the "TTL" header, the value of which is some number of seconds since the creation of the stanza. Note well that this header is purely informational and MUST NOT be used for routing or delivery of XML stanzas, since that function is already served by &xep0079;. A stanza that includes the "TTL" header SHOULD also include a "Created" header so that the recipient can properly process the stanza.</p>
@@ -225,7 +225,7 @@
<section2 topic='Urgency' anchor='headers-urgency'>
<p>It can be useful to specify that the information contained in a stanza is more or less time-sensitive (e.g., in order to help the recipient determine whether to attend to the information immediately or to delay attending to the information). Such is the function of the "Urgency" header, the value of which is "high", "medium", or "low". One use of the header is Sieve notifications (see &sievenotify;) sent via XMPP, as specified in &sievenotifyxmpp;.</p>
<example caption='An Urgent Message'><![CDATA[
-<message
+<message
from='romeo@shakespeare.lit/orchard'
to='juliet@capulet.com'
type='chat'>
diff --git a/xep-0132.xml b/xep-0132.xml
index e446207..54af4e7 100644
--- a/xep-0132.xml
+++ b/xep-0132.xml
@@ -43,7 +43,7 @@
<p>As defined in <cite>XMPP IM</cite>, presence stanzas of type "probe" are handled on behalf of the target entity by the entity's server. While normally these presence stanzas are generated by the requesting entity's server (e.g., when the requesting entity sends initial presence), the requesting entity itself (or, more precisely, its client) is allowed to generate presence stanzas of type "probe". In this document we make use of this ability to query the target entity's server regarding the entity's physical presence.</p>
<p>In the following example, a star-crossed lover pokes the server of his beloved to determine her physical presence (notice that the value of 'to' address lacks a resource identifier and therefore is a bare JID, not a full JID).</p>
<example caption='Poking via the server'><![CDATA[
-<presence
+<presence
type='probe'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
@@ -53,28 +53,28 @@
]]></example>
<p>If the user's server does not support the POKE protocol, it SHOULD ignore the extension and treat the presence stanza as a normal (non-IRL) presence probe. However, the user's server MAY return a "Service Unavailable" error to the requesting entity to inform the requesting entity that IRL probes are not supported (for details regarding error syntax, refer to &xep0086;):</p>
<example caption='Server returns service unavailable error'><![CDATA[
-<presence
+<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='503' type='cancel'>
- <service-unavailable
+ <service-unavailable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></example>
<p>If the user's server supports the POKE protocol, it MUST first perform appropriate access checks to determine if the requesting entity has permission to view the user's presence (e.g., by checking presence subscriptions and privacy lists). If the user's server determines that the requesting entity is not allowed to learn the user's physical presence information, it MUST return a "Forbidden" error:</p>
<example caption='Server returns forbidden error'><![CDATA[
-<presence
+<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='403' type='auth'>
- <forbidden
+ <forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
@@ -87,7 +87,7 @@
</ol>
<p>If the server determines that the user is physically present in the vicinity of a client, it SHOULD return that information to the requesting entity, including the appropriate resource:</p>
<example caption='Server returns success'><![CDATA[
-<presence
+<presence
from='juliet@capulet.com/chamber'
to='romeo@montague.net/orchard'
id='poke1'>
@@ -96,21 +96,21 @@
]]></example>
<p>The server SHOULD NOT wait an inordinate amount of time before returning the presence information (e.g., usually not more than two minutes), but the timeout period SHOULD be configurable. If the request times out, the server SHOULD return a "Request Timeout" error to the requesting entity:</p>
<example caption='Server returns request timeout error'><![CDATA[
-<presence
+<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='408' type='wait'>
- <remote-server-timeout
+ <remote-server-timeout
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></example>
<p>The server SHOULD NOT return a "Not Found" error unless the user does not exist. If the server determines that the user has died, it MAY return a "Gone" error with appropriate descriptive text, although it SHOULD wait to do so pending notification of next-of-kin; note well that such notification is out of scope for this document (though this seems like a sensible application of the &xep0060; protocol):</p>
<example caption='Server returns gone error'><![CDATA[
-<presence
+<presence
type='error'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
@@ -119,7 +119,7 @@
<error code='302' type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
- Please accept our condolences: the user you are
+ Please accept our condolences: the user you are
trying to reach has died.
</text>
</error>
@@ -146,7 +146,7 @@
id='poke1'>
<poke xmlns='http://jabber.org/protocol/poke'/>
<error code='501' type='cancel'>
- <feature-not-implemented
+ <feature-not-implemented
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
@@ -223,8 +223,8 @@
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
- <xs:attribute name='method'
- use='optional'
+ <xs:attribute name='method'
+ use='optional'
type='xs:NCName'/>
</xs:extension>
</xs:simpleContent>
diff --git a/xep-0133.xml b/xep-0133.xml
index 33d3078..4e271c2 100644
--- a/xep-0133.xml
+++ b/xep-0133.xml
@@ -142,7 +142,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#add-user'/>
</iq>
@@ -154,7 +154,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'
status='executing'>
@@ -194,7 +194,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -229,7 +229,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#add-user'
sessionid='add-user:20040408T0337Z'
status='completed'/>
@@ -246,7 +246,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-user'/>
</iq>
@@ -258,7 +258,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'
status='executing'>
@@ -284,7 +284,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -304,7 +304,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-user'
sessionid='delete-user:20040408T0337Z'
status='completed'/>
@@ -320,7 +320,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#disable-user'/>
</iq>
@@ -332,7 +332,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'
status='executing'>
@@ -358,7 +358,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -378,7 +378,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#disable-user'
sessionid='disable-user:20040408T0337Z'
status='completed'/>
@@ -394,7 +394,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#reenable-user'/>
</iq>
@@ -406,7 +406,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'
status='executing'>
@@ -432,7 +432,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -452,7 +452,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#reenable-user'
sessionid='reenable-user:20040408T0337Z'
status='completed'/>
@@ -460,7 +460,7 @@
]]></example>
</section2>
<section2 topic='End User Session' anchor='end-user-session'>
- <p>An administrator may need to terminate one or all of the user's current sessions, but allow future logins (this can be thought of as "kicking" rather than "banning" the user). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#end-user-session".</p>
+ <p>An administrator may need to terminate one or all of the user's current sessions, but allow future logins (this can be thought of as "kicking" rather than "banning" the user). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#end-user-session".</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests to End a User&apos;s Session'><![CDATA[
<iq from='bard@shakespeare.lit/globe'
@@ -468,7 +468,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#end-user-session'/>
</iq>
@@ -480,7 +480,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'
status='executing'>
@@ -506,7 +506,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -526,7 +526,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#end-user-session'
sessionid='end-user-session:20040408T0337Z'
status='completed'/>
@@ -542,7 +542,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-password'/>
</iq>
@@ -554,7 +554,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'
status='executing'>
@@ -580,7 +580,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -601,7 +601,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-password'
sessionid='get-user-password:20040408T0337Z'
status='completed'>
@@ -629,7 +629,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#change-user-password'/>
</iq>
@@ -641,7 +641,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'
status='executing'>
@@ -672,7 +672,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -695,7 +695,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#change-user-password'
sessionid='change-user-password:20040408T0337Z'
status='completed'/>
@@ -711,7 +711,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-roster'/>
</iq>
@@ -723,7 +723,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'
status='executing'>
@@ -749,7 +749,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -770,7 +770,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-roster'
sessionid='get-user-roster:20040408T0337Z'
status='completed'>
@@ -813,7 +813,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-user-lastlogin'/>
</iq>
@@ -825,7 +825,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'
status='executing'>
@@ -851,7 +851,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -872,7 +872,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-user-lastlogin'
sessionid='get-user-lastlogin:20040408T0337Z'
status='completed'>
@@ -900,7 +900,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#user-stats'/>
</iq>
@@ -912,7 +912,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'
status='executing'>
@@ -937,7 +937,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -957,7 +957,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#user-stats'
sessionid='user-stats:20040408T0337Z'
status='completed'>
@@ -996,7 +996,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-blacklist'/>
</iq>
@@ -1008,7 +1008,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'
status='executing'>
@@ -1035,7 +1035,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1057,7 +1057,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-blacklist'
sessionid='edit-blacklist:20040408T0337Z'
status='completed'/>
@@ -1074,7 +1074,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-whitelist'/>
</iq>
@@ -1086,7 +1086,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'
status='executing'>
@@ -1116,7 +1116,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1139,7 +1139,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='edit-whitelist:20040408T0337Z'
status='completed'/>
@@ -1155,7 +1155,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-num'/>
</iq>
@@ -1167,7 +1167,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-num'
sessionid='get-registered-users-num:20040408T0337Z'
status='completed'>
@@ -1193,7 +1193,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-num'/>
</iq>
@@ -1205,7 +1205,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-num'
sessionid='get-disabled-users-num:20040408T0337Z'
status='completed'>
@@ -1231,7 +1231,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-online-users-num'/>
</iq>
@@ -1243,7 +1243,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@@ -1269,7 +1269,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-active-users-num'/>
</iq>
@@ -1281,7 +1281,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@@ -1307,7 +1307,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-idle-users-num'/>
</iq>
@@ -1319,7 +1319,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users-num'
sessionid='get-online-users-num:20040408T0337Z'
status='completed'>
@@ -1345,7 +1345,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-registered-users-list'/>
</iq>
@@ -1361,7 +1361,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users-list:20040408T0337Z'
status='executing'>
@@ -1395,7 +1395,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1415,7 +1415,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-registered-users-list'
sessionid='get-registered-users:20040408T0337Z'
status='completed'>
@@ -1463,7 +1463,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-disabled-users-list'/>
</iq>
@@ -1479,7 +1479,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users-list:20040408T0337Z'
status='executing'>
@@ -1513,7 +1513,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1533,7 +1533,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-disabled-users-list'
sessionid='get-disabled-users:20040408T0337Z'
status='completed'>
@@ -1562,7 +1562,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-online-users-list'/>
</iq>
@@ -1578,7 +1578,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-list'
sessionid='get-online-users-list:20040408T0337Z'
status='executing'>
@@ -1612,7 +1612,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-whitelist'
sessionid='get-online-users-list:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1632,7 +1632,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-online-users-list'
sessionid='get-online-users:20040408T0337Z'
status='completed'>
@@ -1671,7 +1671,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-active-users'/>
</iq>
@@ -1687,7 +1687,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'
status='executing'>
@@ -1721,7 +1721,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1741,7 +1741,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-active-users'
sessionid='get-active-users:20040408T0337Z'
status='completed'>
@@ -1773,7 +1773,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#get-idle-users'/>
</iq>
@@ -1789,7 +1789,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-idle-users:20040408T0337Z'
status='executing'>
@@ -1823,7 +1823,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-idle-users:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1843,7 +1843,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#get-idle-users'
sessionid='get-active-users:20040408T0337Z'
status='completed'>
@@ -1877,7 +1877,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#announce'/>
</iq>
@@ -1889,7 +1889,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'
status='executing'>
@@ -1917,7 +1917,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -1939,7 +1939,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#announce'
sessionid='announce:20040408T0337Z'
status='completed'/>
@@ -1947,7 +1947,7 @@
]]></example>
</section2>
<section2 topic='Set Message of the Day' anchor='set-motd'>
- <p>Administrators of some existing Jabber servers have found it useful to be able to send a "message of the day" that is delivered to any user who logs in to the server that day (e.g., to announce service changes);
+ <p>Administrators of some existing Jabber servers have found it useful to be able to send a "message of the day" that is delivered to any user who logs in to the server that day (e.g., to announce service changes);
<note>Typically, a "message of the day" is an announcement that is sent once to all users of a server or a service until and unless the message is deleted; it can be thought of as a "standing announcement" as opposed to the "one-time announcement" sent to all online users in the previous use cases. The announcement is sent immediately to users who are online when the message is set, or after the next session initiation for other users (e.g., on server login or chatroom join).</note>
this concept can be extended to any service (such as a multi-user chat service or a gateway to a foreign IM service). The command node for this use case SHOULD be "http://jabber.org/protocol/admin#set-motd".</p>
<p>A sample protocol flow for this use case is shown below.</p>
@@ -1957,7 +1957,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#set-motd'/>
</iq>
@@ -1969,7 +1969,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'
status='executing'>
@@ -1996,7 +1996,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2020,7 +2020,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-motd'
sessionid='set-motd:20040408T0337Z'
status='completed'/>
@@ -2036,7 +2036,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-motd'/>
</iq>
@@ -2048,7 +2048,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'
status='executing'>
@@ -2080,7 +2080,7 @@
to='shakespeare.lit'
type='edit'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2104,7 +2104,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-motd'
sessionid='edit-motd:20040408T0337Z'
status='completed'/>
@@ -2120,7 +2120,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-motd'/>
</iq>
@@ -2132,7 +2132,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-motd'
sessionid='delete-motd:20040408T0337Z'
status='completed'/>
@@ -2148,7 +2148,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#set-welcome'/>
</iq>
@@ -2160,7 +2160,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'
status='executing'>
@@ -2190,7 +2190,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2213,7 +2213,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#set-welcome'
sessionid='set-welcome:20040408T0337Z'
status='completed'/>
@@ -2229,7 +2229,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#delete-welcome'/>
</iq>
@@ -2241,7 +2241,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#delete-welcome'
sessionid='delete-welcome:20040408T0337Z'
status='completed'/>
@@ -2257,7 +2257,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#edit-admin'/>
</iq>
@@ -2269,7 +2269,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'
status='executing'>
@@ -2298,7 +2298,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2319,7 +2319,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#edit-admin'
sessionid='edit-admin:20040408T0337Z'
status='completed'/>
@@ -2335,7 +2335,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#restart'/>
</iq>
@@ -2347,7 +2347,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'
status='executing'>
@@ -2381,7 +2381,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2405,7 +2405,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#restart'
sessionid='restart:20040408T0337Z'
status='completed'/>
@@ -2421,7 +2421,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/admin#shutdown'/>
</iq>
@@ -2433,7 +2433,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'
status='executing'>
@@ -2467,7 +2467,7 @@
to='shakespeare.lit'
type='set'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'>
<x xmlns='jabber:x:data' type='submit'>
@@ -2491,7 +2491,7 @@
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/admin#shutdown'
sessionid='shutdown:20040408T0337Z'
status='completed'/>
@@ -2527,7 +2527,7 @@
<td>The ad-hoc commands protocol is not supported.</td>
</tr>
</table>
- <p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p>
+ <p>For the syntax of these errors, see &xep0086;. Naturally, other errors may be returned as well (e.g., &internalserver; if the service cannot be shut down).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The ability to complete the administrative tasks specified herein MUST NOT be granted to users who lack service-level administrative privileges.</p>
diff --git a/xep-0134.xml b/xep-0134.xml
index 00bbd65..cbe6a0f 100644
--- a/xep-0134.xml
+++ b/xep-0134.xml
@@ -96,7 +96,7 @@
<p><em>Background</em></p>
<p>The core strength of Jabber technologies is the streaming of relatively small XML fragments between presence-aware network endpoints. As is usually the case, our greatest strength is also our greatest weakness. Thus XMPP is not optimized for binary data, large XML files, multimedia streaming, or other such applications.</p>
<p><em>Meaning</em></p>
- <p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band
+ <p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band
<note>There are no hard-and-fast rules regarding a reasonable upper limit on the average XML stanza. (Note the use of both 'reasonable' and 'average' in that sentence.) In reality, there is a continuum of stanza sizes, and different sizes may be appropriate for different types of XMPP applications and deployments. While sending 2 gigabyte or 2 megabyte stanzas is wrong in the current context of Jabber technologies, we cannot legitimately say that a 2 kilobyte, 20 kilobyte, or even 200 kilobyte stanza is unreasonable. Is the stanza sent over an open network with current server implementations, or over a closed network with specially tuned servers and clients? Does the application generate one such stanza every second, every minute, every hour? Considerations of this kind help us determine if the use of XMPP is "reasonable" in some sense. However, when protocol extensions are defined in XMPP Extension Protocols, the XMPP Council will require clear explanation of design choices and reasonable stanza size limits if the extension will generally require what might be considered larger than normal stanzas.</note>
is probably not a good idea, and applications that would depend on such behavior are better designed to communicate their data out of band.</p>
<p><em>Examples</em></p>
diff --git a/xep-0135.xml b/xep-0135.xml
index e5bb679..61a14bc 100644
--- a/xep-0135.xml
+++ b/xep-0135.xml
@@ -31,7 +31,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Existing Jabber protocols provide a strong foundation for the controlled, permissions-based sharing of files between Jabber entities, e.g., to enable shared workspaces among ad-hoc workgroups and the attachment of files to &xep0045; rooms.</p>
- <p>This document defines several additional building blocks (a simple request protocol along with well-known service discovery nodes) that tie together existing protocols to enable the sharing of files between Jabber entities.</p>
+ <p>This document defines several additional building blocks (a simple request protocol along with well-known service discovery nodes) that tie together existing protocols to enable the sharing of files between Jabber entities.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ol>
@@ -83,7 +83,7 @@
id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
- <item jid='darkcave@macbeth.shakespeare.lit'
+ <item jid='darkcave@macbeth.shakespeare.lit'
node='files'
name='The files attached to this room'/>
...
@@ -127,7 +127,7 @@
id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
- <item jid='romeo@files.shakespeare.lit'
+ <item jid='romeo@files.shakespeare.lit'
node='files'
name='Romeo&apos;s Files'/>
...
@@ -142,7 +142,7 @@
<example caption='Requesting the File List'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'/>
@@ -151,7 +151,7 @@
<p>If the requesting entity is not allowed to view the offering entity's files (the requesting entity is not an occupant of a chatroom, is not registered with the offering entity, is not a contact in a user's roster, etc.) or the offering entity has no files to share, the offering entity SHOULD return an empty &QUERY; element:</p>
<example caption='No Files to Share'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
@@ -161,10 +161,10 @@
<p>If the requesting entity is allowed to view the offering entity's files and the offering entity has files to share, the offering entity SHOULD return a list of items:</p>
<example caption='Returning the File List'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='files'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir'/>
@@ -182,7 +182,7 @@
<example caption='Requesting Further Information (1)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir'/>
@@ -191,10 +191,10 @@
<p>If the item is a directory, the offering entity SHOULD return information about the directory, including an identity whose category is "filesys" and whose type is "directory":</p>
<example caption='Returning Further Information (1)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info1'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir'>
<identity category='filesys' type='directory'/>
</query>
@@ -204,7 +204,7 @@
<example caption='Requesting Further Information (2)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/>
@@ -213,10 +213,10 @@
<p>If the item is a file, the offering entity SHOULD return information about the file, including an identity whose category is "filesys" and whose type is "file":</p>
<example caption='Returning Further Information (2)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info2'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'>
<identity category='filesys' type='file' name='file1'/>
</query>
@@ -227,7 +227,7 @@
<example caption='Requesting Further Items (1)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir'/>
@@ -236,10 +236,10 @@
<p>The offering entity will then return a list of files and directories contained within the queried directory:</p>
<example caption='Returning Further Items (1)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='items1'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir/anotherdir'/>
@@ -253,7 +253,7 @@
<example caption='Requesting Further Information (3)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='info3'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir'/>
@@ -261,10 +261,10 @@
]]></example>
<example caption='Returning Further Information (3)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info3'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir'>
<identity category='filesys' type='directory'/>
</query>
@@ -273,7 +273,7 @@
<example caption='Requesting Further Information (4)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='info4'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherfile'/>
@@ -281,10 +281,10 @@
]]></example>
<example caption='Returning Further Information (4)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info4'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherfile'>
<identity category='filesys' type='file' name='file2'/>
</query>
@@ -293,7 +293,7 @@
<example caption='Requesting Further Items (2)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='items2'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir/anotherdir'/>
@@ -301,10 +301,10 @@
]]></example>
<example caption='Returning Further Items (2)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='items2'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='files/somedir/anotherdir'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir/anotherdir/yetanotherfile'
@@ -315,7 +315,7 @@
<example caption='Requesting Further Information (5)'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='info5'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir/yetanotherfile'/>
@@ -323,10 +323,10 @@
]]></example>
<example caption='Returning Further Information (5)'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info5'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somedir/anotherdir/yetanotherfile'>
<identity category='filesys' type='file' name='file3'/>
</query>
@@ -348,7 +348,7 @@ share
<example caption='Requesting the File List'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='avail'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='files'/>
@@ -356,10 +356,10 @@ share
]]></example>
<example caption='Returning the File List'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='avail'>
- <query xmlns='http://jabber.org/protocol/disco#items'
+ <query xmlns='http://jabber.org/protocol/disco#items'
node='files'>
<item jid='darkcave@macbeth.shakespeare.lit'
node='files/somedir'/>
@@ -397,7 +397,7 @@ share
<example caption='Requesting File Information'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='file1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'/>
@@ -405,10 +405,10 @@ share
]]></example>
<example caption='Returning Detailed File Information'><![CDATA[
<iq type='result'
- from='darkcave@macbeth.shakespeare.lit'
+ from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
id='info2'>
- <query xmlns='http://jabber.org/protocol/disco#info'
+ <query xmlns='http://jabber.org/protocol/disco#info'
node='files/somefile'>
<identity category='filesys' type='file' name='file1'/>
<x xmlns='jabber:x:data' type='result'>
@@ -442,7 +442,7 @@ share
<example caption='Retrieving a File'><![CDATA[
<iq type='get'
from='hag66@shakespeare.lit/pda'
- to='darkcave@macbeth.shakespeare.lit'
+ to='darkcave@macbeth.shakespeare.lit'
id='retrieve1'>
<retrieve xmlns='http://jabber.org/protocol/files'
node='files/somefile'/>
@@ -455,11 +455,11 @@ share
]]></example>
<example caption='Offering Entity Initiates File Transfer'>
<![CDATA[
-<iq type='set'
- from='darkcave@macbeth.shakespeare.lit'
- id='offer1'
+<iq type='set'
+ from='darkcave@macbeth.shakespeare.lit'
+ id='offer1'
to='hag66@shakespeare.lit/pda'>
- <si xmlns='http://jabber.org/protocol/si'
+ <si xmlns='http://jabber.org/protocol/si'
id='file1'
mime-type='text/plain'
profile='http://jabber.org/protocol/si/profile/file-transfer'>
@@ -537,7 +537,7 @@ share
targetNamespace='http://jabber.org/protocol/files'
xmlns='http://jabber.org/protocol/files'
elementFormDefault='qualified'>
-
+
<xs:element name='retrieve'>
<xs:complexType>
<xs:simpleContent>
diff --git a/xep-0136.xml b/xep-0136.xml
index c569e68..2165956 100644
--- a/xep-0136.xml
+++ b/xep-0136.xml
@@ -203,7 +203,7 @@
<p>In order to capture a complete set of preferences, when the server returns the user's preferences to the client the &lt;pref/&gt; element:</p>
<ul>
<li>MUST include an &lt;auto/&gt; element that specifies whether automatic archiving is on or off.</li>
- <li>MUST include a &lt;default/&gt; element that specifies the user's default settings for OTR Mode and Save Mode.</li>
+ <li>MUST include a &lt;default/&gt; element that specifies the user's default settings for OTR Mode and Save Mode.</li>
<li>MAY include one or more &lt;item/&gt; elements that specify preferences related to particular contacts.</li>
<li>MAY include one or more &lt;session/&gt; elements that specifies whether automatic archiving is on or off for a given chat session.</li>
<li>MUST include at least three &lt;method/&gt; elements, differentiated by the value of the 'type' attribute (i.e., at least one &lt;method/&gt; element each for "auto", "local", and "manual").</li>
@@ -488,7 +488,7 @@
]]></example>
</section2>
<section2 topic='Setting Archiving Method Preferences' anchor='pref-archive'>
- <p>The client can set one or more method preferences by sending an IQ-set containing a &lt;pref/&gt; element that in turn contains one or more &lt;method/&gt; elements.</p>
+ <p>The client can set one or more method preferences by sending an IQ-set containing a &lt;pref/&gt; element that in turn contains one or more &lt;method/&gt; elements.</p>
<example caption='Client Sets Method Preferences'><![CDATA[
<iq type='set' id='pref5'>
<pref xmlns='urn:xmpp:archive'>
@@ -1176,7 +1176,7 @@
<example caption='Client Service Discovery request'>
<![CDATA[
<iq from='romeo@montague.net/orchard'
- id='disco1'
+ id='disco1'
to='montague.net'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@@ -1186,7 +1186,7 @@
<example caption='Server Service Discovery response'>
<![CDATA[
<iq from='montague.net'
- id='disco1'
+ id='disco1'
to='romeo@montague.net/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'>
diff --git a/xep-0139.xml b/xep-0139.xml
index d9a6ab2..c1f0dc2 100644
--- a/xep-0139.xml
+++ b/xep-0139.xml
@@ -45,16 +45,16 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Because security is a core value within the Jabber community, it is appropriate for the XMPP Standards Foundation to assess potential security threats related to technologies that implement the Jabber protocols (including XMPP and defined XMPP extensions), as well as ways to address the threats (for general information about the Internet threat model, see &rfc3552;). Furthermore, since security threats are wide-ranging and of broad concern, it would be valuable for interested members of the entire Jabber community to discuss these matters. Unfortunately, security discussions can often be theoretical, contentious, and inconclusive. Thus it is imperative that discussion proceed based on a methodical process of threat identification, risk analysis, and prioritization before moving on to documentation of threat responses (preferably in protocol specifications such as &xep0001;). This document proposes a forum and process for such security discussions in the form of a Special Interest Group (see &xep0002;) that shall report to the &COUNCIL; in accordance with Article VIII of the &BYLAWS;.</p>
-</section1>
+</section1>
<section1 topic='Scope and Role' anchor='scope'>
<p>The role of the Security SIG shall be to identify and describe security threats related to Jabber technologies, analyze their potential risk, assign priorities to each threat, provide references to existing responses, and (where appropriate) provisionally recommend improvements in Jabber protocols and technologies in order to address the identified threats. The Security SIG shall not itself develop or approve protocols, which tasks shall remain under the purview of the &SSIG; and the Jabber Council respectively.</p>
-</section1>
+</section1>
<section1 topic='Membership' anchor='membership'>
<p>The Security SIG shall be open to the public and shall not be limited to elected members of the XMPP Standards Foundation. Security SIG discussions shall be conducted in open forums, including a dedicated mailing list at &lt;security-jig@jabber.org&gt;. The process for moderating such discussions shall be decided by the members of the Security SIG, but such moderation is strongly encouraged in order to follow the orderly process of threat identification and risk analysis outlined below.</p>
-</section1>
+</section1>
<section1 topic='Lifetime' anchor='lifetime'>
<p>The Security SIG shall be a standing SIG, and shall exist as long as the Jabber Council deems it useful.</p>
-</section1>
+</section1>
<section1 topic='Deliverables' anchor='deliverables'>
<p>The Security SIG shall produce at least the following deliverables:</p>
<ol>
@@ -78,7 +78,7 @@
<li>Existing approaches for addressing the threat (e.g., as documented in a XEP)</li>
<li>The gap between the identified threat and existing responses</li>
<li>Potential approaches to addressing the threat or closing the gap, including implementation issues associated with each approach (since security measures that cannot or will not be implemented are useless)</li>
- <li>Current recommended approach (which may be "do nothing at this time")</li>
+ <li>Current recommended approach (which may be "do nothing at this time")</li>
</ol>
<p>The template will not fully define the foregoing information, but instead specify what information must be defined for each threat when completing the analysis described in Step 3.</p>
</li>
diff --git a/xep-0140.xml b/xep-0140.xml
index 50e092b..67e4083 100644
--- a/xep-0140.xml
+++ b/xep-0140.xml
@@ -116,7 +116,7 @@
<publish node='groups/Marketing/Europe'>
<item id='alice@example.com'>
<x xmlns='jabber:x:roster'
- jid='alice@example.com'
+ jid='alice@example.com'
name='Alice Rosenbaum'>
<group>Marketing/Europe</group>
</x>
@@ -134,7 +134,7 @@
<items node='groups/Marketing/Europe'>
<item id='alice@example.com'>
<x xmlns='jabber:x:roster'
- jid='alice@example.com'
+ jid='alice@example.com'
name='Alice Rosenbaum'>
<group>Marketing/Europe</group>
</x>
@@ -210,7 +210,7 @@
<p>An administrator may wish to define a hierarchy of shared groups (e.g., "Marketing/Europe" and "Marketing/North America"). This can be done using collection nodes as defined in Section 9 of XEP-0060. The receiving application MAY use &xep0083; to define the roster group names.</p>
</section2>
<section2 topic='Exchanging Presence' anchor='impl-pres'>
- <p>Presence is exchanged via the normal mechanisms defined in <strong>XMPP IM</strong>.</p>
+ <p>Presence is exchanged via the normal mechanisms defined in <strong>XMPP IM</strong>.</p>
</section2>
<section2 topic='Sending Messages' anchor='impl-msg'>
<p>In order to send a message to all members of a shared group, a group member's sending application (usually an end-user client) SHOULD either send multiple messages or use &xep0033;.</p>
diff --git a/xep-0141.xml b/xep-0141.xml
index 84946e9..a8ed7ac 100644
--- a/xep-0141.xml
+++ b/xep-0141.xml
@@ -68,7 +68,7 @@
<x xmlns='jabber:x:data' type='form'>
<title>XSF Application</title>
<instructions>Please fill out this form</instructions>
-
+
<field var='name.first' type='text-single' label='First Name'>
<required/>
</field>
@@ -81,14 +81,14 @@
<field var='jid' type='jid-single' label='Jabber JID'>
<required/>
</field>
-
+
<field var='background' type='text-multi' label='Background Information'>
</field>
<field var='future' type='text-multi' label='Jabber Plans for the Next Six Months'>
</field>
<field var='reasoning' type='text-multi' label='Reasons for Joining'>
</field>
-
+
<field var='activity.mailing-lists' type='text-multi' label='Recent Mailing List Activity'>
</field>
<field var='activity.xeps' type='text-multi' label='XEPs Authored or Co-Authored'>
@@ -105,8 +105,8 @@
<page xmlns='http://jabber.org/protocol/xdata-layout' label='Personal Information'>
<text>This is page one of three.</text>
<text>
- Note: In accordance with the XSF privacy policy, your personal information will
- never be shared outside the organization in any way for any purpose; however,
+ Note: In accordance with the XSF privacy policy, your personal information will
+ never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<fieldref var='name.first'/>
@@ -118,7 +118,7 @@
<page xmlns='http://jabber.org/protocol/xdata-layout' label='Community Activity'>
<text>This is page two of three.</text>
<text>
- We use this page to gather information about any XEPs you&apos;ve worked on,
+ We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@@ -129,7 +129,7 @@
<text>This is page three of three.</text>
<text>You're almost done!</text>
<text>
- This is where you describe your future plans and why you think you
+ This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
@@ -170,8 +170,8 @@
<page xmlns='http://jabber.org/protocol/xdata-layout'>
<section label='Personal Information'>
<text>
- Note: In accordance with the XSF privacy policy, your personal information will
- never be shared outside the organization in any way for any purpose; however,
+ Note: In accordance with the XSF privacy policy, your personal information will
+ never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<fieldref var='name.first'/>
@@ -182,7 +182,7 @@
</section>
<section label='Community Activity'>
<text>
- We use this page to gather information about any XEPs you&apos;ve worked on,
+ We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@@ -192,7 +192,7 @@
<section label='Plans and Reasoning'>
<text>You're almost done!</text>
<text>
- This is where you describe your future plans and why you think you
+ This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
@@ -228,12 +228,12 @@
<example caption='Sections of fields (nested)'><![CDATA[
<x xmlns='jabber:x:data' type='form'>
...
-
+
<page xmlns='http://jabber.org/protocol/xdata-layout'>
<section label='Personal Information'>
<text>
- Note: In accordance with the XSF privacy policy, your personal information will
- never be shared outside the organization in any way for any purpose; however,
+ Note: In accordance with the XSF privacy policy, your personal information will
+ never be shared outside the organization in any way for any purpose; however,
your name and JID may be published in the XSF membership directory.
</text>
<section label='Name'>
@@ -250,7 +250,7 @@
</section>
<section label='Community Activity'>
<text>
- We use this page to gather information about any XEPs you&apos;ve worked on,
+ We use this page to gather information about any XEPs you&apos;ve worked on,
as well as your mailing list activity.
</text>
<text>You do post to the mailing lists, don't you?</text>
@@ -259,18 +259,18 @@
</section>
<section label='Plans and Reasoning'>
<text>
- This is where you describe your future plans and why you think you
+ This is where you describe your future plans and why you think you
deserve to be a member of the XMPP Standards Foundation.
</text>
<fieldref var='future'/>
<fieldref var='reasoning'/>
</section>
</page>
-
+
...
</x>
]]></example>
- <p>Note: The preceding example partitions the fields into one page and three sections, with the first section being further partitioned into two sub-sections and one free-standing field reference.</p>
+ <p>Note: The preceding example partitions the fields into one page and three sections, with the first section being further partitioned into two sub-sections and one free-standing field reference.</p>
</section2>
<section2 topic="Including Tables" anchor='tables'>
<p>Data forms tables (the &lt;reported/&gt; and &lt;item/&gt; elements) can also be included in the layout, using the &lt;reportedref/&gt; element. This element MAY be included anywhere that the &lt;fieldref/&gt; element is allowed, but MUST NOT appear more than once.</p>
@@ -358,7 +358,7 @@
<xs:attribute name='label' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
-
+
<xs:element name='section'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
@@ -380,11 +380,11 @@
</xs:simpleContent>
</xs:complexType>
</xs:element>
-
+
<xs:element name='reportedref' type='empty'/>
<xs:element name='text' type='xs:string'/>
-
+
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
diff --git a/xep-0142.xml b/xep-0142.xml
index d8f9364..f642723 100644
--- a/xep-0142.xml
+++ b/xep-0142.xml
@@ -484,7 +484,7 @@ S: to='user@example.net/home'>
S: <x xmlns='http://jabber.org/protocol/muc#user'>
S: <invite from='support@workgroup.example.com'>
S: <reason>
-S: You have been invited to chat with a support@workgroup.example.com
+S: You have been invited to chat with a support@workgroup.example.com
agent.
S: </reason>
S: </invite>
@@ -700,14 +700,14 @@ Agent Service
<p>The workgroup service pushes presence updates to the agent as the presence of other agents changes. This will only occur after an agent has requested to receive other agents' information. The server will continue to send presence updates until the agent sends an unavailable presence to the server. This protocol is similar to the standard XMPP roster workflow.</p>
<p>To receive presence updates for other agents in the workgroup, the agent sends an agent info request to the workgroup:</p>
<example caption='Request Element'><![CDATA[
-U: <iq to='support@workgroup.example.com' from='alice@example.com/work'
+U: <iq to='support@workgroup.example.com' from='alice@example.com/work'
U: id='id1' type='get'>
U: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'/>
U: </iq>
]]></example>
<p>The workgroup will then reply with a list of all agents in the workgroup (excluding the agent making the request):</p>
<example caption='Response Element'><![CDATA[
-S: <iq to='alice@example.com/work' from='support@workgroup.example.com'
+S: <iq to='alice@example.com/work' from='support@workgroup.example.com'
S: id='id1' type='result'>
S: <agent-status-request xmlns='http://jabber.org/protocol/workgroup'>
S: <agent jid='bob@example.com' />
@@ -1043,7 +1043,7 @@ S: </iq>
</xs:documentation>
</xs:annotation>
- <xs:import
+ <xs:import
namespace='jabber:x:data'
schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>
diff --git a/xep-0143.xml b/xep-0143.xml
index 433cec2..34a4f73 100644
--- a/xep-0143.xml
+++ b/xep-0143.xml
@@ -180,7 +180,7 @@
</ul>
<p>We repeat: include lots of protocol examples. Examples help not only implementers but also those who will review your proposal in the Standards SIG and XMPP Council. You get extra credit with the XMPP Extensions Editor team if you follow Jabber tradition by using characters and situations from the plays of Shakespeare:</p>
<example caption='An Example from Shakespeare'><![CDATA[
-<message
+<message
from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
type='chat'>
@@ -234,16 +234,16 @@
<p>Examples are the major source of right-scrolling in our HTML output files. Right-scrolling is evil. Therefore, adjust your example layouts accordingly (line widths should be no more than 110 characters or so).</p>
<p>Example:</p>
<code><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
- id='config1'
- to='crone1@shakespeare.lit/desktop'
+<iq from='darkcave@macbeth.shakespeare.lit'
+ id='config1'
+ to='crone1@shakespeare.lit/desktop'
type='result'>
<query xmlns='http://jabber.org/protocol/muc#roomconfig'>
<x xmlns='jabber:x:data' type='form'>
<title>Configuration for "darkcave" Room</title>
<instructions>
- Please complete this form to make changes to the configuration
- of your room; to add room owners and administrators, use the
+ Please complete this form to make changes to the configuration
+ of your room; to add room owners and administrators, use the
appropriate room commands rather than this form.
</instructions>
<field type='hidden' var='FORM_TYPE'>
diff --git a/xep-0144.xml b/xep-0144.xml
index 70f8217..5c9c609 100644
--- a/xep-0144.xml
+++ b/xep-0144.xml
@@ -107,7 +107,7 @@
<example caption='Suggesting Addition'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
<body>Some visitors, m'lord!</body>
- <x xmlns='http://jabber.org/protocol/rosterx'>
+ <x xmlns='http://jabber.org/protocol/rosterx'>
<item action='add'
jid='rosencrantz@denmark.lit'
name='Rosencrantz'>
@@ -134,16 +134,16 @@
<p>In order to programatically suggest that the receiving entity should delete one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more &lt;item/&gt; child elements, each of which MUST possess an 'action' attribute whose value is "delete", MUST possess a 'jid' attribute that specifies the JabberID of the item to be deleted, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more &lt;group/&gt; elements specifying roster groups for the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:</p>
<example caption='Suggesting Deletion'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
- <x xmlns='http://jabber.org/protocol/rosterx'>
+ <x xmlns='http://jabber.org/protocol/rosterx'>
<item action='delete'
jid='rosencrantz@denmark'
- name='Rosencrantz'>
- <group>Visitors</group>
- </item>
- <item action='delete'
- jid='guildenstern@denmark'
- name='Guildenstern'>
- <group>Visitors</group>
+ name='Rosencrantz'>
+ <group>Visitors</group>
+ </item>
+ <item action='delete'
+ jid='guildenstern@denmark'
+ name='Guildenstern'>
+ <group>Visitors</group>
</item>
</x>
</message>
@@ -160,7 +160,7 @@
<p>In order to programatically suggest that the receiving entity should modify one or more items from its roster, the sending entity MUST send a &MESSAGE; or &IQ; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/rosterx' namespace; the &X; element in turn MUST contain one or more &lt;item/&gt; child elements, each of which MUST possess an 'action' attribute whose value is "modify", MUST possess a 'jid' attribute that specifies the JabberID of the item to be modified, MAY possess a 'name' attribute that specifies a natural-language name or nickname for the item, and MAY contain one or more &lt;group/&gt; elements specifying roster groups into which to place the item. If a &MESSAGE; stanza is sent, it MAY contain a &BODY; element but SHOULD NOT contain any other child elements. Here is an example:</p>
<example caption='Suggesting Modification'><![CDATA[
<message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
- <x xmlns='http://jabber.org/protocol/rosterx'>
+ <x xmlns='http://jabber.org/protocol/rosterx'>
<item action='modify'
jid='rosencrantz@denmark.lit'
name='Rosencrantz'>
@@ -244,7 +244,7 @@
<p>There is a third category of entities that might initiate roster item exchanges, which we label a "group service" and identify by a <cite>Service Discovery</cite> category of "directory" and type of "group". A group service enables an administrator to centrally define and administer roster groups so that they can be shared among a user population in an organized fashion. Such a service could prove useful in enterprise environments
<note>For example, when Alice is hired by the marketing department of Big Company Enterprises, it makes sense for her to automatically have the other members of the marketing department in her roster the first time she logs in, and for the rest of the marketing department to have Alice in their rosters as soon as her account has been set up. Similarly, when Bob in logistics gets fired, it makes sense for him to disappear from the rosters of everyone else in the logistics department.</note>
and other settings where it is beneficial to synchronize rosters across individuals (e.g., schools, social networking applications, consumer IM services, and anywhere else that it is important to build and manage small communities of users).</p>
- <p>In some contexts, an IM server could function as a group service (e.g., if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (e.g., in a larger or more heterogeneous environment with users on multiple servers). In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via &xep0077; or out of band, e.g., via the web) or be otherwise provisioned to use the service (e.g., by a system administrator) before accepting roster item suggestions from the service.</p>
+ <p>In some contexts, an IM server could function as a group service (e.g., if there is a single server deployed on a small company intranet); in other contexts, it may make more sense to deploy a standalone group service (e.g., in a larger or more heterogeneous environment with users on multiple servers). In both cases, the group service MUST advertise a service discovery identity of "directory/group" and SHOULD use the protocol specified herein to communicate changes ("add", "delete", and "modify") to the relevant shared groups; in addition, a user MUST first register with the service (either over Jabber via &xep0077; or out of band, e.g., via the web) or be otherwise provisioned to use the service (e.g., by a system administrator) before accepting roster item suggestions from the service.</p>
<p>If the user has registered with a group service or been otherwise provisioned to use a group service, the receiving application SHOULD process roster item suggestions received from the service. Such processing MAY occur automatically (i.e., without the user's approval of each roster item or batch of roster items) if and only if the receiving application has explicitly informed the user that it will automatically process roster items from the service. Furthermore, the receiving application SHOULD periodically verify automatic processing with the user (e.g., once per session in which the service sends roster item suggestions to the user).</p>
</section2>
</section1>
diff --git a/xep-0145.xml b/xep-0145.xml
index 4739179..2d8da41 100644
--- a/xep-0145.xml
+++ b/xep-0145.xml
@@ -64,7 +64,7 @@
</section1>
<section1 topic='The storage:rosternotes Namespace' anchor='ns_storage_notes'>
-
+
<p>Annotations are stored using server-side private XML storage (the 'jabber:iq:private' namespace). A storage element marked by the storage:rosternotes namespace contains a collection of one or more &lt;note/&gt; elements, each representing a note about a given entity. For any given JID there MUST NOT be more than one note.</p>
<p>The 'jid' attribute of the &lt;note/&gt; element SHOULD be used without a resource. Along with the annotation a client MAY choose to store creation time ('cdate') and modification time ('mdate') as attributes to the &lt;note/&gt; element containing the note; these attributes MUST conform to the DateTime profile specified in &xep0082; and the timezone SHOULD be UTC.</p>
diff --git a/xep-0146.xml b/xep-0146.xml
index d1b6f8f..d5187b5 100644
--- a/xep-0146.xml
+++ b/xep-0146.xml
@@ -33,7 +33,7 @@
<version>0.3</version>
<date>2006-01-25</date>
<initials>rt</initials>
- <remark>Using XEP-0033 (Extended Stanza Addressing) for Forwarding
+ <remark>Using XEP-0033 (Extended Stanza Addressing) for Forwarding
use case.</remark>
</revision>
<revision>
@@ -52,14 +52,14 @@
<section1 topic='Introduction' anchor='intro'>
<p>
- When one has multiple clients at different locations logged in
- simultaneously, it is often desirable to control these clients from
+ When one has multiple clients at different locations logged in
+ simultaneously, it is often desirable to control these clients from
the client you are currently using. There are a number of common tasks
one might want to perform remotely on clients: change the status of the
client, forward all received unread messages to this client, and so on.
Therefore, it makes sense to define a protocol for performing these tasks.
</p>
-
+
<p>
This document describes a protocol to perform a set of common tasks on a
remote client, by specifying a profile of &xep0050;.
@@ -70,7 +70,7 @@
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p>
<ul>
- <li>Enable users to perform a set of common tasks on a remote
+ <li>Enable users to perform a set of common tasks on a remote
client.</li>
<li>Re-use existing XMPP and Jabber protocols wherever possible.</li>
</ul>
@@ -78,7 +78,7 @@
<section1 topic='Discovery' anchor='disco'>
- <p>A client MUST advertise any remote controlling commands it supports via
+ <p>A client MUST advertise any remote controlling commands it supports via
&xep0030; (as described in <strong>XEP-0050: Ad-Hoc Commands</strong>).
&xep0115; can be used to query capability of remote controlling commands
in a client.
@@ -107,8 +107,8 @@
<section2 topic='Change Status' anchor='set-status'>
<p>It is common to forget changing the status of a resource when leaving the
- client for a longer period. When realizing this while at another location, it
- might be desirable to change the status from there, to avoid contacts
+ client for a longer period. When realizing this while at another location, it
+ might be desirable to change the status from there, to avoid contacts
thinking that resource is attended and sending it messages.</p>
<example caption='Local Client Requests to Set the Status of a Remote Client'><![CDATA[
<iq from='juliet@example.com/chamber'
@@ -116,19 +116,19 @@
type='set'
id='set-status-1'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#set-status'/>
</iq>
]]></example>
- <p>Unless an error occurs (see the
- <link url='#errors'>Error Handling</link> section below), the service
+ <p>Unless an error occurs (see the
+ <link url='#errors'>Error Handling</link> section below), the service
SHOULD return the appropriate form.</p>
-
+
<example caption='Remote Client Replies with a Form to Set its Status'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='set-status-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -141,40 +141,40 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
- <field label='Status'
- type='list-single'
+ <field label='Status'
+ type='list-single'
var='status'>
<required/>
<value>online</value>
- <option label='Chat'>
+ <option label='Chat'>
<value>chat</value>
</option>
- <option label='Online'>
+ <option label='Online'>
<value>online</value>
</option>
- <option label='Away'>
+ <option label='Away'>
<value>away</value>
</option>
- <option label='Extended Away'>
+ <option label='Extended Away'>
<value>xa</value>
</option>
- <option label='Do Not Disturb'>
+ <option label='Do Not Disturb'>
<value>dnd</value>
</option>
- <option label='Invisible'>
+ <option label='Invisible'>
<value>invisible</value>
</option>
- <option label='Offline'>
+ <option label='Offline'>
<value>offline</value>
</option>
</field>
<field label='Priority'
type='text-single'
var='status-priority'>
- <value>5</value>
+ <value>5</value>
</field>
- <field label='Message'
- type='text-multi'
+ <field label='Message'
+ type='text-multi'
var='status-message'/>
</x>
</command>
@@ -186,7 +186,7 @@
type='set'
id='set-status-2'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-status'
sessionid='set-status:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@@ -209,9 +209,9 @@
<p>If the 'status-priority' variable is omitted, the client SHOULD NOT
change the priority of the client</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='set-status-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -220,7 +220,7 @@
status='completed'/>
</iq>
]]></example>
- <p>Notification of completion MAY include the processed data in a data
+ <p>Notification of completion MAY include the processed data in a data
form of type 'result'.</p>
</section2>
@@ -254,7 +254,7 @@
type='set'
id='forward-1'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#forward'
sessionid='forward:20040727T0337Z'/>
@@ -267,7 +267,7 @@
the command was completed.
</p>
<example caption='Remote Client Forwards All Unread Messages to Local Client'><![CDATA[
-<message from='juliet@example.com/balcony'
+<message from='juliet@example.com/balcony'
to='juliet@example.com/chamber'>
<subject>Just saying hi</subject>
<body>Hello Juliet!</body>
@@ -279,9 +279,9 @@
stamp='2002-09-10T23:41:07Z'/>
</message>]]></example>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='forward-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -310,7 +310,7 @@
type='set'
id='set-options-1'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#set-options'/>
</iq>]]></example>
@@ -340,23 +340,23 @@
var='sounds'>
<value>1</value>
</field>
- <field label='Automatically Go Offline when Idle'
- type='boolean'
+ <field label='Automatically Go Offline when Idle'
+ type='boolean'
var='auto-offline'>
<value>0</value>
</field>
- <field label='Automatically Open New Messages'
- type='boolean'
+ <field label='Automatically Open New Messages'
+ type='boolean'
var='auto-msg'>
<value>0</value>
</field>
- <field label='Automatically Accept File Transfers'
- type='boolean'
+ <field label='Automatically Accept File Transfers'
+ type='boolean'
var='auto-files'>
<value>0</value>
</field>
- <field label='Automatically Authorize Contacts'
- type='boolean'
+ <field label='Automatically Authorize Contacts'
+ type='boolean'
var='auto-auth'>
<value>0</value>
</field>
@@ -369,7 +369,7 @@
type='set'
id='set-options-2'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#set-options'
sessionid='set-options:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@@ -425,7 +425,7 @@
type='set'
id='accept-files-1'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#accept-files'/>
</iq>]]></example>
@@ -450,17 +450,17 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
- <field label='Files'
- type='list-multi'
+ <field label='Files'
+ type='list-multi'
var='files'>
<required/>
- <option label='ballad.ogg (romeo@example.com)'>
+ <option label='ballad.ogg (romeo@example.com)'>
<value>romeo@example.com/orchard:1</value>
</option>
- <option label='picture.jpg (romeo@example.com)'>
+ <option label='picture.jpg (romeo@example.com)'>
<value>romeo@example.com/orchard:2</value>
</option>
- <option label='challenge.txt (mercutio@example.com)'>
+ <option label='challenge.txt (mercutio@example.com)'>
<value>mercutio@example.com/orchard:1</value>
</option>
</field>
@@ -473,7 +473,7 @@
type='set'
id='accept-files-2'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#accept-files'
sessionid='accept-files:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@@ -491,9 +491,9 @@
local client of completion.
</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='accept-files-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -512,15 +512,15 @@
type='set'
id='leave-groupchats-1'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
action='execute'
node='http://jabber.org/protocol/rc#leave-groupchats'/>
</iq>
]]></example>
<example caption='Remote Client Replies with a Form with a List of Groupchats it is currently in'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='leave-groupchats-1'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -533,17 +533,17 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/rc</value>
</field>
- <field label='Groupchats'
- type='list-multi'
+ <field label='Groupchats'
+ type='list-multi'
var='groupchats'>
<required/>
- <option label='juliet on jdev@conference.jabber.org'>
+ <option label='juliet on jdev@conference.jabber.org'>
<value>jdev@conference.jabber.org/juliet</value>
</option>
- <option label='juliette on jdev@conference.jabber.org'>
+ <option label='juliette on jdev@conference.jabber.org'>
<value>jdev@conference.jabber.org/juliette</value>
</option>
- <option label='juliet on girlsonly@jabber.com'>
+ <option label='juliet on girlsonly@jabber.com'>
<value>girlsonly@jabber.com/juliet</value>
</option>
</field>
@@ -557,7 +557,7 @@
type='set'
id='leave-groupchats-2'
xml:lang='en'>
- <command xmlns='http://jabber.org/protocol/commands'
+ <command xmlns='http://jabber.org/protocol/commands'
node='http://jabber.org/protocol/rc#leave-groupchats'
sessionid='leave-groupchats:20040727T0337Z'>
<x xmlns='jabber:x:data' type='form'>
@@ -575,9 +575,9 @@
<p>The remote client leaves the requested groupchats, and informs the
local client of completion.</p>
<example caption='Remote Client Informs Local Client of Completion'><![CDATA[
-<iq from='juliet@example.com/balcony'
- to='juliet@example.com/chamber'
- type='result'
+<iq from='juliet@example.com/balcony'
+ to='juliet@example.com/chamber'
+ type='result'
id='leave-groupchats-2'
xml:lang='en'>
<command xmlns='http://jabber.org/protocol/commands'
@@ -589,8 +589,8 @@
</section2>
</section1>
-
-<section1 topic='Error Handling' anchor='errors'>
+
+<section1 topic='Error Handling' anchor='errors'>
<p>Several error conditions are possible when an entity sends a command
request to the service, as defined in the following table. If one of these
errors occurs, the service MUST return an error stanza to the requesting
@@ -613,7 +613,7 @@
</tr>
<tr>
<td>&forbidden;</td>
- <td>The requesting entity does not have sufficient privileges to
+ <td>The requesting entity does not have sufficient privileges to
perform the command</td>
</tr>
<tr>
@@ -621,32 +621,32 @@
<td>The ad-hoc commands protocol is not supported</td>
</tr>
</table>
-
+
<p>For the syntax of these errors, see &xep0086;. Naturally, other errors
may be returned as well.</p>
</section1>
-<section1 topic='Implementation Notes' anchor='implementation'>
+<section1 topic='Implementation Notes' anchor='implementation'>
<p>Implementations of this protocol MAY add or remove fields to forms as
they see fit. For example, when setting the status of a remote client that
- supports multiple accounts, the client may choose to add a boolean field
+ supports multiple accounts, the client may choose to add a boolean field
to allow the user to specify whether the status change should be applied
globally or only to the receiving account.</p>
<p> Implementations MAY also introduce extra forms for commands. For example,
- when forwarding unread messages, a client could return a form containing a
- list
+ when forwarding unread messages, a client could return a form containing a
+ list
of short descriptions of unread messages, allowing the user to select the
messages he wants to forward.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The ability to complete the tasks specified herein MUST NOT be granted
- to users who lack privileges to control a client. A sensible
- access policy is to only allow remote controlling by other
+ to users who lack privileges to control a client. A sensible
+ access policy is to only allow remote controlling by other
resources of the same account used by the client. If other accounts
- are to be able to remote control the client, the client needs more
+ are to be able to remote control the client, the client needs more
complex access right management.</p>
</section1>
@@ -657,7 +657,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
-
+
<section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
<p>The XMPP Registrar includes 'http://jabber.org/protocol/rc' in its registry
of protocol namespaces (see &NAMESPACES;).</p>
@@ -665,8 +665,8 @@
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&xep0068; defines a process for standardizing the fields used within
- Data Forms scoped by a particular namespace (see also &FORMTYPES;).
- The reserved fields for the 'http://jabber.org/protocol/rc' namespace
+ Data Forms scoped by a particular namespace (see also &FORMTYPES;).
+ The reserved fields for the 'http://jabber.org/protocol/rc' namespace
are specified below.</p>
<code caption='Registry Submission'><![CDATA[
<form_type>
@@ -697,25 +697,25 @@
<field var='status'
type='list-single'
label='A presence or availability status'>
- <option label='Chat'>
+ <option label='Chat'>
<value>chat</value>
</option>
- <option label='Online'>
+ <option label='Online'>
<value>online</value>
</option>
- <option label='Away'>
+ <option label='Away'>
<value>away</value>
</option>
- <option label='Extended Away'>
+ <option label='Extended Away'>
<value>xa</value>
</option>
- <option label='Do Not Disturb'>
+ <option label='Do Not Disturb'>
<value>dnd</value>
</option>
- <option label='Invisible'>
+ <option label='Invisible'>
<value>invisible</value>
</option>
- <option label='Offline'>
+ <option label='Offline'>
<value>offline</value>
</option>
</field>
diff --git a/xep-0147.xml b/xep-0147.xml
index 1ee5a2f..b594db8 100644
--- a/xep-0147.xml
+++ b/xep-0147.xml
@@ -102,7 +102,7 @@
</section1>
<section1 topic='Query Actions' anchor='actions'>
<p>The range of actions that might be triggered by interaction with an XMPP entity by means of an XMPP IRI/URI is potentially as wide as the range of extensions to XMPP. This document does not seek to exhaustively define all such potential actions. However, the following actions might be of general interest:</p>
- <ol>
+ <ol>
<li>Sending a message.</li>
<li>Adding or removing a roster item.</li>
<li>Subscribing to or unsubscribing from an entity's presence information.</li>
@@ -113,7 +113,7 @@
<li>Subscribing to or unsubscribing from a &xep0060; node.</li>
<li>Registering with another entity via &xep0077;.</li>
<li>Initiating a file transfer with another entity (see &xep0096;).</li>
- </ol>
+ </ol>
<p>For each such action, the XMPP Registrar maintains a RECOMMENDED "querytype" (this can be thought of as an action name or "verb"; see <cite>RFC 5122</cite> for syntax and semantics) as well as an OPTIONAL list of keys to be used in key-value pairs if appropriate.</p>
<p>The querytypes and key-value pairs related to <cite>RFC 3920</cite> and <cite>RFC 3921</cite> are defined herein; the querytypes and key-value pairs related to protocols defined in the XMPP Standards Foundation's XEP series are defined in the relevant XMPP Extension Protocol specifications.</p>
<section2 topic='Message Action' anchor='actions-message'>
@@ -244,7 +244,7 @@ xmpp:romeo@montague.net?unsubscribe
<querytype>
<name>the name of the querytype (e.g., "pubsub")</name>
<proto>
- the namespace of associated protocol output
+ the namespace of associated protocol output
(e.g., "http://jabber.org/protocol/pubsub")
</proto>
<desc>a natural-language description of the querytype</desc>
diff --git a/xep-0148.xml b/xep-0148.xml
index 0394f4b..32ee9d0 100644
--- a/xep-0148.xml
+++ b/xep-0148.xml
@@ -120,8 +120,8 @@
id='hint1'>
<query xmlns='jabber:iq:iq'>
<hint>
- I&apos;ve heard that there&apos;s this thing called the Internet, which
- contains incredible amounts of helpful information. Have you considered
+ I&apos;ve heard that there&apos;s this thing called the Internet, which
+ contains incredible amounts of helpful information. Have you considered
using it?
</hint>
</query>
@@ -175,7 +175,7 @@
<td>idiot</td>
</tr>
</table>
- <p>While once common, these terms are now considered politically incorrect. However, please note that this specification merely provides informational documentation of a protocol historically used within the Jabber community, and is not intended to stereotype individuals in any manner whatsoever. A given server implementation of the 'jabber:iq:iq' protocol MAY substitute more modern ranges and terminology if desired or leave out the descriptive phrases entirely, and a given client implementation MAY rename or disguise the descriptive phrases.</p>
+ <p>While once common, these terms are now considered politically incorrect. However, please note that this specification merely provides informational documentation of a protocol historically used within the Jabber community, and is not intended to stereotype individuals in any manner whatsoever. A given server implementation of the 'jabber:iq:iq' protocol MAY substitute more modern ranges and terminology if desired or leave out the descriptive phrases entirely, and a given client implementation MAY rename or disguise the descriptive phrases.</p>
<p>That said, it is true that many people on the Jabber network do act like morons, imbeciles, and even idiots.</p>
</section2>
<section2 topic='Determination of IM IQ' anchor='impl-determination'>
@@ -201,7 +201,7 @@
<p>Most people become somewhat insecure when they realize that in fact they are not as smart as they thought they were; for this reason, querying the server for one's own IM IQ is NOT RECOMMENDED on a regular basis.</p>
</section1>
<section1 topic='IANA Considerations'>
- <p>This document requires no interaction with &IANA;.</p>
+ <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; shall include the 'jabber:iq:iq' namespace in its registry of protocol namespaces.</p>
diff --git a/xep-0149.xml b/xep-0149.xml
index 40b320c..bda160d 100644
--- a/xep-0149.xml
+++ b/xep-0149.xml
@@ -91,9 +91,9 @@
<section2 topic='User Activity' anchor='activity'>
<p>An XMPP extension for user activity is specified in <cite>XEP-0108</cite>. It may be desirable to include time period information when publishing one's activity.</p>
<example caption='User Activity With Time Period'><![CDATA[
-<iq type='set'
- from='juliet@capulet.com/balcony'
- to='pubsub.shakespeare.lit'
+<iq type='set'
+ from='juliet@capulet.com/balcony'
+ to='pubsub.shakespeare.lit'
id='activity1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='generic/juliet-activity'>
@@ -117,9 +117,9 @@
<section2 topic='User Mood' anchor='mood'>
<p>An XMPP extension for user mood is specified in <cite>XEP-0107</cite>. It may be desirable to include time period information when publishing one's mood.</p>
<example caption='User Mood With Time Period'><![CDATA[
-<iq type='set'
- from='juliet@capulet.com/balcony'
- to='pubsub.shakespeare.lit'
+<iq type='set'
+ from='juliet@capulet.com/balcony'
+ to='pubsub.shakespeare.lit'
id='mood1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='generic/juliet-mood'>
diff --git a/xep-0150.xml b/xep-0150.xml
index f1bdc31..4feda4d 100644
--- a/xep-0150.xml
+++ b/xep-0150.xml
@@ -59,14 +59,14 @@
<p>The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); this is made possible by a straightforward application of SHIM headers as specified in <cite>XEP-0131</cite>. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data object can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object has not changed.</p>
<p>Here is an example of such a request-response flow (the example is that of roster retrieval):</p>
<example caption='Client Requests Roster'><![CDATA[
-<iq type='get'
+<iq type='get'
from='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
]]></example>
<example caption='Server Returns Roster Including ETag Header'><![CDATA[
-<iq type='result'
+<iq type='result'
to='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'>
@@ -83,7 +83,7 @@
</iq>
]]></example>
<example caption='Client Requests Roster Including If-None-Match Header'><![CDATA[
-<iq type='get'
+<iq type='get'
from='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
@@ -96,7 +96,7 @@
<p>If the responding entity does not understand the If-None-Match header or does not handle Entity Tags for the namespace in the request, it MUST ignore the header and return whatever information it would have returned if the header had not been present.</p>
<p>If the responding entity determines that the requested information has not changed since it was last retrieved by the requesting entity, then it MUST return a &lt;not-modified/&gt; error corresponding to the HTTP 304 error returned by HTTP entities that support the ETag header:</p>
<example caption='Responding Entity Returns Not Modified Error'><![CDATA[
-<iq type='error'
+<iq type='error'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
@@ -118,7 +118,7 @@
<p>As specified in &xmppim;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since <cite>RFC 6121</cite> defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.</p>
<p>First, the client requests its roster:</p>
<example caption='Client Requests Roster'><![CDATA[
-<iq type='get'
+<iq type='get'
from='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
@@ -126,7 +126,7 @@
]]></example>
<p>If the server supports Entity Tag functionality for rosters, it SHOULD include an ETag SHIM header in its response (although it MAY decide not to include the header if the roster is deemed to be not worth caching because it is so small):</p>
<example caption='Server Returns Roster Including ETag Header'><![CDATA[
-<iq type='result'
+<iq type='result'
to='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'>
@@ -144,7 +144,7 @@
]]></example>
<p>The client would then cache that roster and associate the included Entity Tag with that cached copy. In order to subsequently retrieve the roster, the client would include the last known Entity Tag value with the request in an If-None-Match SHIM header:</p>
<example caption='Client Requests Roster, Including If-None-Match Header'><![CDATA[
-<iq type='get'
+<iq type='get'
from='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
@@ -156,7 +156,7 @@
]]></example>
<p>If the roster did not change since the client last retrieved the roster and the server supports Entity Tags for the 'jabber:iq:roster' namespace, the server MUST return a &lt;not-modified/&gt; error:</p>
<example caption='Server Returns Not Modified Error'><![CDATA[
-<iq type='error'
+<iq type='error'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
@@ -171,7 +171,7 @@
]]></example>
<p>If the roster has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the roster as if the If-None-Match header was not included:</p>
<example caption='Server Returns Roster'><![CDATA[
-<iq type='result'
+<iq type='result'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
@@ -192,8 +192,8 @@
<p>The payloads exchanged in the &xep0016; protocol can also be quite large. Therefore a server might want to support Entity Tags in the context of privacy list management. The process is as follows.</p>
<p>First, a client requests its privacy lists:</p>
<example caption='Client Requests Privacy List'><![CDATA[
-<iq type='get'
- from='romeo@montague.net/orchard'
+<iq type='get'
+ from='romeo@montague.net/orchard'
id='getlist1'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
@@ -202,7 +202,7 @@
]]></example>
<p>The server returns the list and includes an Entity Tag in an ETag SHIM header.</p>
<example caption='Server Returns Privacy List Including ETag Header'><![CDATA[
-<iq type='result'
+<iq type='result'
to='romeo@example.net/orchard'
id='getlist1'>
<query xmlns='jabber:iq:privacy'>
@@ -229,8 +229,8 @@
]]></example>
<p>Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:</p>
<example caption='Client Requests Privacy List Including If-None-Match Header'><![CDATA[
-<iq type='get'
- from='romeo@montague.net/orchard'
+<iq type='get'
+ from='romeo@montague.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
@@ -242,7 +242,7 @@
]]></example>
<p>If the privacy list did not change since the client last retrieved it and the server supports Entity Tags for the 'jabber:iq:privacy' namespace, the server MUST return a &lt;not-modified/&gt; error:</p>
<example caption='Server Returns Not Modified Error'><![CDATA[
-<iq type='error'
+<iq type='error'
to='romeo@example.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
@@ -258,7 +258,7 @@
]]></example>
<p>If the privacy list has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the privacy list as if the If-None-Match header was not included:</p>
<example caption='Server Returns Privacy List'><![CDATA[
-<iq type='result'
+<iq type='result'
to='romeo@example.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
diff --git a/xep-0151.xml b/xep-0151.xml
index 3422c18..5857c72 100644
--- a/xep-0151.xml
+++ b/xep-0151.xml
@@ -50,7 +50,7 @@
<version>0.0.7</version>
<date>2005-02-08</date>
<initials>hw</initials>
- <remark><p>Added comments on anonymity of presence element JID.
+ <remark><p>Added comments on anonymity of presence element JID.
Added additional avatar retrieval methods: 1. presence stanza avatar data element 2. via disco</p></remark>
</revision>
<revision>
@@ -93,9 +93,9 @@
<section1 topic='Introduction'>
<p>Virtual presence on Web pages (also sometimes known as co-browsing, while co-browsing can also mean something different) makes people aware of each other, who are at the same Web location at the same time. The basic purpose of a virtual presence system is to show names, icons, and/or avatars of people who are on a page or a set of pages and to let them communicate. This document proposes extensions to the Jabber protocol, which enable neat virtual presence on Web pages. The extensions are implemented as namespaces for the protocol elements &IQ;, &PRESENCE;, &MESSAGE;, and for server storage. </p>
-
- <p>This document also covers the mapping of URLs to Jabber chat rooms. It describes step by step how clients derive virtual locations from URLs of web pages. The process includes queries to the web server, queries to default configuration sources, delegation between configuration sets, ways for administrators of websites to opt out, and methods to shape the virtual space actively by clustering together or splitting off URL groups.</p>
-
+
+ <p>This document also covers the mapping of URLs to Jabber chat rooms. It describes step by step how clients derive virtual locations from URLs of web pages. The process includes queries to the web server, queries to default configuration sources, delegation between configuration sets, ways for administrators of websites to opt out, and methods to shape the virtual space actively by clustering together or splitting off URL groups.</p>
+
<p>This document describes an implementation that proved to be useful over one year. We propose the extensions, but we are open to comments and other proposals, if readers think that different approaches would better fit into the Jabber architecture. This also applies to namespaces, especially since the extensions where designed while the Jabber community was moving to URL-style namespaces. So did this implementation.</p>
</section1>
@@ -122,7 +122,7 @@
<p>The traffic goals can be met by using only the initial &PRESENCE; stanza, which carries all required information, so that no peer-to-peer messages are required on entering. VP clients which gather additional information about peers (e.g. avatar images) should cache the data so that it can be re-used. This is especially important since users browsing virtually connected locations (i.e. linked pages) may meet very often in a short time.</p>
- <p>The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &xep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.</p>
+ <p>The virtual presence extensions make use of Jabber group chat. Virtual locations are implemented as public Jabber chat channels. The proposed protocol works with &xep0045; rooms and GroupChat 1.0 compatible services. Its core functionality described here uses only groupchat features.</p>
<p>The virtual presence extensions are supposed to be implemented by Jabber IM clients in addition to the IM functions or by pure virtual presence (Jabber VP) clients.</p>
@@ -175,7 +175,7 @@
<section1 topic='Example of a Virtual Meeting'>
- <p>Since it has been suggested that the use of Shakespeare characters might please the reader we will try to employ them without really knowing the works of Shakespeare. Two characters called Romeo and Juliet will appear. Both will be equipped with a Web browser and a virtual presence Jabber client which implements the protocol extensions described in this document (called VP client in the following). The communication is shown as seen by the conference component including &apos;from&apos; attributes.</p>
+ <p>Since it has been suggested that the use of Shakespeare characters might please the reader we will try to employ them without really knowing the works of Shakespeare. Two characters called Romeo and Juliet will appear. Both will be equipped with a Web browser and a virtual presence Jabber client which implements the protocol extensions described in this document (called VP client in the following). The communication is shown as seen by the conference component including &apos;from&apos; attributes.</p>
<section2 topic='Meeting on Virtual Locations'>
<p>This shows how the first meeting of Romeo and Juliet would have happened if they had known Cyberspace, i.e. the Web. Romeo browses the Web with his favorite web client. He reads the page http://www.shakespeare.com/market/ModernLibrary/page1.html. He is also running a VP client. There is no mention of a buddy list jabber client at this point. The VP client is properly logged in to the Jabber server using the JID romeo@montague.net. Through some magic, the VP client acquires the URL of the current web page. The VP client converts the URL into the JID of a public chat room (see section &apos;Virtual Locations&apos;). The JID will usually be a SHA1 digest of the URL prefixed to a conference component (like f4eb29410ec339144633773dda1dc4a643513933@shakespeare.com). For the sake of readability we will refer to the chat room as room1@shakespeare.com. The VP client then enters the room using &apos;YoungHero&apos; as the nickname.</p>
@@ -188,16 +188,16 @@
<presence from='room1@shakespeare.com/YoungHero' to='romeo@montague.net/garden' />]]>
</example>
- <p>Upon reception the VP client visualizes the presence of Romeo at the location to Romeo, e.g. by displaying Romeo&apos;s icon and/or nickname on, at, or close to the web page. In other words: the VP client shows an avatar of Romeo on the page.</p>
+ <p>Upon reception the VP client visualizes the presence of Romeo at the location to Romeo, e.g. by displaying Romeo&apos;s icon and/or nickname on, at, or close to the web page. In other words: the VP client shows an avatar of Romeo on the page.</p>
- <p>Dramatic increases when Juliet browses to the same web page. Her VP client also gathers the URL, performs the same mapping and enters the room. It sends a &PRESENCE; stanza to the room using nickname &apos;WebGirl&apos;. The room as expected returns the acknowledgement. In addition the room forwards both &PRESENCE; stanzas to the VP clients in order to announce the mutual presence. </p>
+ <p>Dramatic increases when Juliet browses to the same web page. Her VP client also gathers the URL, performs the same mapping and enters the room. It sends a &PRESENCE; stanza to the room using nickname &apos;WebGirl&apos;. The room as expected returns the acknowledgement. In addition the room forwards both &PRESENCE; stanzas to the VP clients in order to announce the mutual presence. </p>
<p>Romeo gets:</p>
<example caption='Announcement of peer presence'><![CDATA[
<presence from='room1@shakespeare.com/WebGirl' to='romeo@montague.net/garden' />]]>
</example>
- <p>Juliet gets the equivalent. Romeo&apos;s VP client shows Juliet&apos;s presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask &quot;Who art thou, Romeo?&quot;, because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (XEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room&apos;s JID.</p>
+ <p>Juliet gets the equivalent. Romeo&apos;s VP client shows Juliet&apos;s presence by adding a second avatar to the page. They now engage in a vivid conversation. In deviation to the original text Juliet would not ask &quot;Who art thou, Romeo?&quot;, because she only knows the nickname and on the other hand she actually knows where Romeo is: he is on the same web page. There is nothing new until now. Everything happened according to GroupChat 1.0 (XEP-0045) without MUC features. Of course, users can join the same room with any client that supports GroupChat, if they know the room&apos;s JID.</p>
<p>Extensions come into the play in order to make the virtual presence more attractive and more vivid.</p>
</section2>
@@ -208,7 +208,7 @@
<p>Entering the room Juliet would add a JID-element to the initial &PRESENCE; stanza.</p>
<example caption='Disclosing the JID'><![CDATA[
-<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
+<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
<x xmlns='firebat:user:jid'>juliet@capulet.com/balcony</x>
</presence>]]>
</example>
@@ -231,7 +231,7 @@
<p>Romeo will be much more interested in Juliet if Juliet is depicted by a nice image rather than only a name. Users may choose avatars, publish those avatars, and change them on the fly. Changes to the avatar are tracked by comparing a stored digest of the avatar data to the received digest. The avatar digest will be received as part of the &PRESENCE; stanza. Juliet also includes an avatar-digest element with a hex-coded SHA1-digest of the avatar data (i.e. the digest of the image file): </p>
<example caption='Avatar Digest'><![CDATA[
-<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
+<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
<x xmlns='firebat:user:jid'>juliet@capulet.com/balcony</x>
<x xmlns='firebat:avatar:digest'>9b3635eb1440a1ee1c9f67767651194f34ecf130</x>
</presence>]]>
@@ -325,7 +325,7 @@
<x xmlns='firebat:avatar:data'><data src='http://www.capulet.com/juliet.png'/></x>
as part of:
-<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
+<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
<x xmlns='firebat:avatar:digest'>9b3635eb1440a1ee1c9f67767651194f34ecf130</x>
<x xmlns='firebat:avatar:data'><data src='http://www.capulet.com/juliet.png'/></x>
</presence>]]>
@@ -363,7 +363,7 @@ as part of:
<p>A web page can be regarded as a two dimensional space. Avatars can move around on the page. Users are not just at a page, they are at a certain coordinate of the page. Entering the room Juliet tells Romeo (and all other participants) her initial position by including a position element into the initial &PRESENCE; stanza:</p>
<example caption='Avatar Position'><![CDATA[
-<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
+<presence from='juliet@capulet.com/balcony' to='room1@shakespeare.com/WebGirl'
<x xmlns='firebat:user:jid'>juliet@capulet.com/balcony</x>
<x xmlns='firebat:avatar:digest'>9b3635eb1440a1ee1c9f67767651194f34ecf130</x>
<x xmlns='firebat:avatar:position'><position x='180' w='853'/></x>
@@ -375,7 +375,7 @@ as part of:
<p>As soon as Juliet enters and her avatar appears, Romeo moves his avatar up to Juliet&apos;s. Romeo&apos;s VP client sends a new &PRESENCE; stanza with an altered position. The message is automatically broadcast by the room to all participants and stored for new participants. Romeo approaches Juliet:</p>
<example caption='Move Avatar'><![CDATA[
-<presence from='romeo@montague.net/garden' to='room1@shakespeare.com/YoungHero'
+<presence from='romeo@montague.net/garden' to='room1@shakespeare.com/YoungHero'
<x xmlns='firebat:user:jid'>romeo@montague.net</x>
<x xmlns='firebat:avatar:digest'>e5229ec136892e00fcb79f822c192e7a2067a296</x>
<x xmlns='firebat:avatar:position'><position x='150'/></x>
@@ -409,7 +409,7 @@ as part of:
</section2>
<section2 topic='Bubble Chat'>
-
+
<p>We remember: after seeing Juliet&apos;s avatar, Romeo has already falling in love. But Juliet is a more realistic type. She insists on talking before falling in love. The avatar-on-web-pages paradigm frees us from chat line based chat. Each avatar may show a separate chat bubble with the latest text or even a chat history. </p>
<p>While Juliet is writing an opening, her VP client may send the current contents of the chat line to the room giving other participants snapshots of the text. We propose instant chat updates as an extension to groupchat. For backward compatibility these snapshots are transmitted as control messages without body text, so that other clients ignore them. Once Juliet hits the send button (or the enter-key) the VP client sends the chat message as body text of a &MESSAGE;. With a timely distance of fractions of seconds to few seconds Juliet sends the following messages:</p>
@@ -440,11 +440,11 @@ as part of:
</section2>
- <section2 topic='Video Icon'>
+ <section2 topic='Video Icon'>
<p>After some chatting, Juliet is still not convinced. She demands to see Romeo live (although not in person). Romeo switches on his webcam and sends the webcam URL as part of the &PRESENCE; stanza.</p>
<example caption='Iconic Video'><![CDATA[
-<presence from='romeo@montague.net/garden' to='room1@shakespeare.com/YoungHero'
+<presence from='romeo@montague.net/garden' to='room1@shakespeare.com/YoungHero'
<x xmlns='firebat:user:jid'>romeo@montague.net</x>
<x xmlns='firebat:avatar:digest'>e5229ec136892e00fcb79f822c192e7a2067a296</x>
<x xmlns='firebat:avatar:position'><position x='150'/></x>
@@ -495,7 +495,7 @@ as part of:
<p>This &lt;name/&gt;-tag produces the room name. The text of the &lt;name/&gt;-tag in combination with the match expression of the &lt;location/&gt; extracts the first level folder of the path section from the URL. It creates a room for each first level folder. The resulting room name is &apos;market-room&apos;. It is hashed by a message digest, if the &lt;digest/&gt; tag is present. A SHA1 digest is used by default. VP clients must support SHA1. The hashed result will be prefixed by &apos;vp-&apos;. Prefixing is provided for convenience, so that rooms generated for virtual presence can be sorted easily in room lists of conference components. Both &lt;digest/&gt; and &lt;prefix/&gt; are optional.</p>
<p>The \1 variable of the match-expression is used to generate a room per sub-folder of the URL. Match-expression variables can be used inside all elements to modify the inner text of the element. You might use the \1 inside the &lt;service/&gt;-tag to point to a different chat server per sub-folder of the URL.</p>
-
+
<p>The rule generates a virtual location ID. This mechanism is extensible to other protocols as virtual presence transport, e.g. IRC. The &lt;service/&gt;-tag contains a service URL, which consists of a scheme and server address. In this case the &apos;xmpp&apos;-scheme means that the Jabber protocol will be used and that the VP client joins a Jabber chat room with a JID created according to the Jabber ID building rules, i.e. room-name@server-address, where the room-name has been derived from the &apos;name&apos;-tag and mangled by the &apos;digest&apos;-tag before it has been prepended to '@server-address'.</p>
<p>A &lt;location/&gt; without match-attribute matches all URLs. In other words: the default match-attribute is '.*'.</p>
@@ -514,7 +514,7 @@ as part of:
... <!-- more locations -->
<location>...</location> <!-- default location -->
</vpi>]]></example>
-
+
<p>Examples were formerly available at http://developer.lluna.de/docs/vpi-file-syntax.html</p>
</section2>
@@ -556,7 +556,7 @@ as part of:
<ignore/>
</location>]]>
</example>
-
+
</section2>
<section2 topic='Web Server based Configuration'>
@@ -579,9 +579,9 @@ http://www.shakespeare.com/_vpi.xml]]>
<code caption='Default VPI'><![CDATA[
<location>
- <name>\1</name>
+ <name>\1</name>
<digest/>
- <service>xmpp:location.virtual-presence.org</service>
+ <service>xmpp:location.virtual-presence.org</service>
</location>]]>
</code>
@@ -595,7 +595,7 @@ http://www.shakespeare.com/_vpi.xml]]>
<example caption='Delegation'><![CDATA[
<location>
- <delegate>http://www.shakespeare.com/_vpi.xml</delegate>
+ <delegate>http://www.shakespeare.com/_vpi.xml</delegate>
</location>]]>
</example>
@@ -604,7 +604,7 @@ http://www.shakespeare.com/_vpi.xml]]>
<example caption='Delegation for Subspaces'><![CDATA[
...
<location match="^http://.*\.com($|/.*)">
- <delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
+ <delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
</location>]]>
...
</example>
@@ -641,12 +641,12 @@ http://www.shakespeare.com/_vpi.xml]]>
<?xml version='1.0' ?>
<vpi xmlns='http://schema.bluehands.de/virtual-presence-info'>
- <!-- handle .com(s) by another file -->
+ <!-- handle .com(s) by another file -->
<location match='^http://.*\.com/.*'>
<delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotcom-vpi.xml</delegate>
</location>
- <!-- handle .de(s) by another file -->
+ <!-- handle .de(s) by another file -->
<location match='^http://.*\.de/.*'>
<delegate>http://vpi.vp.bluehands.de/lluna-2.5.2/dotde-vpi.xml</delegate>
</location>
@@ -718,7 +718,7 @@ http://www.shakespeare.com/_vpi.xml]]>
So, the security mask is (the rule applies only to URLs in the same folder
as the original URL):
</p>
- <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code>
+ <code><![CDATA[^http://www\.shakespeare\.com/market/ModernLibrary/.*]]></code>
<p>
If the security mask applies to a URL can be verified by a simple
string-compare without using a regular expression.
diff --git a/xep-0152.xml b/xep-0152.xml
index 109ab33..5d3a6b4 100644
--- a/xep-0152.xml
+++ b/xep-0152.xml
@@ -223,7 +223,7 @@
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports reachability addresses, it MUST advertise that fact by returning a feature of "urn:xmpp:reach:0" &VNOTE; in response to a &xep0030; information request.</p>
<example caption="Service Discovery Information Request"><![CDATA[
-<iq from='juliet@capulet.com/balcony'
+<iq from='juliet@capulet.com/balcony'
id='disco1'
to='romeo@montague.net/orchard'
type='get'>
@@ -231,9 +231,9 @@
</iq>
]]></example>
<example caption="Service Discovery Information Response"><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
id='disco1'
- to='juliet@capulet.com/balcony'
+ to='juliet@capulet.com/balcony'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:reach:0'/>
@@ -294,7 +294,7 @@
<xs:element name='reach'>
<xs:complexType>
<xs:sequence>
- <xs:element name='addr'
+ <xs:element name='addr'
minOccurs='0'
maxOccurs='unbounded'
type='addrElementType'/>
@@ -304,7 +304,7 @@
<xs:complexType name='addrElementType'>
<xs:sequence>
- <xs:element name='desc'
+ <xs:element name='desc'
minOccurs='0'
maxOccurs='unbounded'
type='xs:string'/>
diff --git a/xep-0153.xml b/xep-0153.xml
index d14249a..e4385de 100644
--- a/xep-0153.xml
+++ b/xep-0153.xml
@@ -85,7 +85,7 @@
<section2 topic='User Publishes Avatar' anchor='publish'>
<p>Before informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in &xep0054;.</p>
<example caption="User&apos;s Client Publishes Avatar Data to vCard"><![CDATA[
-<iq from='juliet@capulet.com'
+<iq from='juliet@capulet.com'
type='set'
id='vc1'>
<vCard xmlns='vcard-temp'>
@@ -123,16 +123,16 @@
<section2 topic='Contact Retrieves Avatar' anchor='retrieve'>
<p>When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. If not, it retrieves the sender's full vCard in accordance with the protocol flow described in <cite>XEP-0054</cite> (note that this request is sent to the user's bare JID, not full JID):</p>
<example caption="Contact&apos;s Client Requests User&apos;s vCard"><![CDATA[
-<iq from='romeo@montague.net/orchard'
+<iq from='romeo@montague.net/orchard'
to='juliet@capulet.com'
- type='get'
+ type='get'
id='vc2'>
<vCard xmlns='vcard-temp'/>
</iq>
]]></example>
<example caption="Server Returns vCard on Behalf of User"><![CDATA[
-<iq from='juliet@capulet.com'
- to='romeo@montague.net/orchard'
+<iq from='juliet@capulet.com'
+ to='romeo@montague.net/orchard'
type='result'
id='vc2'>
<vCard xmlns='vcard-temp'>
diff --git a/xep-0154.xml b/xep-0154.xml
index 6810026..d846429 100644
--- a/xep-0154.xml
+++ b/xep-0154.xml
@@ -118,9 +118,9 @@
<p>This document addresses the following requirements for data representation:</p>
<ol>
<li>Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.</li>
- <li>Ensure that the protocol is extensible (e.g., not limited to existing vCard fields).
+ <li>Ensure that the protocol is extensible (e.g., not limited to existing vCard fields).
<note>The extensibility requirement is critically important, because it would be best if the protocol specified herein could be used to represent data used within specialized communities. Examples of such communities include dating services, multiplayer gaming networks, IM services provided by portals and ISPs, and expert-location systems within large corporations. While such communities might use part or all of some common set of data fields (such as fields that map to familiar vCard elements), each community might also want to represent quite disparate kinds of information (dating criteria, favorite games, contact preferences, areas of expertise, and the like). Furthermore, data might be used to profile network actors that are not persons (e.g., bots, services, and other software agents). Therefore, the ideal proposal will provide an extensible framework for representing profile data and will not limit itself to representing the relatively small set of data fields covered by the vCard format.</note>
- </li>
+ </li>
<li>Where possible, map profile data fields to existing vCard fields and other common formats.</li>
</ol>
</section1>
@@ -169,7 +169,7 @@
<li>The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in <cite>XEP-0068</cite>).</li>
<li>Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).</li>
<li>Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.</li>
- <li>The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).</li>
+ <li>The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).</li>
</ol>
</li>
</ul>
@@ -1609,7 +1609,7 @@
]]></example>
</section3>
<section3 topic='Religious Affiliation' anchor='religion'>
- <p>Many people feel affiliated with a religious belief system.</p>
+ <p>Many people feel affiliated with a religious belief system.</p>
<p>The Data Forms field that represents a religious affiliation is "religion".</p>
<example caption='Religious Affiliation'><![CDATA[
<field var='religion'>
@@ -1627,7 +1627,7 @@
]]></example>
</section3>
<section3 topic='Smoker' anchor='smoker'>
- <p>Some people smoke tobacco in various forms (cigarettes, cigars, pipes, etc.).</p>
+ <p>Some people smoke tobacco in various forms (cigarettes, cigars, pipes, etc.).</p>
<p>The Data Forms field that represents whether a person smokes is "smoker".</p>
<example caption='Smoker'><![CDATA[
<field var='smoker'>
diff --git a/xep-0160.xml b/xep-0160.xml
index a26fd59..f47d0a2 100644
--- a/xep-0160.xml
+++ b/xep-0160.xml
@@ -94,7 +94,7 @@
Too flattering-sweet to be substantial.
</body>
<delay xmlns='urn:xmpp:delay'
- from='capulet.com'
+ from='capulet.com'
stamp='2002-09-10T23:08:25Z'>Offline Storage</delay>
</message>
]]></example>
diff --git a/xep-0161.xml b/xep-0161.xml
index 57b27ac..58049d3 100644
--- a/xep-0161.xml
+++ b/xep-0161.xml
@@ -162,11 +162,11 @@
<li><p>The recipient SHOULD NOT report the abuse stanza to the suspected abuser.</p></li>
</ol>
<example caption='Unsuspecting User Receives Abuse from Evil Bot'><![CDATA[
-<presence from='abuser@example.com'
+<presence from='abuser@example.com'
to='victim@example.org'
type='subscribe'>
<status>
- You too can be rich! Find out how at
+ You too can be rich! Find out how at
http://clickhere.info/makemoney
Let&apos;s chat to make your dreams
come true!
@@ -179,12 +179,12 @@
type='set'
id='report1'>
<spim xmlns='urn:xmpp:tmp:abuse'>
- <presence from='abuser@example.com'
+ <presence from='abuser@example.com'
to='victim@example.net'
type='subscribe'
xmlns='jabber:client'>
<status>
- You too can be rich! Find out how at
+ You too can be rich! Find out how at
http://clickhere.info/makemoney
Let&apos;s chat to make your dreams
come true!
@@ -391,7 +391,7 @@
xmlns='urn:xmpp:tmp:abuse'
elementFormDefault='qualified'>
- <xs:import
+ <xs:import
namespace='jabber:client'
schemaLocation='http://www.xmpp.org/schemas/jabber-client.xsd'/>
diff --git a/xep-0162.xml b/xep-0162.xml
index e28be7a..f038c68 100644
--- a/xep-0162.xml
+++ b/xep-0162.xml
@@ -60,9 +60,9 @@
<p>&rfc3921; explains how subscriptions and rosters integrate. However,
several points are left to the client author's discretion, and this can lead
- to some confusion among client developers. This document specifies best practices
- that enable all Jabber clients to manage subscriptions and roster in a coherent
- way, thus making sure that such clients will not surprise end users with
+ to some confusion among client developers. This document specifies best practices
+ that enable all Jabber clients to manage subscriptions and roster in a coherent
+ way, thus making sure that such clients will not surprise end users with
unexpected behavior.</p>
</section2>
@@ -76,7 +76,7 @@
<li><em>subscription='none'</em>: you aren't interested in the item's
presence, and neither is the item interested in yours.</li>
-
+
<li><em>subscription='from'</em>: the item is interested in your
presence information, but you don't care about the contact. (You must
be somebody important! ;)</li>
@@ -84,7 +84,7 @@
<li><em>subscription='to'</em>: You are interested in the item's
presence information, but the contact is not interested in
yours.</li>
-
+
<li><em>subscription='both'</em>: You and the contact are interested in each other's presence information.</li>
</ul>
@@ -141,7 +141,7 @@
</ol>
</li>
</ol>
-
+
<p>In addition to the "Remove" action described above, the client MAY
provide a way to revoke the contact's subscription to the user's presence.
This action, if provided, SHOULD be called "Block" since this is the
diff --git a/xep-0163.xml b/xep-0163.xml
index 07e59bb..a344f44 100644
--- a/xep-0163.xml
+++ b/xep-0163.xml
@@ -150,7 +150,7 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='motivation'>
- <p>Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented.
+ <p>Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented.
<note>Instead, many "extended presence" formats are currently sent using the &PRESENCE; stanza type; unfortunately, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.</note> To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing Protocol" or PEP.</p>
<p class='em'>Note: Any use cases not described herein are described in <cite>XEP-0060</cite>. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>XEP-0060</cite>. The reader is referred to <cite>XEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.</p>
</section2>
@@ -274,7 +274,7 @@
</ol>
<example caption='Romeo sends presence with caps'><![CDATA[
<presence from='romeo@montague.lit/orchard'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
@@ -404,7 +404,7 @@
<p class='box'>Note: The "on_sub_and_presence" setting relates to the <em>subscriber's</em> presence, not the publisher's presence.</p>
<example caption='Subscriber sends presence from newly-available resource'><![CDATA[
<presence from='romeo@montague.lit/orchard'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
@@ -412,7 +412,7 @@
]]></example>
<example caption='Subscriber&apos;s server sends presence from newly-available resource to publisher&apos;s bare JID (i.e., PEP service)'><![CDATA[
<presence from='romeo@montague.lit/orchard' to='juliet@capulet.lit'>
- <c xmlns='http://jabber.org/protocol/caps'
+ <c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
@@ -533,7 +533,7 @@
<type>
<name>pep</name>
<desc>
- A personal eventing service that supports the
+ A personal eventing service that supports the
publish-subscribe subset defined in XEP-0163.
</desc>
<doc>XEP-0163</doc>
diff --git a/xep-0164.xml b/xep-0164.xml
index 88cbbd8..0513ede 100644
--- a/xep-0164.xml
+++ b/xep-0164.xml
@@ -57,7 +57,7 @@
<p>To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in <cite>XEP-0054</cite>, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.</p>
<example caption="Requesting Another User's vCard"><![CDATA[
<iq to='jer@jabber.org'
- from='stpeter@jabber.org/home'
+ from='stpeter@jabber.org/home'
type='get'
id='v1'>
<vCard xmlns='vcard-temp'/>
@@ -65,8 +65,8 @@
]]></example>
<p>The server should then return the other user's vCard to the requestor:</p>
<example caption="Receiving Another User's vCard"><![CDATA[
-<iq from='jer@jabber.org'
- to='stpeter@jabber.org/home'
+<iq from='jer@jabber.org'
+ to='stpeter@jabber.org/home'
type='result'
id='v1'>
<vCard xmlns='vcard-temp'>
@@ -85,7 +85,7 @@
<p>A user may request that specific portions of another user's vCard be excluded by including the requested field(s) inside a filter element qualified by the 'vcard-temp-filter' namespace, inside the vCard element.</p>
<example caption="Requesting Another User's vCard Without the JABBERID Element"><![CDATA[
<iq to='jer@jabber.org'
- from='stpeter@jabber.org/home'
+ from='stpeter@jabber.org/home'
type='get'
id='v2'>
<vCard xmlns='vcard-temp'>
diff --git a/xep-0165.xml b/xep-0165.xml
index 279b4c9..9c658eb 100644
--- a/xep-0165.xml
+++ b/xep-0165.xml
@@ -81,8 +81,8 @@
&#5082;&#5026;&#5045;&#5036;&#5026;&#5036;&#5074;@&#5035;&#5034;&#5108;&#5108;&#5036;&#5074;.org</code>
<p>That JID is not an uppercase version of "stpeter@jabber.org" in US-ASCII characters, but a fake JID made up mostly of Cherokee characters, namely:</p>
<code>
- U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2
- @
+ U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2
+ @
U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 .org</code>
<p>In this example, it is unlikely that the average user could tell the difference between the real JID and the fake JID. <note>Naturally, there is no way to distinguish with full certainty which is the fake JID and which is the real JID. For example, in some communication contexts, the Cherokee JID may be the real JID and the US-ASCII JID may thus appear to be the fake JID.</note></p>
<p>By contrast with address forging, it may be relatively easy to mimic (some) JIDs in Jabber/XMPP systems, especially because JIDs can contain almost any Unicode character. The possibility of address mimicking introduces security vulnerabilities of the kind that have also plagued the World Wide Web, specifically the phenomenon known as phishing. <note>Phishing has been defined by the Financial Services Technology Consortium Counter-Phishing Initiative as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them"). To be precise, the current document (1) does not assume that such attacks will be broadly launched and (2) focuses on the misrepresentation of Jabber IDs (not any other identifiers) within the context of Jabber/XMPP systems.</note> To combat those vulnerabilities, this document recommends a set of best practices to minimize the potential impact of address mimicking on the Jabber/XMPP network. <note>This document does not cover handling of non-XMPP addresses, for example HTTP URLs. Jabber/XMPP clients SHOULD handle such addresses in accordance with best practices for the relevant non-XMPP technology.</note></p>
diff --git a/xep-0166.xml b/xep-0166.xml
index 7ec164c..75261f6 100644
--- a/xep-0166.xml
+++ b/xep-0166.xml
@@ -1081,7 +1081,7 @@ PENDING o-----------------------+ |
</error>
</iq>
]]></example>
- <p>Not all Jingle sessions end gracefully. When the parties to a Jingle session also exchange XMPP presence information, receipt of &UNAVAILABLE; from the other party SHOULD be considered a session-ending event that justifies proactively sending a session-terminate message to the seemingly unavailable party -- if, that is, no other communication has been received within 5 or 10 seconds from the seemingly unavailable party in the form of XMPP signalling traffic, connectivity checks, or continued media transfer.</p>
+ <p>Not all Jingle sessions end gracefully. When the parties to a Jingle session also exchange XMPP presence information, receipt of &UNAVAILABLE; from the other party SHOULD be considered a session-ending event that justifies proactively sending a session-terminate message to the seemingly unavailable party -- if, that is, no other communication has been received within 5 or 10 seconds from the seemingly unavailable party in the form of XMPP signalling traffic, connectivity checks, or continued media transfer.</p>
</section2>
<section2 topic='Informational Messages' anchor='session-info'>
<p>At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to inform the other party that a device is ringing.</p>
@@ -1146,12 +1146,12 @@ PENDING o-----------------------+ |
</tr>
<tr>
<td>initiator*</td>
- <td>The full JID of the entity that has initiated the session flow. When the Jingle action is "session-initiate", the &JINGLE; element SHOULD possess an 'initiator' attribute that explicitly specifies the full JID of the initiating entity; for all other actions, the &JINGLE; element SHOULD NOT possess an 'initiator' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'initiator' attribute MAY be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays). This usage shall be defined in other specifications, for example, in &xep0251;. However, in all cases if the 'initiator' and 'from' values differ then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts that the 'from' JID is allowed to authorize the 'initiator' JID to act on the 'from' JID's behalf. In the absence of explicit rules for handling this case, the responder SHOULD simply ignore the 'initiator' attribute and treat the 'from' JID as the initiating entity. After sending acknowledgement of the session-initiate message, the responder MUST send all future commmunications about the Jingle session to the initiator (whether the initiator is considered the 'from' JID or the 'initiator' JID).</td>
+ <td>The full JID of the entity that has initiated the session flow. When the Jingle action is "session-initiate", the &JINGLE; element SHOULD possess an 'initiator' attribute that explicitly specifies the full JID of the initiating entity; for all other actions, the &JINGLE; element SHOULD NOT possess an 'initiator' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'initiator' attribute MAY be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays). This usage shall be defined in other specifications, for example, in &xep0251;. However, in all cases if the 'initiator' and 'from' values differ then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts that the 'from' JID is allowed to authorize the 'initiator' JID to act on the 'from' JID's behalf. In the absence of explicit rules for handling this case, the responder SHOULD simply ignore the 'initiator' attribute and treat the 'from' JID as the initiating entity. After sending acknowledgement of the session-initiate message, the responder MUST send all future commmunications about the Jingle session to the initiator (whether the initiator is considered the 'from' JID or the 'initiator' JID).</td>
<td>RECOMMENDED for session-initiate, NOT RECOMMENDED otherwise</td>
</tr>
<tr>
<td>responder*</td>
- <td>The full JID of the entity that has replied to the initiation, which can be different from the 'to' address on the IQ-set. When the Jingle action is "session-accept", the &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; for all other actions, the &JINGLE; element SHOULD NOT possess a 'responder' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'responder' attribute MAY be different from the 'from' address on the IQ-set of the session-accept message, where the logic for handling any difference between the 'responder' JID and the 'from' JID follows the same logic as for session-initiate messages (see above). After sending acknowledgement of the session-accept message, the initiator MUST send all future commmunications about this Jingle session to the responder (whether the responder is considered the 'from' JID or the 'responder' JID).</td>
+ <td>The full JID of the entity that has replied to the initiation, which can be different from the 'to' address on the IQ-set. When the Jingle action is "session-accept", the &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; for all other actions, the &JINGLE; element SHOULD NOT possess a 'responder' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'responder' attribute MAY be different from the 'from' address on the IQ-set of the session-accept message, where the logic for handling any difference between the 'responder' JID and the 'from' JID follows the same logic as for session-initiate messages (see above). After sending acknowledgement of the session-accept message, the initiator MUST send all future commmunications about this Jingle session to the responder (whether the responder is considered the 'from' JID or the 'responder' JID).</td>
<td>RECOMMENDED for session-accept, NOT RECOMMENDED otherwise</td>
</tr>
<tr>
@@ -1546,7 +1546,7 @@ PENDING o-----------------------+ |
<name>The name of the application format.</name>
<desc>A natural-language summary of the application format.</desc>
<transport>
- Whether the media can be sent over a "streaming" transport,
+ Whether the media can be sent over a "streaming" transport,
a "datagram" transport, or "both".
</transport>
<doc>The document in which the application format is specified.</doc>
@@ -1561,7 +1561,7 @@ PENDING o-----------------------+ |
<name>The name of the transport method.</name>
<desc>A natural-language summary of the transport method.</desc>
<type>
- Whether the transport method can be "streaming", "datagram",
+ Whether the transport method can be "streaming", "datagram",
or "both".
</type>
<doc>The document in which this transport method is specified.</doc>
@@ -1590,13 +1590,13 @@ PENDING o-----------------------+ |
<xs:element name='jingle'>
<xs:complexType>
<xs:sequence>
- <xs:element name='content'
+ <xs:element name='content'
type='contentElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='unbounded'/>
- <xs:element name='reason'
+ <xs:element name='reason'
type='reasonElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='1'/>
<xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
@@ -1673,7 +1673,7 @@ PENDING o-----------------------+ |
<xs:complexType name='reasonElementType'>
<xs:sequence>
<xs:choice>
- <xs:element name='alternative-session'
+ <xs:element name='alternative-session'
type='alternativeSessionElementType'/>
<xs:element name='busy' type='empty'/>
<xs:element name='cancel' type='empty'/>
diff --git a/xep-0167.xml b/xep-0167.xml
index 7cf3e59..98cbfbd 100644
--- a/xep-0167.xml
+++ b/xep-0167.xml
@@ -605,9 +605,9 @@ delivery-method=inline; configuration=somebase16string;
<p>An example follows.</p>
<code><![CDATA[
<encryption required='1'>
- <crypto
- crypto-suite='AES_CM_128_HMAC_SHA1_80'
- key-params='inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32'
+ <crypto
+ crypto-suite='AES_CM_128_HMAC_SHA1_80'
+ key-params='inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32'
session-params='KDR=1 UNENCRYPTED_SRTCP'
tag='1'/>
</encryption>
@@ -1164,9 +1164,9 @@ Romeo Juliet
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
<encryption required='1'>
- <crypto
- crypto-suite='AES_CM_128_HMAC_SHA1_80'
- key-params='inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32'
+ <crypto
+ crypto-suite='AES_CM_128_HMAC_SHA1_80'
+ key-params='inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32'
session-params='KDR=1 UNENCRYPTED_SRTCP'
tag='1'/>
</encryption>
@@ -1245,9 +1245,9 @@ Romeo Juliet
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<encryption>
- <crypto
- crypto-suite='AES_CM_128_HMAC_SHA1_80'
- key-params='inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32'
+ <crypto
+ crypto-suite='AES_CM_128_HMAC_SHA1_80'
+ key-params='inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32'
session-params='KDR=1;UNENCRYPTED_SRTCP'
tag='1'/>
</encryption>
@@ -1717,7 +1717,7 @@ Romeo Juliet
<application>
<name>rtp</name>
<desc>
- Jingle sessions that support media exchange
+ Jingle sessions that support media exchange
via the Real-time Transport Protocol.
</desc>
<transport>datagram</transport>
@@ -1748,17 +1748,17 @@ Romeo Juliet
<xs:element name='description'>
<xs:complexType>
<xs:sequence>
- <xs:element name='payload-type'
+ <xs:element name='payload-type'
type='payloadElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='unbounded'/>
- <xs:element name='encryption'
+ <xs:element name='encryption'
type='encryptionElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='1'/>
- <xs:element name='bandwidth'
+ <xs:element name='bandwidth'
type='bandwidthElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='media'
@@ -1773,8 +1773,8 @@ Romeo Juliet
<xs:complexType name='bandwidthElementType'>
<xs:simpleContent>
<xs:extension base='xs:string'>
- <xs:attribute name='type'
- type='xs:string'
+ <xs:attribute name='type'
+ type='xs:string'
use='required'/>
</xs:extension>
</xs:simpleContent>
@@ -1793,9 +1793,9 @@ Romeo Juliet
<xs:complexType name='encryptionElementType'>
<xs:sequence>
- <xs:element name='crypto'
+ <xs:element name='crypto'
type='cryptoElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
@@ -1804,7 +1804,7 @@ Romeo Juliet
<xs:sequence>
<xs:element name='parameter'
type='parameterElementType'
- minOccurs='0'
+ minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='channels'
diff --git a/xep-0168.xml b/xep-0168.xml
index b12285c..bb783e6 100644
--- a/xep-0168.xml
+++ b/xep-0168.xml
@@ -185,8 +185,8 @@
</table>
<p>An example follows.</p>
<example caption='Data format'><![CDATA[
-<rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+<rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='5'/>
]]></example>
</section2>
@@ -205,22 +205,22 @@
<example caption='Contact receives presence from user'><![CDATA[
<presence from='juliet@capulet.lit/desktop' to='romeo@montague.lit/home'>
<priority>10</priority>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='5'/>
</presence>
<presence from='juliet@capulet.lit/pda' to='romeo@montague.lit/home'>
<priority>5</priority>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='-1'/>
</presence>
<presence from='juliet@capulet.lit/mobile' to='romeo@montague.lit/home'>
<priority>-1</priority>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='10'/>
</presence>
]]></example>
@@ -236,8 +236,8 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:rap:0'>
<item>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='5'/>
</item>
</items>
@@ -254,8 +254,8 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:rap:0'>
<item>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='-1'/>
</item>
</items>
@@ -272,8 +272,8 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:rap:0'>
<item>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='10'/>
</item>
</items>
@@ -292,8 +292,8 @@
<example caption='Primary resource flag'><![CDATA[
<presence from='juliet@capulet.lit/mobile'>
<priority>-1</priority>
- <rap xmlns='urn:xmpp:rap:0'
- ns='urn:xmpp:jingle:apps:rtp:0'
+ <rap xmlns='urn:xmpp:rap:0'
+ ns='urn:xmpp:jingle:apps:rtp:0'
num='10'>
<primary/>
</rap>
diff --git a/xep-0169.xml b/xep-0169.xml
index f5160d9..4c4eb60 100644
--- a/xep-0169.xml
+++ b/xep-0169.xml
@@ -81,7 +81,7 @@
<p>The children were nestled all snug in their beds,</p>
<code><![CDATA[
-<message from='child@twas-the-night.lit'
+<message from='child@twas-the-night.lit'
to='narrator@twas-the-night.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -99,7 +99,7 @@
<p>While visions of sugar-plums danced in their heads.</p>
<code><![CDATA[
-<message from='child@twas-the-night.lit'
+<message from='child@twas-the-night.lit'
to='narrator@twas-the-night.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -121,7 +121,7 @@
<p>Had just settled down for a long winter's nap.</p>
<code><![CDATA[
-<message from='mama@twas-the-night.lit'
+<message from='mama@twas-the-night.lit'
to='narrator@twas-the-night.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -146,9 +146,9 @@
<p>But a miniature sleigh, and eight tiny rein-deer,</p>
<code><![CDATA[
-<iq from='sleigh@northpole.lit/sleigh'
+<iq from='sleigh@northpole.lit/sleigh'
id='geo87361'
- to='sleigh@northpole.lit'
+ to='sleigh@northpole.lit'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/geoloc'>
@@ -165,7 +165,7 @@
]]></code>
<code><![CDATA[
-<message from='sleigh@northpole.lit'
+<message from='sleigh@northpole.lit'
to='polecom@northpole.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -188,68 +188,68 @@
<p>And he whistled, and shouted, and called them by name;</p>
<code><![CDATA[
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Now, Dasher!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Now, Dancer!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Now, Prancer and Vixen!</body>
-</message>
+</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>On, Comet!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>On, Cupid!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>On, Donder and Blitzen!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>To the top of the porch!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>To the top of the wall!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Now dash away!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Dash away!</body>
</message>
-<message from='reindeer@chat.northpole.lit/santa'
- to='reindeer@chat.northpole.lit'
+<message from='reindeer@chat.northpole.lit/santa'
+ to='reindeer@chat.northpole.lit'
type='groupchat'>
<body>Dash away all!</body>
</message>
@@ -261,9 +261,9 @@
<p>With the sleigh full of toys, and St. Nicholas too.</p>
<code><![CDATA[
-<iq type='set'
- from='sleigh@northpole.lit/sleigh'
- to='info.northpole.lit'
+<iq type='set'
+ from='sleigh@northpole.lit/sleigh'
+ to='info.northpole.lit'
id='geo87361'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='sleigh/geoloc'>
@@ -280,7 +280,7 @@
]]></code>
<code><![CDATA[
-<message from='info.northpole.lit'
+<message from='info.northpole.lit'
to='polecom@northpole.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -303,9 +303,9 @@
<p>Down the chimney St. Nicholas came with a bound.</p>
<code><![CDATA[
-<iq type='set'
- from='saintnick@northpole.lit/pda'
- to='info.northpole.lit'
+<iq type='set'
+ from='saintnick@northpole.lit/pda'
+ to='info.northpole.lit'
id='geo117362'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='kringle/geoloc'>
@@ -357,7 +357,7 @@
<p>And I laughed when I saw him in spite of myself;</p>
<code><![CDATA[
-<message from='narrator@twas-the-night.lit'
+<message from='narrator@twas-the-night.lit'
to='mama@twas-the-night.lit'
type='headline>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -376,7 +376,7 @@
<p>Soon gave me to know I had nothing to dread.</p>
<code><![CDATA[
-<message from='narrator@twas-the-night.lit'
+<message from='narrator@twas-the-night.lit'
to='mama@twas-the-night.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -394,9 +394,9 @@
<p>He spoke not a word, but went straight to his work,</p>
<code><![CDATA[
-<iq type='set'
- from='saintnick@northpole.lit/pda'
- to='info.northpole.lit'
+<iq type='set'
+ from='saintnick@northpole.lit/pda'
+ to='info.northpole.lit'
id='activity9412'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='kringle/activity'>
@@ -431,9 +431,9 @@
<p>And giving a nod, up the chimney he rose.</p>
<code><![CDATA[
-<iq type='set'
- from='saintnick@northpole.lit/pda'
- to='info.northpole.lit'
+<iq type='set'
+ from='saintnick@northpole.lit/pda'
+ to='info.northpole.lit'
id='geo117363'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='kringle/geoloc'>
@@ -450,7 +450,7 @@
]]></code>
<code><![CDATA[
-<message from='info.northpole.lit'
+<message from='info.northpole.lit'
to='polecom@northpole.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@@ -471,9 +471,9 @@
<p>And away they all flew, like the down of a thistle.</p>
<code><![CDATA[
-<iq type='set'
- from='sleigh@northpole.lit/sleigh'
- to='info.northpole.lit'
+<iq type='set'
+ from='sleigh@northpole.lit/sleigh'
+ to='info.northpole.lit'
id='geo87362'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='sleigh/geoloc'>
@@ -508,16 +508,16 @@
<p>But I heard him exclaim, ere he drove out of sight --</p>
<code><![CDATA[
-<message from='house@chat.twas-the-night.lit/santa'
- to='house@chat.twas-the-night.lit'
+<message from='house@chat.twas-the-night.lit/santa'
+ to='house@chat.twas-the-night.lit'
type='groupchat'>
<body>Happy Christmas to all, and to all a good night.</body>
</message>
]]></code>
<code><![CDATA[
-<presence from='saintnick@northpole.lit/pda'
- to='house@chat.twas-the-night.lit/santa'
+<presence from='saintnick@northpole.lit/pda'
+ to='house@chat.twas-the-night.lit/santa'
type='unavailable'/>
]]></code>
@@ -543,9 +543,9 @@
<p>This document assumes the following architecture:</p>
<code><![CDATA[
+--- info.northpole.lit (pubsub service) *
- | |
+ | |
| | (pubsub nodes)
- | |
+ | |
+--------------------+ (s2s) +---------------+ | |-- kringle/activity
| twas-the-night.lit | ------- | northpole.lit |---| |-- kringle/geoloc
+--------------------+ +---------------+ | |-- sleigh/geoloc
@@ -561,7 +561,7 @@
| |-- cupid
| (occupants) |-- donder
| |-- blitzen
- |-- santa et al.
+ |-- santa et al.
]]></code>
<p>In addition, we assume that the twas-the-night.lit server is running a virtual pubsub service for each account it hosts (in accordance with <cite>XEP-0163</cite>) and that the users "narrator", "mama", and "child" publish information to personal pubsub nodes related to mood (<cite>XEP-0107</cite>), activity (<cite>XEP-0108</cite>), and physical location (<cite>XEP-0112</cite>).</p>
<p>* Because millions of people track the movements and activities of Santa, northpole.lit runs a highly scalable, standalone pubsub service instead of PEP at Santa's bare JID.</p>
diff --git a/xep-0172.xml b/xep-0172.xml
index 08eca5d..7345867 100644
--- a/xep-0172.xml
+++ b/xep-0172.xml
@@ -188,8 +188,8 @@
<section2 topic='Nickname Management' anchor='manage'>
<p>In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &xep0163; (a.k.a. PEP).</p>
<example caption='User Publishes Updated Nickname to PEP Node'><![CDATA[
-<iq from='narrator@moby-dick.lit/pda'
- type='set'
+<iq from='narrator@moby-dick.lit/pda'
+ type='set'
id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/nick'>
@@ -201,7 +201,7 @@
</iq>
]]></example>
<example caption='PEP Node Generates Notifications'><![CDATA[
-<message from='narrator@moby-dick.lit'
+<message from='narrator@moby-dick.lit'
to='starbuck@moby-dick.lit'
type='headline'
id='foo'>
@@ -222,9 +222,9 @@
]]></example>
<p>If a XEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &xep0060; service.</p>
<example caption='User Publishes Updated Nickname to PubSub Node'><![CDATA[
-<iq from='narrator@moby-dick.lit/pda'
- to='pubsub.mody-dick.lit'
- type='set'
+<iq from='narrator@moby-dick.lit/pda'
+ to='pubsub.mody-dick.lit'
+ type='set'
id='pub2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='841f3c8955c4c41a0cf99620d78a33b996659ded'>
@@ -236,7 +236,7 @@
</iq>
]]></example>
<example caption='PubSub Node Generates Notifications'><![CDATA[
-<message from='pubsub.mody-dick.lit'
+<message from='pubsub.mody-dick.lit'
to='starbuck@moby-dick.lit'
type='headline'
id='foo'>
diff --git a/xep-0174.xml b/xep-0174.xml
index b11f146..b97d7c8 100644
--- a/xep-0174.xml
+++ b/xep-0174.xml
@@ -167,7 +167,7 @@
<code><![CDATA[
pronto.local. A 10.2.1.187
-juliet@pronto._presence._tcp.local. SRV 5562 pronto.local.
+juliet@pronto._presence._tcp.local. SRV 5562 pronto.local.
_presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
]]></code>
@@ -181,25 +181,25 @@ _presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
<code><![CDATA[
txtvers=1
1st=Juliet
-email=juliet@capulet.lit
-hash=sha-1
-jid=juliet@capulet.lit
-last=Capulet
-msg=Hanging out downtown
-nick=JuliC
-node=http://www.adiumx.com
-phsh=a3839614e1a382bcfebbcf20464f519e81770813
-port.p2pj=5562
-status=avail
-vc=CA!
+email=juliet@capulet.lit
+hash=sha-1
+jid=juliet@capulet.lit
+last=Capulet
+msg=Hanging out downtown
+nick=JuliC
+node=http://www.adiumx.com
+phsh=a3839614e1a382bcfebbcf20464f519e81770813
+port.p2pj=5562
+status=avail
+vc=CA!
ver=QgayPKawpkPSDYmwT/WM94uAlu0=
]]></code>
<p>Other people at the hotspot can also advertise similar DNS records for use on the local link. Essentially, the mDNS daemons running on all of the machines at the hotspot collectively manage the ".local." domain, which has meaning only at the hotspot (not across the broader Internet). Queries and responses for services on the local link occur via multicast DNS over UDP port 5353 instead of via normal DNS unicast over UDP port 53. When a new machine joins the local link, it can send out queries for any number of service types, to which the other machines will reply. For the purpose of serverless messaging we are interested only in the "presence" service, but many other services could exist on the local link (see <link url='http://www.dns-sd.org/'>dns-sd.org</link> for a complete list).</p>
<p>Now let us imagine that a fine young gentleman named Romeo joins the hotspot and that his chat client (actually his mDNS daemon) sends out multicast DNS queries for services of type "presence". To do this, his client essentially reverses the order of DNS record publication (explained above) by asking for pointers to presence services (i.e., PTR records that match "_presence._tcp.local."), querying each service for its service instance and port (i.e., SRV record), mapping each service instance to an IP address (i.e., A record), and finding out additional information about the entity using the service (i.e., TXT record parameters). <note>As explained in the DNS-SD specification, these queries might all be returned in the same answer.</note> As a result, Romeo's client will discover any number of local presence services, among them a service named "juliet@pronto" (with some intriguing TXT record parameters) at IP address 10.2.1.187 and port 5562. Being a romantic fellow, he then initiates a chat with you by opening an XML stream to the advertised IP address and port.</p>
<code><![CDATA[
<?xml version='1.0'?>
-<stream:stream
- xmlns='jabber:client'
+<stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@forza'
to='juliet@pronto'
@@ -208,8 +208,8 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=
<p>Your client then responds with a response stream header.</p>
<code><![CDATA[
<?xml version='1.0'?>
-<stream:stream
- xmlns='jabber:client'
+<stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='juliet@pronto'
to='romeo@forza'
@@ -247,11 +247,11 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=
</tr>
<tr>
<td>Bonjour</td>
- <td>Apple Computer's implementation of zero-configuration networking, formerly known as Rendezvous. See &lt;<link url='http://www.apple.com/macosx/features/bonjour/'>http://www.apple.com/macosx/features/bonjour/</link>&gt;.</td>
+ <td>Apple Computer's implementation of zero-configuration networking, formerly known as Rendezvous. See &lt;<link url='http://www.apple.com/macosx/features/bonjour/'>http://www.apple.com/macosx/features/bonjour/</link>&gt;.</td>
</tr>
<tr>
<td>DNS-SD</td>
- <td>A convention for naming and structuring DNS SRV records such that a client can dynamically discover a domain for a service using only standard DNS queries. See <cite>draft-cheshire-dnsext-dns-sd</cite>. For a full list of registered DNS-SD records, see &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt;.</td>
+ <td>A convention for naming and structuring DNS SRV records such that a client can dynamically discover a domain for a service using only standard DNS queries. See <cite>draft-cheshire-dnsext-dns-sd</cite>. For a full list of registered DNS-SD records, see &lt;<link url='http://www.dns-sd.org/ServiceTypes.html'>http://www.dns-sd.org/ServiceTypes.html</link>&gt;.</td>
</tr>
<tr>
<td>Multicast DNS (mDNS)</td>
@@ -259,7 +259,7 @@ ver=QgayPKawpkPSDYmwT/WM94uAlu0=
</tr>
<tr>
<td>Zero-configuration networking</td>
- <td>A set of technologies that enable the use of the Internet Protocol for local or wide-area communications. See &lt;<link url='http://www.zeroconf.org/'>http://www.zeroconf.org/</link>&gt;.</td>
+ <td>A set of technologies that enable the use of the Internet Protocol for local or wide-area communications. See &lt;<link url='http://www.zeroconf.org/'>http://www.zeroconf.org/</link>&gt;.</td>
</tr>
</table>
</section1>
@@ -282,7 +282,7 @@ machine.local. A ip-address
<li>
<p>An SRV record of the following form:</p>
<code><![CDATA[
-user@machine._presence._tcp.local <ttl> SRV <priority> <weight> port-number machine.local.
+user@machine._presence._tcp.local <ttl> SRV <priority> <weight> port-number machine.local.
]]></code>
</li>
<li>
@@ -313,11 +313,11 @@ ver=entity-capabilities-identity
<code><![CDATA[
_presence._tcp.local. PTR juliet@pronto._presence._tcp.local.
-juliet@pronto._presence._tcp.local. SRV 5562 pronto.local.
+juliet@pronto._presence._tcp.local. SRV 5562 pronto.local.
pronto.local. A 10.2.1.187
-juliet@pronto._presence._tcp.local. IN TXT
+juliet@pronto._presence._tcp.local. IN TXT
"txtvers=1"
"1st=Juliet"
"email=juliet@capulet.lit "
@@ -334,8 +334,8 @@ juliet@pronto._presence._tcp.local. IN TXT
"ver=QgayPKawpkPSDYmwT/WM94uAlu0=""
]]></code>
<p>The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.187". See <cite>RFC 3927</cite> for details.</p>
- <p>If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.</p>
- <p>If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.</p>
+ <p>If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.</p>
+ <p>If the username asserted by a client is already taken by another application on the machine, the client MUST assert a different username, which SHOULD be formed by adding the character "-" and digit "1" to the end of the username string (e.g., "juliet-1"), adding the character "-" and digit "2" if the resulting username is already taken (e.g., "juliet-2"), and similarly incrementing the digit until a unique username is constructed.</p>
<section2 topic='TXT Record' anchor='txt'>
<p>DNS-SD enables service definitions to include a TXT record that specifies parameters to be used in the context of the relevant service type. The name of the TXT record is the same as that of the SRV record (i.e., "user@machine._presence._tcp.local."). The value of the TXT record is one or more strings, where each string is a parameter that usually takes the form of a key-value pair.</p>
<p>In the context of serverless messaging, the following rules apply:</p>
@@ -352,7 +352,7 @@ juliet@pronto._presence._tcp.local. IN TXT
<section1 topic='Discovering Other Users' anchor='disco'>
<p>In order to discover other users, a client sends an mDNS request for PTR records that match "_presence._tcp.local.". The client then receives replies from all machines that advertise support for serverless messaging. <note>The replies will include a record corresponding to the client itself; the client MUST filter out this result.</note> In accordance with Section 13 of the DNS-SD specification, these replies can include the SRV, A/AAAA, and TXT records in the Additional Section of the DNS message (subject to the size limits described in Section 19 of the Multicast DNS specification).</p>
- <p>The client MAY then find out detailed information about each machine by sending SRV and TXT queries <note>These questions MAY all be sent in one DNS query packet.</note> to "user@machine.local." for each machine; however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communication with the other user, and it MUST cancel the queries after it has received a response).
+ <p>The client MAY then find out detailed information about each machine by sending SRV and TXT queries <note>These questions MAY all be sent in one DNS query packet.</note> to "user@machine.local." for each machine; however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communication with the other user, and it MUST cancel the queries after it has received a response).
</p>
</section1>
@@ -365,8 +365,8 @@ juliet@pronto._presence._tcp.local. IN TXT
<p>First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:</p>
<example caption="Initiator Opens a Stream"><![CDATA[
I: <?xml version='1.0'?>
- <stream:stream
- xmlns='jabber:client'
+ <stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@forza'
to='juliet@pronto'
@@ -376,8 +376,8 @@ I: <?xml version='1.0'?>
<p>The recipient then responds with a stream header as well:</p>
<example caption="Recipient Sends Stream Header Response"><![CDATA[
R: <?xml version='1.0'?>
- <stream:stream
- xmlns='jabber:client'
+ <stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='juliet@pronto'
to='romeo@forza'
@@ -431,8 +431,8 @@ I: </stream:stream>
<p>Unfortunately, full stream negotiation (including TLS and SASL if appropriate) can require a large number of packets. Therefore, as an optimization, it is RECOMMENDED for the receiving entity in a serverless XML stream negotiation to include its disco#info data (including node) as a stream feature, as shown in the following examples.</p>
<example caption="Initiator Opens a Stream"><![CDATA[
I: <?xml version='1.0'?>
- <stream:stream
- xmlns='jabber:client'
+ <stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@forza'
to='juliet@pronto'
@@ -440,8 +440,8 @@ I: <?xml version='1.0'?>
]]></example>
<example caption="Recipient Sends Stream Header Response"><![CDATA[
R: <?xml version='1.0'?>
- <stream:stream
- xmlns='jabber:client'
+ <stream:stream
+ xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='juliet@pronto'
to='romeo@forza'
@@ -552,9 +552,9 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<name>The name of the parameter as used a key-value pair.</name>
<desc>A natural-language description of the parameter.</desc>
<status>
- The requirements status of the record. Should be one of:
+ The requirements status of the record. Should be one of:
- required
- - recommended
+ - recommended
- optional
- deprecated
- obsolete
@@ -576,7 +576,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<param>
<name>email</name>
<desc>
- The email address of the user; can contain a space-separated list
+ The email address of the user; can contain a space-separated list
of more than one email address.
</desc>
<status>optional</status>
@@ -585,8 +585,8 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<param>
<name>ext</name>
<desc>
- A space-separated list of extensions; the value of this record MUST
- be the same as that provided via normal XMPP presence (if applicable)
+ A space-separated list of extensions; the value of this record MUST
+ be the same as that provided via normal XMPP presence (if applicable)
in the 'ext' attribute specified in Entity Capabilities (XEP-0115).
</desc>
<status>optional</status>
@@ -595,7 +595,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<param>
<name>hash</name>
<desc>
- The hashing algorithm used to generated the 'ver' attribute in
+ The hashing algorithm used to generated the 'ver' attribute in
Entity Capabilities (XEP-0115) and therefore the ver parameter
in Link-Local Messaging.
</desc>
@@ -605,7 +605,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<param>
<name>jid</name>
<desc>
- The Jabber ID of th